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 as a worker process

The panel can keep a command running for you, and restart it if it exits. Open the site, then Advanced and Worker processes, click Launch, pick Laravel, and set the command to php artisan schedule:work with the working directory that holds artisan. The scheduler now runs every minute on its own, with its log under the worker card.

If you prefer cron, the classic single entry still works on every plan:

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

Either way it is one entry, not one per scheduled task.

Queues run as worker processes too

php artisan queue:work is designed to run forever, and worker processes are built for exactly that. Launch a second Laravel worker with php artisan queue:work --tries=3 and the same working directory. It starts with the site and comes back if it dies, which is what Supervisor did for you on a VPS.

The queue worker and scheduler guide walks through the form and the mistakes that stop a worker from starting. Horizon, Reverb and Octane have their own guide.

If you would rather not run a permanent process, a cron entry with php artisan queue:work --stop-when-empty --max-time=55 drains the queue once a minute and exits. For a low traffic app that is still fine.

Deploying

The panel can deploy straight from a GitHub repository, on every push or when you press the button, running your build script inside the site’s container. The GitHub deploy guide covers the setup and the build script that carries .env forward between releases.

Without that, 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, worker processes, GitHub deploy, 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 on Linux and WordPress, and are on every Laravel Hosting plan, so if your queue or cache configuration expects Redis, or you want Horizon, look at a Laravel plan.