How to deploy Laravel on an Ubuntu VPS

By Andrea Pollastri · Last updated: August 4, 2026 · free to read, no paywall

A $5–7/month VPS is still the cheapest, most flexible way to run Laravel in production — if you set it up properly. This guide walks through the full production stack, every manual step, the one-command alternative, and the operational habits that keep a server healthy for years.

Why a VPS (and when not)

Shared hosting can't run queue workers, WebSockets or Laravel Octane properly, and managed PaaS platforms charge for convenience with usage-based pricing. A VPS from Hetzner, DigitalOcean, Vultr or Linode gives you root access, predictable billing and enough headroom to host several Laravel apps on one machine.

• Sizing: 1 vCPU / 2 GB RAM is a comfortable starting point for a production app with a database, queue worker and cache on the same box. Add swap on anything under 4 GB.
• Ubuntu version: use a current LTS — Ubuntu 24.04 or 26.04. Skip interim releases for production.
• When not to use a VPS: if nobody on the team can respond to a server alert, a managed platform like Laravel Cloud is the safer trade — you pay to make operations someone else's problem.

The production stack, explained

Every production Laravel server converges on the same components. Understand what each piece does before you automate any of it:

The manual setup, step by step

This is the honest, unabridged checklist. Budget 2–4 hours the first time, and remember you'll own every one of these choices at upgrade time too.

1. Create a sudo user and lock down SSH. adduser deploy, install your public key, then disable root login and password auth in /etc/ssh/sshd_config.
2. Enable the firewall. ufw allow OpenSSH http https then ufw enable. Install Fail2ban for SSH brute-force protection.
3. Install Nginx. apt install nginx.
4. Install PHP. Add a maintained PHP repository, then install php8.x-fpm with the extensions Laravel needs: mbstring, xml, curl, zip, intl, mysql (or pgsql), redis, gd, opcache.
5. Tune PHP for production. Enable opcache, set sane memory_limit and upload_max_filesize, turn expose_php off.
6. Install Composer globally.
7. Install MariaDB, run mariadb-secure-installation, create a database and a dedicated user per app — never reuse root.
8. Install Valkey (or Redis) for cache, sessions and queues.
9. Write the Nginx server block. Document root points at current/public, try_files falls back to index.php, FastCGI passes to the app's PHP-FPM socket.
10. Ship the code. Clone into a releases/ directory, composer install --no-dev --optimize-autoloader, copy .env, run php artisan key:generate, storage:link, and fix permissions so only storage/ and bootstrap/cache/ are writable.
11. Migrate and cache. php artisan migrate --force then config:cache, route:cache, view:cache.
12. Configure Supervisor to run php artisan queue:work (or Horizon) and restart it on every deploy.
13. Add the scheduler cron: * * * * * php artisan schedule:run.
14. Issue TLS certificates with Certbot and force HTTPS.

Now multiply by every app you host, and again by every server — and keep PHP, Nginx and the OS patched forever. It's all doable; it's just undifferentiated work.

The one-command alternative

Everything in the previous section is exactly what Cipi automates. On a fresh Ubuntu 24.04/26.04 VPS:

In about ten minutes you get the full stack — Nginx, PHP, MariaDB, Valkey, Supervisor, UFW, Fail2ban, Certbot, Deployer — plus hardening you'd otherwise do by hand: root login disabled, key-only SSH for the admin user, and a random root password stored in /etc/cipi/server.json. Then each app is one more command:

That provisions an isolated system user, PHP-FPM pool, Nginx vhost and database per app, connects GitHub or GitLab with deploy keys and webhooks for zero-downtime Git deploys, and wires queue workers and the scheduler. SSL is cipi ssl install; PostgreSQL is cipi db install pgsql. See the getting started guide for the full walkthrough, or the comparison hub if you're evaluating it against Forge, Ploi and friends.

Post-deploy operations that matter

Getting to "it works" is half the job. These habits are what separate a server that lasts years from one that surprises you:

• Backups you have actually restored. Automate database and storage backups to S3-compatible storage (cipi backup configure handles schedule and retention). Any S3 target works — including Johnny, an open-source S3-compatible object storage you can run on a second VPS for genuinely independent off-site copies. Do a restore drill quarterly: an untested backup is a hope, not a plan.
• Exception tracking from day one. Production errors need to reach you before users do. Boogle is a self-hosted exception tracker that keeps error data on your own infrastructure — a good fit if you chose a VPS for data ownership in the first place.
• Health checks and logs. Cipi 5 ships app health checks, and cipi app logs tails Laravel, Nginx and deploy logs without SSH gymnastics.
• Patching discipline. Unattended OS security updates plus a deliberate PHP upgrade path (cipi php upgrade manages PHP security patches with a weekly check) beat "we'll update when we remember".
• Tame your SSH sprawl. Once you run more than two servers, connection details rot in your shell history. Conn is a tiny Bash tool that manages servers as named aliases — pairs nicely with a fleet of Cipi machines.

Common mistakes to avoid

• Deploying as root. One compromised app owns the whole box. Use per-app users — this is why Cipi isolates every app under its own system user.
• APP_DEBUG=true in production. Debug pages leak env vars, credentials and paths. It's the single most common self-inflicted Laravel breach.
• Committing .env or leaving .git/ web-accessible.
• 777 permissions "to make the error go away". Only storage/ and bootstrap/cache/ need to be writable by the runtime user.
• No queue worker. Mail and jobs silently pile up in the queue table forever.
• Skipping opcache — free 2–3x throughput lost.
• No swap on small instances — Composer and asset builds OOM-kill at the worst time.
• Untested SSL renewals. Certificates auto-renew until the day they don't; monitor expiry.

Frequently asked questions

Keep reading