Skip to main content
Handbook/Ship/Page 121 · Deployment

Going to Production

Share

Share this page

Pass it to someone who needs it.

Star on GitHub

Key takeaway: Ship to real infrastructure

Chapter 13 of 15 · Ship

Deploy to production on real infrastructure

This is the big one. Everything so far was built and tested on your machine; now it goes live on real infrastructure, with real environments, real releases, and a safe way back if a deploy goes wrong.

By the end of this part, you can:

  • Deploy your app to real production infrastructure
  • Run separate dev, staging, and production environments
  • Release with one command and roll back with another
  • Keep your production secrets and data safe
Done:Protect·You are here: Ship·Next:Operate

Your app works on your machine, and nobody else can open it. Production is the leap to a real server the world can reach. This chapter gets you there. It also hands you the one mindset that makes every later step in this part sane: the whole setup is rebuildable from files, never clicked together by hand.

13.1.1Production is rebuildable, not clicked

Production is not a machine you configure by hand and hope never dies. Anything you set by clicking around in a dashboard is gone the day that server does, and you are rebuilding it from memory.

Real production is described in files. You run those files and the whole setup comes back, identical, on a fresh machine. That single idea is what the rest of this part builds, so treat every by-hand click as a note you still have to turn into a file.

13.1.2Pick a host you can afford to keep

The honest default is cheap, own-the-metal hosting, not the big-cloud maze. A small server on a provider like Hetzner costs a fraction of the same box on a hyperscaler. You also stop paying a tax for a hundred managed services you will never touch.

Rule of thumb: skip the AWS managed maze unless you have a specific reason to be in it. If you must be on AWS, a plain server (an EC2 box) beats wiring ten services together to run one app.

Default to a cheap box; only a specific reason justifies the AWS maze.

13.1.3Deploy by hand once, then never again

The first time, do it by hand. Stand up a server, point a domain (the web address people type) at it, turn on HTTPS, then get the app running and open it from another device. Doing it once shows you every moving part, and automating a thing you have never done by hand only hides where it breaks.

Then you never do it by hand again. Every step you just took becomes a file in the chapters that follow, and from then on a deploy is one command, not a lost afternoon.

This prompt turns your first deploy into a written plan:

Ready prompt
Act as a senior engineer planning my first production deploy. Read my spec, my non-functional targets, and my .env.example, so the plan covers every service and variable the app actually needs. For my stack and chosen host, lay out the smallest real path to live: the server, the domain and TLS, how the app runs, how migrations run, and how I reach it. Keep it manual for now, and mark which step becomes a file I automate later. Say plainly if my targets rule this host out, then log the host choice and its reason in my decision log. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/ship/deploying-to-production My stack and host:

Do this now: paste the prompt, get your manual deploy plan, and stand the app up on a real host once, by hand.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Star on GitHubContribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license