Akamai Sandbox

Overview

Every day, developers write code and spin up development environments for new feature requests or bug fixes. But often those features or bug fixes are untested, simply because there is no way for developers to replicate their complex production environment within their dev environments.

We’ve heard from multiple customers who have requested a local Akamai server environment where they can test their changes locally before promoting the changes over to their Akamai production environment. This mode of testing can reduce the risk of finding issues later in the development cycle and improves development velocity.

get started now

Introducing Akamai Sandbox

Akamai Sandbox is an isolated Akamai environment (i.e., a sandbox) that you can use for testing development versions of property configurations before deploying to the content delivery network.

With Akamai Sandbox, individual developers or dev teams can spin up concurrent and isolated Akamai sandboxes quickly to rapidly test Akamai configurations in their development environment, while accessing origins running locally or behind a firewall.

Key benefits

• Quick provisioning and easy setup: Quickly provision a sandbox within minutes by either referring to an existing config or cloning an existing sandbox.

• Isolated and concurrent Akamai sandboxes: Create up to 100 concurrent active sandboxes with the same hostname so different teams can work on their sandboxes independently.

• Reduced risk of production issues: Sandbox helps developers simply and efficiently check their work for any problematic issues prior to promoting their code to production.

How it works

In the flowchart below, you can see how the four main stages of the Sandbox request-response flow work, starting with the user’s (i.e., developer’s) laptop. The four stages are:

1. Request from browser
2. Request from sandbox
3. Response from origin
4. Response to browser

Different setup configurations for Sandbox

Sandbox was designed for the different types of development environments customers have today. Following are the three configuration models our customers requested for different types of environments.

• Local and Containerized Model: Customers who have their entire web application stack running locally in containers or behind the firewall can spin up an Akamai environment by choosing to run the Sandbox client locally within their laptops or within a machine that has access these local instances.
• Cloud-Based Model: Organizations that have embraced the cloud and spin up thousands of dev environments or microservices per week can now spin up an individual Akamai environment alongside these dev environments or microservices by choosing to run the Sandbox client as another microservice within their architecture.

• Hybrid Model: Customers who have a combination of both cloud-based microservices and locally contained instances can choose to run the Sandbox client in a machine that has access to both of these environments.

Get started

All Akamai web customers get access to 100 sandboxes each. View the Sandbox user guide to see the quickest ways to set up your own sandboxes.

Limitations

As of October 2018, sandboxes created with Akamai Sandbox will only provide users the ability to modify an Akamai delivery configuration. These sandboxes are designed to work across all Akamai web delivery products, including Ion, Dynamic Site Accelerator, Rich Media Accelerator, Terra Alta, Web Application Accelerator, Aqua Ion Mobile, and Dynamic Site Delivery.

However, if users have certain Akamai products (Web Application Protector, Kona Site Defender, Bot Manager, or API Gateway) tied to their configs, Akamai Sandbox cannot apply rules or policies associated to these products against Sandbox traffic.

Also please note that, for this early phase of the product, Akamai has disabled HTTP/2 connections to sandboxes by actively removing HTTP/2 behaviors from Sandbox configs.

Additional resources