Hosting and Deployment: Getting It Online Without Fear

Part five of the full-stack series. Everything so far — frontend, API, database, auth — runs on your laptop and helps exactly one person. Hosting is where it runs for everyone else; deployment is how your code gets there. The goal of this layer is boring on purpose: shipping should be a non-event you do five times a day without your stomach dropping.

Two questions, kept separate

People conflate these, and it muddies every decision:

• Hosting: where does it run? A server, a platform, a container somewhere.
• Deployment: how does new code get onto it? The pipeline from commit to live.

You can change one without the other — switch hosts but keep your deploy flow, or improve deploys on the same host. Keeping them separate in your head keeps the choices clean.

The hosting spectrum: control vs convenience

There’s a straight trade-off between how much you manage and how little you have to think about:

For most Laravel work I land on Forge driving a DigitalOcean droplet: Forge provisions nginx + PHP-FPM + the queue worker + TLS, and I still have SSH and full control when I need it. The next post on cloud and compute goes under the hood of what that droplet actually is.

Deployment: the rules that kill “works on my machine”

A deploy is more than git pull. A real one is a repeatable sequence:

# the shape of a zero-fuss deploy
git pull origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force          # schema in lockstep with code
npm ci && npm run build              # compiled, hashed assets
php artisan config:cache route:cache view:cache
php artisan queue:restart            # workers pick up the new code

Three rules turn that into something you trust:

1. Reproducible. Pinned dependencies (composer.lock, package-lock.json), the same build everywhere. No hand-edits on the server, ever — they vanish on the next deploy and nobody remembers them.
2. Reversible. A bad deploy must roll back in seconds. Atomic/symlinked releases (Forge, Envoyer, Deployer) flip a symlink to the new release and flip it back instantly if it’s broken.
3. Automated. Triggered by a push, not a human running commands by hand at midnight. That’s the CI/CD layer, and it’s where this leads.

Config belongs in the environment, not the repo

The one rule that spans every host: configuration lives in the environment, secrets never live in git. Same code artifact, different .env per environment.

// code reads config; values come from the environment, not the source
'key' => env('PAYMONGO_SECRET'),   // set on the server, never committed

A leaked .env in git history is a credential-rotation fire drill — the kind a pre-commit secret scan is built to prevent.

Caveats and best practices

• Migrations are part of the deploy, and they’re the risky part. Code rolls back in seconds; a destructive migration may not. Make schema changes additive and reversible — see database and storage.
• Zero-downtime or you’ll feel it. Symlinked releases + queue:restart mean users never hit a half-deployed app. A naive in-place git pull serves broken pages mid-deploy.
• Automate TLS. Let’s Encrypt + auto-renewal. An expired cert is a self-inflicted outage that pages you on a weekend.
• One environment that mirrors prod (staging). “It worked in staging” is worth the cost; “I only tested locally” is how prod breaks.

Conclusion

Hosting     → where it runs (VPS ↔ PaaS ↔ serverless: control vs convenience)
Deploy      → reproducible, reversible, automated
Releases    → atomic symlink swap = instant rollback
Config      → environment vars; secrets never in git

Good hosting and deployment make shipping forgettable — and forgettable is the goal, because a deploy that scares you is a deploy you do too rarely. Next: cloud and compute, a look at what that server actually is and who’s really running it.