Dark Launch
A dark launch deploys and exercises new code in production without exposing its output to users, validating behavior on real traffic before a visible release.
Definition
A dark launch ships code to production but keeps it invisible to users. The new path may be invoked in parallel, fed mirrored traffic, or run behind a disabled feature toggle. The team observes correctness, latency, and resource usage on real data before enabling the user-facing behavior.
Context and scope
Dark launches are used for risky rewrites, new recommendations, and performance-sensitive paths where staging data cannot reproduce production conditions. They reduce release risk without exposing unfinished behavior.
Common misconceptions
- Dark code has no side effects — it may write, charge, send, or mutate unless explicitly isolated
- A dark launch is the same as shadow traffic — dark launch is the broader idea; shadowing is one technique
- If it runs in production, users cannot be affected — resource use, shared caches, and side effects can still leak
Anti-patterns
- Enabling writes, emails, or payments in the dark path
- Comparing only success rates and ignoring latency and resource cost
- Leaving dark code running forever without a decision to launch or remove it
Related concepts
Authoritative source
Run the code without showing the result
A dark launch executes the new path in production but discards or hides its output. The team can compare the new result with the current result, measure latency, and catch data-shape errors that staging missed. Users see the old behavior until the team explicitly enables the new one.
request -> old path -> user response
-> new path (dark) -> log/compare onlyThe new path must be side-effect free. If it writes to the database, sends notifications, or charges a card, it is not dark; it is a live feature with a hidden UI. Isolate writes behind a sandbox, a separate table, or a disabled branch.
Compare, do not just execute
A dark launch is valuable when the results are compared. Log the new output, compare it with the current output, and measure differences and latency. A new path that runs but is never compared provides little evidence. Define the comparison metric before launch, including tolerance for expected differences.
Control cost and risk
Running two paths doubles work for the affected requests. Bound the sample, monitor CPU and dependency load, and stop the dark path if it degrades the user-facing path. A dark launch must not become an unowned permanent workload. Decide at the end: launch, iterate, or remove.
When to use it
Use a dark launch when production data and traffic are necessary to validate a risky change and the new path can be made side-effect free. The advantage is real-world evidence with low user risk; the drawback is duplicate resource use and comparison complexity. Compared to a canary, it hides output entirely; compared to staging, it tests the real system.