PHP development frameworks providing structured foundations, libraries, and tools for building modern web applications. All available with one-click installation on 365i web hosting.
CakePHP is a free, open-source PHP framework designed to simplify and speed up web development. Know...
Laravel is a powerful, open-source PHP framework designed for building modern web applications quick...
Slim is a lightweight, open-source PHP micro-framework designed for building simple, fast, and power...
Nobody installs a framework the way they install a content management system. There is no admin login at the end of it and nothing to configure in a browser. What a framework install produces is an empty application skeleton, and the useful question for a hosting page is not "can I install Laravel" but "will the application my developer built on Laravel run here, and what will break". This page answers that one.
The three listed cover the range. Laravel is the default choice for PHP application work now, with version 13 released on 17 March 2026 requiring PHP 8.3 to 8.5, and a support policy of eighteen months of bug fixes and two years of security fixes per release. CakePHP is the long-lived alternative, at 5.4 as of July 2026 and needing PHP 8.2 or newer. Slim is a micro-framework: routing, middleware and PSR-7 messages, nothing else, which makes it the natural pick for a small API or a service that does one job.
Shared hosting has a reputation for being hostile to framework applications, and it is half deserved. The parts that really do need a server you control are long-running processes and in-memory caching. The parts people assume are impossible, pointing the web root at a subdirectory, running Composer, scheduling artisan commands, keeping environment variables out of the document root, are all perfectly ordinary if the host gives you SSH and cron. We do, on every plan.
Situations we see often. If one of these sounds like you, this category is worth a look.
The agency hands over a repository and a deployment note, and the business needs somewhere to put it that will not fight the framework's expectations. SSH, Composer, a document root that can point at public/ and cron for the scheduler cover everything in a standard Laravel deployment guide.
A booking system or a stock tracker with predictable, low traffic and no public exposure, where a dedicated server would be an expensive way to serve twenty people. Shared hosting is the honest fit, and the application only needs the database and a nightly scheduled task.
A handful of JSON endpoints feeding a mobile app or a JavaScript front end, deployed as its own small codebase on a subdomain. Slim has no console tooling, no migrations and nothing to schedule, so there is nothing about it that shared hosting cannot do.
Client work, a side project and a staging copy, each wanting its own document root, database and PHP version. Add-on domains with independent web roots and a per-package PHP selector handle that without paying for three servers, and the PHP version can differ where an older project needs it to.
You should never attempt to move the index.php file to your project's root, as serving the application from the project root will expose many sensitive configuration files to the public Internet.
This is the single most consequential shared-hosting mistake in the category, and the framework authors have put a warning in the documentation because of how often it is made. Moving index.php up puts your .env file, with database credentials and API keys in it, one guessed URL away from anyone. Point the document root at public/ instead. It takes a minute.
Your web server's PHP version must match your CLI PHP version (8.2+).
Worth flagging because shared hosting is exactly where this goes wrong. Many hosts serve pages on one PHP build while an SSH session gets a different default, so Composer resolves dependencies against one version and the site runs on another. Check both with php -v over SSH and a phpinfo page before you debug anything else.
Hosting a PHP framework well is mostly about the things people forget to check until something breaks: SSH access, Composer, cron, environment variable handling, and a sane document-root setup that points at the framework's public/ subdirectory rather than the project root. We give all of that on every plan with PHP 8.5, modern extensions, and a real shell, so framework deployments behave the way framework documentation expects.
Get the document root right and most of the rest follows. Laravel serves from public/ and CakePHP from webroot/, and the fix is to point the domain's web root at that subdirectory in the control panel. The two workarounds people reach for are both worse: moving index.php into the project root exposes .env, and rewriting into public/ with .htaccess leaves the rest of the tree reachable by direct URL. If you have inherited a site set up either way, treat the credentials in .env as compromised and rotate them.
Composer works over SSH, and what trips it is memory rather than availability, since resolving a large dependency tree is expensive. Committing vendor/ and deploying it is a legitimate answer. Cron covers the scheduler: one entry running artisan schedule:run each minute is all Laravel needs.
Queues are where shared hosting actually stops. queue:work is a daemon, and a shared plan has no supervisor to restart it when it exits. Calling queue:work --stop-when-empty from cron approximates it, which is fine for email and poor for anything latency-sensitive. Redis is a managed cloud server feature here, not a shared-plan one.
Not for you if you need Horizon, Octane, WebSockets, a persistent queue worker or Redis. Those are the reasons to take a cloud server, and they are good ones.
Common questions we hear from people running PHP frameworks applications on 365i hosting.
Set the web root for the domain in the My365i control panel to the public/ subdirectory (or webroot/ on CakePHP) and upload the project above it. Do not move index.php up to the project root instead. Laravel's own documentation warns that serving from the project root exposes sensitive configuration files, which in practice means your .env file with its database credentials and API keys is fetchable over the web. If you are unsure, raise a ticket and we will check the setup with you.
SSH and SFTP are on every plan, and Composer is available, so you can run composer install on the server in the normal way. Uploading a locally built vendor/ directory is also perfectly valid and is sometimes the faster route, particularly if dependency resolution is memory-hungry or your connection is slow. Either approach works. What matters more is checking that the PHP version your SSH session uses matches the one serving the site, because a mismatch produces confusing errors after deployment.
Scheduled tasks yes, persistent queue workers no. A single cron entry running artisan schedule:run every minute gives you Laravel's full scheduler, and cron jobs are unlimited on every plan. Queue workers are a different thing: queue:work is a long-running daemon and shared hosting has no process supervisor to keep it alive. Calling queue:work --stop-when-empty from cron is a workable compromise for background email and report generation. If queue latency actually matters to your application, that is a cloud server requirement.
Slim is a micro-framework for PHP: HTTP routing, middleware and PSR-7 message handling, and deliberately nothing else. No ORM, no templating engine, no console tooling, no migrations. You choose it when the job is a small API or a service with a handful of endpoints and Laravel's structure would be overhead rather than help. Version 4.15.2 arrived in May 2026 and supports PHP 7.4 through 8.5. It is also the least demanding framework in this category to host, by a distance.
Match the framework, not the newest number. Laravel 13 supports PHP 8.3 to 8.5, Laravel 12 supports 8.2 to 8.5, and CakePHP 5 needs 8.2 or above with 8.5 supported. Laravel gives each release eighteen months of bug fixes and two years of security fixes, so Laravel 12's bug-fix window closed in August 2026 with security fixes running to February 2027. Plan the framework upgrade before the security window ends rather than after, and use the PHP selector to pin the version your application expects.
Get PHP frameworks apps up and running in minutes with our fast, reliable web hosting. Every plan includes one-click installation, free SSL, UK, US & Asia data centres, and dedicated expert support.
All prices exclude VAT. No contract, cancel any time.
All 3 php frameworks applications available with one-click installation on our fast UK web hosting.
