Stand up a host you control — Dokploy on Hetzner or on-prem — and promote to it safely
Self-hosting means your data never leaves infrastructure you control — a rented EU server (Hetzner) or your own on-prem hardware, running a stack like Dokploy so you get auto-deploys without handing anyone your data. But a private host is only as safe as your deploy discipline: once it has real users, the riskiest move is editing the live site directly. The fix is two environments: production (live, what users see) and a private staging copy you can break. Taught as weak → strong pairs — land changes on staging, verify them, and promote only what you have checked. The advanced example is how this very curriculum site is set up: a staging branch → a private Tailscale preview → merge to main → live.
Because it keeps your data inside infrastructure you control, whether that’s a rented EU server or your own hardware, so no third party ever sees it.
By using two environments—a production version for users and a private staging copy where you test changes before promoting them to live.
Develop on a staging branch, preview it through a private Tailscale link, merge to main once verified, then the change goes live automatically via Dokploy.
One to break, one to trust
Deploy straight to a US-hyperscaler PaaS and hope the data-residency question never comes up.
Rent a Hetzner (or similar EU) server, or use existing on-prem hardware, and run a self-hosted platform like Dokploy on top of it — auto-deploys and a dashboard, but the host stays yours.
Edit the live site directly and hope the change is fine.
Run two copies: production (live, what users see) and staging (a private copy that mirrors it). Make every change on staging first; promote only what you have checked.
Test on your laptop with a different OS, database and config, then deploy to a totally different prod.
Build staging from the SAME image/Dockerfile and config as prod, changing only what must differ (the URL, secrets). Then "passes on staging" really means "will pass in prod".
Point staging at the production database, so a test run quietly mutates real user data.
Give staging its own data. Share a prod resource only on purpose and record it. (This site shares exactly one thing — a vanity hit-counter — and nothing that matters; it is noted in DEPLOY.md.)
Stage it, don't edit prod
git push origin main # straight to the live site
git push origin staging # auto-builds the private :3012 preview; main (prod) is untouched
SSH into the prod server and re-make the change there by hand.
Merge staging → main. The byte-for-byte change you checked on staging is what builds for prod; no hand edits, no drift.
It's urgent — push the fix straight to prod, no time to test.
Make the hotfix on staging, glance at :3012 to confirm it works, then promote. The one-minute detour is what stops a 2am one-character outage.
Don't trust the push
CI is green, so the new version must be live.
curl the deployed /version.json (or the changed page) and confirm the build/SHA actually advanced before you call it done.
The diff looks right, so merge it to prod.
Open the staging URL, click the actual button / read the actual paragraph you touched, and confirm it behaves — then promote.
If prod breaks after the merge, start figuring out how to undo it.
git revert HEAD && git push origin main # prod rebuilds the previous version automatically
A fresh Linux VM that will host your private services.
You will have an SSH‑accessible server with Docker installed ready for deployments.
docker version showing client and server details, confirming Docker is ready.Dokploy is an auto‑deploy dashboard that runs on your own VM and pulls builds from Git.
Run a Dokploy instance on a rented EU server you control
curl -fsSL https://dokploy.com/install.sh | sh to install Dokployhttp://<server‑ip>:3000 to view the dashboardA long‑lived staging branch that triggers private preview builds while the main branch represents live production.
Create two independent deployments—one for staging, one for production—each linked to its own branch
Nextcloud, an open‑source file sync and collaboration platform.
You will have a running Nextcloud instance accessible via a web browser.
docker pull nextcloud/all-in-one.docker run -d -p 80:80 -v /path/to/data:/var/www/html nextcloud/all-in-one.A Cloudflare Tunnel that provides encrypted, browser‑based access without opening firewall ports.
You will be able to reach your Nextcloud instance through a private Cloudflare URL.
cloudflared on the VM following the Cloudflare One clientless SSH documentation.cloudflared with your Cloudflare account using cloudflared login.cloudflared tunnel create nextcloud-tunnel and then cloudflared tunnel route dns nextcloud-tunnel .cfargotunnel.com .cloudflared tunnel run nextcloud-tunnel..cfargotunnel.com Promotion is merging the tested staging branch into main, causing Dokploy to deploy the exact artifact that passed staging.
Move a verified build from staging to production and confirm that the new version is serving live traffic
staging into main/version.json from the live site (e.g., with curl) to confirm the new build identifiergit revert on the latest production commit and redeployBitwarden, an open‑source password manager that can be run as a private service.
You will have Bitwarden running in Docker, managed from a Git repository with separate staging and production branches.
/opt/bitwarden on the VM.staging and production. Checkout staging and edit the .env file to set ADMIN_TOKEN=staging-token.docker-compose -f docker-compose.yml up -d while on the staging branch.staging into production, change ADMIN_TOKEN to a production value, and redeploy by running docker-compose down && docker-compose up -d on the production branch.Staging can corrupt real data
Staging must not be able to corrupt real data. Anything it deliberately shares with prod should be a conscious, written-down choice. The whole value of a throwaway environment evaporates if breaking it breaks prod too. Default to isolation; treat every shared resource as a decision you can defend, not an accident.
Staging differs from production → test passes don’t mean anything
Staging only predicts prod if it is built the same way. The bigger the gap, the more "worked on staging, broke in prod" surprises. The twelve-factor "dev/prod parity" rule warns about three gaps that make testing lie: the time gap, the personnel gap, and the tools gap (different stacks). Closing them is what makes a staging check trustworthy.
Pick where your private host lives
Before staging vs. production even applies, decide where BOTH copies run — a rented EU server, your own hardware, or a managed-but-private platform on top of either. A private cloud is not "no infrastructure" — it is infrastructure you can name, audit and evict data from on demand. Dokploy on a rented Hetzner box gets you most of a managed platform's convenience (git-triggered builds, one dashboard, rollbacks) while the actual server stays under your control — the same buy-vs-build trade-off the governance chapter runs, applied to the host itself.
Edit the live site directly and hope it works
Production is the live site users interact with. Staging is a private copy that resembles it — there to absorb your mistakes. A staging environment "exactly resembles a production environment" but no users are watching it — so a broken build there costs you a re-deploy, not an outage. Production is the one place a mistake is felt immediately.
Edits go to staging instead of live
A long-lived staging branch is where edits go first; pushing it auto-builds the private preview. Main stays clean until you promote. Separating the branches separates the environments. The thing on main is always "what is live"; the thing on staging is "what you are trying" — so you can never accidentally ship a half-finished edit.
The temptation to skip staging is strongest exactly when you are panicking — which is when a typo does the most damage. Urgency raises the error rate and the stakes at once. A staging pass is cheap insurance precisely when you are least careful — the rule that has no exceptions is the one that protects you under pressure.
Want to push a verified change to prod without manual edits
To go live, move the exact change you verified — not a fresh hand-made copy of it. Promotion = merge, not re-typing. Blue-green deployment makes the same point at the infrastructure level: you bring up the new version, verify it, then switch traffic to it — and switch back if it misbehaves. Promoting an artifact you already tested beats reproducing it live.
A green push and green CI mean the build compiled, not that the new version is actually serving. Confirm the deployed thing changed. Deploys fail silently in real ways — a cached image, a stalled auto-pull, a recreated container. The only honest signal is the artifact itself reporting the new version; "it pushed" is not "it shipped".
The preview tier exists to be opened. Read the page and click the exact thing you changed — do not approve from the diff alone. A diff shows intent, not result: rendering, layout, a broken link, or a copy button that silently fails only show up in the running page. Staging is where you catch those for free, before users do.
Want a quick way to undo a bad deploy
Decide how you would undo a change before you ship it, so a bad prod deploy is a 30-second revert, not a scramble. Blue-green deployments keep the old environment idle so you can "switch the router back" instantly. A revert-and-rebuild is the small-scale version of the same safety net: every promotion should have a known, fast undo.
The same set on /recipes, filtered by tool and role.
A clear, beginner-friendly explainer of why teams keep separate dev, staging, and production environments.
How real startups use a staging environment as a safety net before changes reach live users.
Control over the data and the deploy pipeline: nothing routes through a third party's infrastructure. A stack like Dokploy on a rented EU server (Hetzner) or on-prem hardware gets you back most of the managed-platform convenience — git push, auto-build, one dashboard, rollbacks — while the host itself stays yours. It costs setup time a managed PaaS would absorb for you; the trade-off is the same buy-vs-build call this curriculum makes for AI tools, applied to where the app itself runs.
Production is the live environment "users directly interact with". Staging is a pre-production environment "that exactly resembles a production environment" but is private — it exists so you can install, configure and test a change before it reaches anyone.
Because every test then risks a real outage or real data loss, in front of real users. A private staging copy absorbs the mistakes for free: you break it, fix it, and only promote what you have proven. Production should only ever see changes that already worked somewhere else.
As similar as you can make it. The twelve-factor "dev/prod parity" principle is "Keep development, staging, and production as similar as possible," and warns of three gaps that make testing lie: the time gap (code waits to ship), the personnel gap (different people deploy), and the tools gap (different OS/database/stack). The smaller the gaps, the more a staging pass actually predicts prod.
Promotion moves the exact build you verified, rather than re-making the change by hand on prod (which drifts and reintroduces bugs). Blue-green deployment is the same idea at the infrastructure level: bring up the new version, verify it, switch traffic to it — and switch back to the old one if anything goes wrong. Ship the artifact you tested.
By default, yes — staging must not be able to corrupt real data, or breaking it defeats the purpose. Share a production resource only deliberately and write it down. (This site shares exactly one harmless thing between the tiers — a vanity page-hit counter — and nothing that matters; that choice is documented.)
Check the artifact, not the push. A green push and green CI only mean the build compiled — the new version can still fail to serve (a cached image, a stalled pull, a recreated container). curl the deployed /version.json (or the changed page) and confirm the SHA/build advanced past your change before you call it done.
Private cloudDokployEnvironmentProduction (prod)StagingDev/prod parityDeployPromotionRollbackBlue-green deploymentstaging branch:3012 (Tailscale)version.json-p (compose project)Ask, share, or report — over on the Heidelberg AI community forum.