Deployment in Coder¶
The Hardest Part of Shipping¶
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 six 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 to obtain an ATO. What you're using today isn't a toy — it's a pattern for how continuous delivery works in environments where security and compliance are non-negotiable.
That pipeline is the foundation for continuous delivery — the practice of keeping your application in a deployable state at all times so that every change can reach users immediately. Continuous delivery matters because outputs mean nothing if they don't change user behavior. You can build the most sophisticated analysis engine in the room, but if it never gets in front of real users, you can't validate whether it actually helps anyone make better decisions. You can't have impact unless you actually change behavior — and you can't change behavior from a development machine.
Why This Matters Now¶
The instinct for experienced practitioners is to build first, deploy later. The risk: you build for a full day on assumptions about data formats, threshold values, and alert logic, and only discover at the end that the deployment pipeline doesn't work or your assumptions were wrong.
Deploying something simple now — even a hello world page — gets you three things:
- Pipeline verification. You confirm deployment works before adding complexity. If it breaks later, you know it's something you changed.
- 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 — you're shipping continuously.
- 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.
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 Avalanche Forecast Analysis Engine — just a title, a short description of what it will do, and a placeholder for the 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 — you'll use it throughout the day to verify features as you build them. That URL is now your continuous delivery endpoint. Every change you make from here can be live within minutes.
Key Insight¶
The hardest part of shipping isn't building — it's getting from development to production. Continuous delivery means keeping your application deployable at all times so that every change can reach users immediately. In government contexts especially, this is often the bottleneck that kills impact. Your Coder workspace removes that bottleneck. Deploying a hello world page now proves the pipeline works and establishes the habit: build, test, deploy, validate. Outputs don't matter if they never reach users.