Dark launch
Deploying code to production while keeping the feature hidden, so it can be exercised safely before users are allowed to see it.
What it is
A dark launch deploys new code into production while keeping the user-facing feature off. A feature flag may expose it only to employees, or a backend may run the new path beside the old one and discard its answer. Deployment and release happen on different days, so the team can prove that the code starts, scales, and reads real production-shaped data before customers see it. Facebook's 2008 Chat launch is the canonical example: ordinary page loads quietly sent invisible requests to the new chat servers, so the backend was already carrying real load before anyone could see a chat window.
Reach for it when a large feature or rewritten service needs production traffic to reveal capacity and integration problems that staging cannot reproduce. LaunchDarkly and similar flag systems make the visible switch cheap, while shadow traffic can exercise a read-only backend path without changing the response users receive.
Gotcha: invisible does not mean harmless. Dark code can still run database migrations, consume CPU, emit duplicate analytics, or trigger emails and payments. Shadowed requests must suppress side effects, and the flag needs an owner and removal date so the hidden path does not become permanent.
Ask AI for it
Dark-launch this feature with a LaunchDarkly server-side flag named dark-feature-v2. Default it to off, allow only an explicit list of internal account IDs, and keep the current user-facing path unchanged. For the new backend path, mirror only idempotent read requests, discard its response, block email, payment, and write side effects, and label latency, error, and resource metrics with path=v2. Add a kill switch, an audit log for flag changes, and a removal date for the flag.