How to run Laravel on shared hosting

You can, provided the host gives you four things: SSH, Composer, a per-site PHP version, and real cron. Without those you are uploading files by FTP and hoping, which is where the “Laravel needs a VPS” advice comes from. It is advice about bad shared hosting, not about Laravel.

Here is what actually matters once you have them.

Point the document root at public

Laravel expects the web server to serve its public directory, not the project root. If you upload the project so that the root is served, everything above public becomes reachable over the web, including your .env file with the database credentials and the application key in it.

Set the site’s document root to the project’s public folder. Do not solve this by moving index.php up a level and rewriting the paths inside it, which is a widely copied trick that puts the whole framework back inside the web root.

Use localhost for the database, not 127.0.0.1

This one costs people an afternoon, and it is specific to hosts that isolate each site properly.

When every site runs in its own container, 127.0.0.1 refers to that container’s own loopback, and the database is not in there. Laravel then fails to connect with an error that looks like the credentials are wrong when they are fine.

In your .env:

DB_HOST=localhost

localhost resolves through the socket the site is actually allowed to use. 127.0.0.1 forces a TCP connection to a place with nothing listening. If your app connects locally but not after deploying, check this before you check anything else.

Run the scheduler with one cron entry

Laravel’s scheduler is driven by a single cron job that fires every minute. Everything you registered in the application gets dispatched from it:

* * * * * cd /path/to/your/site && php artisan schedule:run >> /dev/null 2>&1

Add that once. You do not add a cron entry per scheduled task, which is the mistake that produces a crontab with fifteen lines in it.

Queues need care on shared hosting

php artisan queue:work is designed to run forever, and shared hosting is not the place for a permanently running process. Use the version that finishes:

* * * * * cd /path/to/your/site && php artisan queue:work --stop-when-empty --max-time=55

It drains whatever is waiting, then exits before the next minute starts. For most applications, jobs processed within a minute is entirely adequate. If you genuinely need sub-second processing of a constant stream, that is the point where a VPS earns its price, and you should move.

Deploying without a pipeline

With SSH and Composer available, a deploy is the usual sequence:

git pull
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

Two warnings. Run config:cache only after the .env is correct, because caching reads it once and freezes the result, and a stale config cache produces bugs that survive you fixing the actual setting. And if a deploy leaves the site broken in a way that makes no sense, clear the cached bootstrap files before debugging anything else.

Permissions

storage and bootstrap/cache must be writable by the web user. If you see a permissions error on a fresh deploy, that is nearly always it. Do not fix it with chmod -R 777, which makes those directories world writable on a server you share.

What you get on our plans

SSH with a real terminal, Composer, Git, cron, and a per-site PHP selector from 5.6 to 8.5 are on every plan, including the entry tier. Private Redis and PostgreSQL start at the Business tier, so if your queue or cache configuration expects Redis, that is the tier to look at.