A proposal to give developers back their time by moving staging off AWS.
"The build was broken on staging for two days. It worked locally. We spent hours on Slack with ops trying to reproduce it. Two days of the team blocked — and it turned out to be a config issue on their side."
Our dev team loses hours every week — not writing code, but waiting.
Waiting for builds. Waiting for ops to deploy. Waiting for access. Waiting for answers to "can you check this log?" or "can you restart that service?".
Every time a developer needs something from the staging environment, the flow breaks. They context-switch. They open a ticket. They wait. They forget where they were. They start again.
This isn't an ops team problem — they're doing their job. It's a structural problem: our staging infrastructure requires an intermediary for every action.
When auto-deploy succeeds, no ops needed. But when something breaks — tickets, back-and-forth, waiting.
| Self-hosted staging | Current (AWS + Ops) | |
|---|---|---|
| Team autonomy | Fully self-sufficient — zero ops dependency | Every infra change goes through external team |
| Ops coordination | None | Meetings, tickets, Slack back-and-forth |
| Debug a staging issue | Direct access — any port, any tool, instant | Limited by ops permissions, context switching |
| Deploy a commit | Auto-deploy on push + Dokploy for any branch/SHA (self-service) | Auto-deploy on push (ops needed when it breaks) |
| Build speed | ~2-3 min (local Gradle cache) | 25-30 min |
| Dev cycles / day | 15-20+ iterations | 2-3 iterations |
Build time per iteration
Production stays on AWS.
1 production-like AWS environment stays — for regression testing and performance testing.
The ops team stays — they continue managing production.
This only changes staging and builds — the environments where developer speed matters most and enterprise SLAs don't.
The honest answer:
What those 10 minutes look like
That's 0.1% of a working month.
Compare: the current ops coordination costs the dev team hours per week in context switching alone.
There's no cluster to manage. No Kubernetes. No Terraform. No cloud console.
It's 2 VMs running Docker containers. That's it.
Same compose.yml files we already use every day.
No new tooling to learn. No new deployment scripts to write. Dokploy just runs what we already have.
The system monitors itself.
If it doesn't work out, we go back to AWS. Nothing is lost.
~€66k annual savings • €2,627 one-time hardware • pays for itself in ~2 weeks
One server. Five weeks. The team stops waiting.