Dark Launch

A dark launch releases code or a backend path into production in a hidden state. Real requests exercise it, often through traffic mirroring or a feature flag, but its results are not shown to users.

Why it matters

Staging environments rarely match production load or data. A dark launch lets you observe latency, error rates and resource use under real conditions before anyone depends on the feature. If something misbehaves, you turn it off, and users never saw it. It is related to canary releases, but the difference matters: a canary exposes a small share of users to the new version, while a dark launch exposes none.

Example

A new search service runs alongside the old one. The application calls both, returns the old result, and logs the comparison:

result_old = search_v1(query)
if flag("search_v2_shadow"):
    result_new = search_v2(query)   # not returned
    log_diff(result_old, result_new)
return result_old

After a week of matching results and acceptable latency, the team ramps the flag to real users.

Common mistakes

• Shadow traffic that triggers side effects such as emails or payments twice.
• Doubling load on a shared database without capacity headroom.
• Never cleaning up the flag and the dead code path afterward.

Related

• Feature flag
• Canary release
• Blue-green deployment
• Rollback

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.