Deployment in Coder¶
The Deployment Bottleneck¶
In most government contexts, getting from a development machine into production is the single biggest bottleneck. Teams build for months before discovering that the deployment pipeline doesn't exist, isn't approved, or requires weeks of paperwork. By the time something reaches users, the assumptions baked into it are stale.
Your Coder workspace eliminates that bottleneck. It comes with a deployment pipeline already configured — no Docker setup, no CI/CD YAML files, no infrastructure provisioning. You ask your AI coding assistant to deploy, tests run automatically, and if they pass, the application goes live at a URL you can share.
For our lab purposes, we don't have a rigorous Authority to Operate (ATO) process. But the pipeline itself is built with the kind of security scanning, vulnerability checking, and compliance gates that a production government system would require. What you're using today is a pattern for how continuous delivery works in environments where security and compliance are non-negotiable.
Why Deploy First¶
The instinct — especially at this experience level — is to build first and deploy later. The system-level risk: you build an entire platform on assumptions about data formats, normalization logic, and cross-center integration, and only discover at the end that the deployment pipeline doesn't work or your assumptions were wrong.
Deploying something minimal now gives you three things:
- Pipeline verification. You confirm deployment works before adding complexity. If it breaks later, you know it's something you changed — not the pipeline itself.
- Continuous delivery from the start. Every feature you add after this is immediately deployable. You're not building toward a big-bang deployment at the end.
- The feedback loop is live. A deployed application is one you can share, test in a real browser, and validate against real conditions. The gap between "it works on my machine" and "it works for users" closes to zero.
When you're designing systems at scale — which is what this track is about — that feedback loop is the foundation everything else builds on. Evals, quality gates, and self-healing pipelines all depend on a deployment pipeline that works.
Team Activity: Hello World Deployment¶
Format: Mob Session Time: ~2 minutes Setup: One person drives, everyone navigates.
Ask your AI coding assistant:
Create a simple landing page for our Multi-Center Avalanche Operations Platform — just a title, a short description of what it will do, and a placeholder for the unified dashboard. Then deploy it and give me the URL.
Claude Code builds the page and runs the pre-configured deployment pipeline. You'll see tests execute, then get a live URL.
Codex builds the page and executes the same pipeline. The deployment command and URL format are identical.
pi builds the page and runs the deployment through the same pre-configured pipeline.
Verify the deployment loads in a browser. Bookmark the URL — this is your continuous delivery endpoint for the rest of the lab. Every change you make from here can be live within minutes.
Key Insight¶
Continuous delivery means keeping your application deployable at all times so that every change can reach users immediately. In government contexts especially, the deployment pipeline is often the bottleneck that kills impact. Your Coder workspace removes that bottleneck. Deploying now proves the pipeline works and establishes the rhythm: build, test, deploy, validate. When you're designing systems that multiple contributors operate simultaneously — which starts in Lift 2 — that rhythm is what keeps the system coherent.