Deploy Laravel on Cloudways

What you will build

A Laravel application running in production on Cloudways: deployed from Git, configured through the panel, with queue workers and the scheduler up and running, which is the part Laravel deployments usually get wrong. There is a companion repository for this walkthrough, the deployment starter on our GitHub, if you want a known-good shape to diff your own setup against.

Create the server and application

Laravel is one of the application types the panel installs for you: create a server, add an application, pick Laravel. The application arrives with SSH access, Git support and a provisioned database attached, credentials visible in the application settings. PHP versions are selectable at the server level, with 8.2 the newest available as of October 2026; check what your application requires and set the server to match before the first deploy.

Get the code in and composer running

Connect the application to your repository in the panel, choose the branch, deploy. Then get dependencies onto the server: SSH into the application and run composer install with dev dependencies excluded, so vendor/ matches the server's PHP version. Your laptop's vendor directory stops mattering at this point. Keep vendor out of the repository. The lock file is the contract, and the server honours it at install time.

Database migrations run as part of the deploy, after the code lands, against the provisioned database. Watch them run the first time instead of assuming; the first migration against a fresh database is where configuration mistakes surface.

Environment variables live in the panel

Laravel reads its environment from .env, and in production the panel is where that environment is defined, application by application. Set what the framework needs: APP_ENV for production, APP_DEBUG off, APP_KEY generated and set once, the database credentials from the application settings, then mail and third-party keys as your app requires. Two rules keep this clean: production secrets never live in the repository, and the panel holds exactly one copy of each, so there is one place to rotate when a key leaks.

Storage permissions

Laravel writes logs, cache, sessions and uploads under storage/, and compiled views under bootstrap/cache. Both directories need to be writable by the web server. On a fresh deploy this is the classic breakage: the site loads, then dies the first time it tries to log something or compile a view. Via SSH or the panel's file manager, set the write permissions for the web server's user on those two directories, then confirm by loading a page that compiles views and checking that a log entry appeared.

Queue workers and the scheduler

Background work is where Laravel deployments either come alive or decay unseen. The platform runs Laravel queue workers supervised, with process management handled on the server side, so a worker that dies comes back on its own. Your job has three parts: set the queue connection your application uses, get the worker running against it, and restart workers after each deploy, since a long-running worker keeps executing the old code until it restarts.

The scheduler needs one cron entry, and the panel has a cron job manager for exactly this: one line invoking artisan schedule:run every minute, and Laravel's task scheduling takes over from there. The failure mode is predictable. Everything works locally, where you ran the scheduler by hand, and nothing fires in production, where nobody added the entry. Add it on day one, then confirm a scheduled job fired.

First deploy checklist

Environment set in the panel and APP_DEBUG off. APP_KEY generated and set, with any key that ever touched the repository rotated. Composer install run on the server with dev dependencies excluded. Migrations run against the production database. storage/ and bootstrap/cache writable, confirmed by a log line appearing. Queue worker running, with a restart step added to your deploy habit. Scheduler cron entry added and a scheduled job observed firing. Domain pointed and TLS issued. One on-demand backup taken, so the restore story starts from a real baseline.

If a coding agent built this application and this is your first production deploy, where to host an AI-built app covers the decisions around the hosting choice itself, and the Cloudways review covers what living on the platform is like week to week.