Running Laravel on your own DigitalOcean droplet, without Forge

Laravel Forge exists because configuring a DigitalOcean droplet correctly — Nginx or Octane, PHP-FPM, a queue worker, the scheduler, TLS, zero-downtime deploys — is real work that most teams would rather pay to skip. The part worth separating out: that configuration work is a one-time problem, not a reason to pay a recurring fee on top of the droplet you’re already paying DigitalOcean for.

What actually needs to happen on the droplet

Every one of these is real setup, not optional polish: composer install, php artisan migrate --force before the new code takes traffic, APP_KEY generated and kept stable across deploys, a queue worker running alongside the web process without stepping on it, php artisan schedule:run firing on time, and a zero-downtime swap so a deploy doesn’t drop requests mid-release.

Connecting your own droplet

Servers → Add a server → Create on your cloud → DigitalOcean

A personal access token from DigitalOcean’s control panel (API → generate a token with read and write access) is all that’s needed — Railyard provisions the droplet directly in your own DigitalOcean account, at DigitalOcean’s own price, with no markup. s-1vcpu-2gb (1 vCPU, 2 GB) is a reasonable starting size for a single Laravel app; Frankfurt or Amsterdam if the data needs to stay in the EU.

Already have a droplet running? Bring your own server works the same way against any Ubuntu 22.04/24.04 box with passwordless sudo and ports 22/80/443 open — no need to provision a fresh one just to connect it.

What happens once the repo’s connected

railyard create my-app https://github.com/me/my-app --addons mysql,redis

composer.json and .env.example are read to fill in the database engine, php artisan migrate --force as the release step, and APP_KEY generated once in Laravel’s own format. laravel/horizon or laravel/octane installed gets detected and wired up the same way — see the full Laravel docs for the exact detection rules. Every push after the first rebuilds and redeploys on the same droplet, with the zero-downtime swap handled automatically.

The actual comparison

Forge’s value is real — it’s solving exactly the problem above. The question worth asking is just where that value should live: as a markup on every droplet forever, or as a one-time platform choice on infrastructure that’s already yours either way. Either path ends with a working, properly configured droplet; only one of them keeps charging after the configuration is done.

Full reference: Laravel docs, Add a server.