Overview

An environment defines the isolated deployment context and rule configuration logic within a workspace. Each environment represents a configuration variant of your application or service at a specific stage of its lifecycle, such as development, testing, or production. By bringing branch-like isolation, automated promotion checks, and configuration safeguards directly to content delivery, teams can safely iterate, validate, and deploy changes without affecting other environments.

With environments, you can:

• Develop in isolation, enabling multiple teams to work on separate features at the same time.
• Test and validate changes on real infrastructure before promoting them to production traffic.
• Promote configuration changes intentionally, with a clear audit trail.
• Roll back to a previous environment state if anything goes wrong.

Environment profiles

Environments are defined by immutable profiles that act as blueprints for application lifecycle stages. These profiles dictate the infrastructure routing, target networks, and persistence characteristics:

• Production. For environments serving live, end-user traffic. These are persistent deployments that can be activated on both the Akamai staging and production networks. Each workspace is limited to only one production environment.
• *Testing. Assigned to long-lived, persistent non-production context used for regression testing, performance evaluation, and pre-production validation. Unlike ephemeral development setups, a testing environment runs continuously until you manually deactivate it, providing a stable target for end-to-end CI/CD pipelines. Testing environments have access to both the staging and production networks to maintain feature parity.
• *Development. Assigned to short-lived, ephemeral non-production contexts designed for rapid, iterative feature branch development. It uses header-based routing for testing, eliminating the need for manual DNS or certificate management. Development environments carry a 30-day default lifespan with automatic cleanup, though you can extend or reactivate them at any time.

🚧

Beta limitation

Only a single production environment is supported during the initial beta phase. Additional non-production environments will be supported at a later stage.

Environment components

An environment functions as a container that brings together localized rules and references to global, workspace-level components.

Environment-level components:

• Settings and local rule sets. Every environment version contains a rule configuration composed of a default rule set optimized for your product and optional custom rule sets.
• Network. Each environment profile has access to one or both of Akamai’s production or staging networks. The profile you choose defines which networks you have available for environment activation.

Referenced workspace-level components:

• Service hostname sets. Public-facing domains organized into sets at the workspace level and mapped to environments through routes. To pass traffic, you need to activate service hostname sets and their routed environments on the same network.
• Origins. The server where the authoritative version of your site, application, or content lives. Origins are defined at the contract level and can be shared across workspaces and environments.
• Variables. Value-based containers declared globally at the workspace level to allow parameterization. Environments can implement local variable overrides to inject stage-specific logic.
• Shared and platform rule sets. Beyond inline rules, environments can reference contract-level shared rule sets or platform-level rule sets to import standardized configurations.