What Is Dark Launch? Definition & Examples

Dark launch is a software release method where new code is deployed but kept hidden from most or all users. The feature is controlled by configuration flags, routing rules, or gradual exposure, so teams can test behaviour in production before full release without changing the deployed version.

How Dark Launches Work

Dark launch is a release pattern that separates deployment from exposure. New code is placed into production, but routing, feature flags, or configuration keep it invisible or inactive for most users until the team chooses to reveal it.

This approach lets teams validate real production behaviour without committing to a full rollout. It is especially useful when the change touches performance-sensitive flows, complex dependencies, or customer-facing paths where a staged reveal reduces release uncertainty.

Why Teams Use Dark Launches

The main value of a dark launch is control over when users experience change. Teams can confirm that code runs correctly in the live environment, observe how it behaves under real load, and compare outcomes before making the feature generally available.

That separation also supports safer experimentation. A team can expose a feature to a small audience, a specific tenant, or internal testers while the code is already deployed, which makes validation faster than waiting for a full production release cycle.

Operational Patterns Behind the Technique

Dark launches usually rely on feature flags, conditional routing, environment-aware configuration, or gradual exposure controls. Those mechanisms let the same deployed version behave differently depending on who receives traffic or which path a request takes.

The pattern is often paired with telemetry so teams can observe latency, error rates, and behavioural differences before expanding exposure. That visibility matters because the feature may appear dormant to users even though it is active in production behind the scenes.

A dark launch is not the same as a simple internal test build. The important distinction is that the code is already running in the production environment, so operational assumptions, dependencies, and rollback behaviour should be treated as production-grade from the start.

Common Trade-offs and Failure Modes

Dark launches reduce release risk, but they introduce control complexity. Hidden code can still consume resources, trigger background work, or interact with shared services, so a feature that is “off” to users may still create load, defects, or unexpected side effects.

They also depend on the flag or routing layer being trustworthy. If those controls are misconfigured, the feature may expose prematurely, remain permanently hidden, or behave inconsistently across users and environments, which can complicate testing and incident response.

Risk and Threat Considerations

Dark launch mechanisms can become a security and operational blind spot when hidden functionality is left enabled in production longer than intended, or when feature-flag logic becomes complex enough that teams lose track of what is actually reachable. The risk is less about the release method itself and more about the extra control plane it creates around exposure, authorization, and observability.

Failure mechanism: A bypassed flag, stale configuration, or overly broad rollout rule can expose unfinished code paths, reveal sensitive logic, or create inconsistent access conditions that attackers or testers can exploit.

Impact: Premature exposure, unexpected attack surface, and harder incident triage, especially when logs and monitoring do not clearly show which code path was active for which users.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.PS-01 — Configuration Management	Dark launch depends on controlled production configuration and rollout state.
	DE.CM-01 — Monitoring of Networks, Systems, and Assets	Dark launches need telemetry to confirm behaviour while exposure is limited.
Recommendation — Track feature-flag and rollout settings as production configuration items. Monitor production behaviour while the feature remains partially hidden.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Feature flags and routing rules are configuration controls that shape exposure.
Recommendation — Harden and review rollout configurations before expanding access.
OWASP SAMM	SAMM — Software Assurance Maturity Model	Dark launch is a software delivery practice that benefits from mature release governance.
Recommendation — Embed release-gating, validation, and rollback checks into delivery practice.
SLSA	SLSA — Supply-chain Levels for Software Artifacts	The release pattern assumes trustworthy build and deployment provenance for code already in production.
Recommendation — Verify artifact provenance before exposing deployed code paths.

Practitioner Guidance

Why practitioners should care: Dark launch works best when the deployment pipeline, flag governance, and observability model are treated as part of the release itself, not as afterthoughts. The hidden feature still needs ownership, review, and rollback discipline because it is already living in production.

Common misunderstanding: Teams sometimes assume that an undisclosed feature is harmless until it is publicly enabled. In practice, any code that is deployed, wired into routing, or partially reachable can affect performance, data handling, and security posture before the official launch date.

Dark Launch