Dark launch
A dark launch deploys a feature's code to production while keeping the feature hidden from users, so the team can run it against real data and real load before anyone sees it. The new path is exercised quietly, often alongside the old one, and its results are checked and then discarded. Only afterwards is the feature switched on.
The longer version
Hiding is usually done with a feature flag that is off for everyone, or with an endpoint nothing links to. More thorough versions use shadow traffic: each real request is served by the existing code as usual and also copied to the new code, whose answer is compared with the old one and thrown away. A search rewrite can be run this way for weeks, with every result set compared and every slow query logged, before a single visitor sees one of its pages.
The aim is to find what staging cannot show: the volume, the odd data, the slow third-party call. Nobody is exposed to a defect, so the feedback has no cost in customer trust. The price is paid in load, since the system does extra work for results nobody sees, and in care. A copied request that sends an email or charges a card does it twice, so the shadow path has to be stripped of side effects, and any writes it makes must go somewhere harmless.
A dark launch ends when the flag is turned on, and that moment is the start of a canary or a phased rollout, since the change meets real users for the first time. The two are linked in sequence. The dark phase checks that the code survives production, and the later stages check that people want and can use what it does, which dark traffic cannot tell anyone.
Common questions
What is a dark launch?
A dark launch is putting a feature's code into production with the feature hidden from users. The team runs the new code against real traffic and data without showing the result to anyone, then turns the feature on once it has held up under real conditions.
Should a dark launch come before a canary release?
A dark launch often comes first when the change is risky under load. In a dark launch no user sees the new behaviour, so the test is of the code under real load, while in a canary release a small share of real users does see it, so the test includes how they react. Teams commonly run a dark launch first and a canary second.
What is shadow traffic?
Shadow traffic is a copy of real production requests sent to a new version of a service in addition to the live one. The new version processes the copy and its answers are compared with the live version's, but they are never returned to the user. It is a common technique for dark launches of back-end changes.
What are the risks of a dark launch?
The main risks are side effects and cost. A duplicated request can send a second email, charge a card twice or write to a shared database, so the shadow path must be isolated. The extra work also adds real load to production, which has to be capacity-planned for the length of the test.
How does a dark launch relate to feature flags?
A feature flag is the usual mechanism for a dark launch, because it lets the code ship switched off and be enabled later without another deployment. The dark launch is the practice of using that hidden period to test under real load, and the flag is what hides the feature during it.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.