Sandboxes are used to manage the base layer infrastructure of an app. Please refer to the Terraform reference for full configuration options.

What is a sandbox?

Sandboxes create a consistent, isolated environment that your application can be guaranteed to work with, across hundreds or thousands of different installs. They are responsible for defining the basic networking, permissioning, and compute primitives to power the app.

In a shared responsiblity model, a customer may provide some infrastructure in the sandbox, such as an existing network or compute cluster. In this case, Nuon sandboxes enable you to leverage this customer infrastructure, while also having a consistent way to deploy and manage your app in any account.

Sandboxes ensure you can install your app into any account - whether a completely new account with no prior provisioning, or an account with other workflows.

Sandboxes can ensure isolation, reproducability and repeatability with each install - regardless of the account.

Configuring a Sandbox

To configure a sandbox, specify a repo and the correct parameters for your sandbox.

You can configure sandboxes to use either a public repo (using a public_repo block) or a private GitHub repo (using a connected_repo block). Read more about VCS configuration here.

Nuon Managed Sandboxes

We maintain managed sandboxes for each platform that we support. Each platform has both a turnkey (where all resources are provisioned) and a bring-your-own-vpc sandbox. These sandboxes are designed to be a stable, configurable starting point and most relevant options around the network, cluster and compute are configurable.

We publish each sandbox as a Terraform module. They can all be found in the Terraform Registry, and you can find detailed documentation for each sandbox there.

Since you cannot use a Terraform module with Nuon directly, we also provide pre-configured Terraform projects that wrap them for convenient use. You can find these in our sandboxes repo on Github. These projects are what you will reference in your sandbox config.

AWS EKS

AWS EKS is a sandbox for provisioning an EKS app. This sandbox creates a new VPC, EKS cluster, IAM and installs a set of Helm resources.


There is also a Bring Your Own Network version of this sandbox.

AWS ECS

AWS ECS is a sandbox for provisioning an ECS app. This sandbox creates a new VPC, ECS cluster and IAM resources.


There is also a Bring Your Own Network of this sandbox.

Azure AKS

The Azure AKS sandbox creates a VPN and an AKS cluster.


There is also a Bring Your Own Network of this sandbox.

Sandbox Updates

Nuon managed sandboxes are open source and tagged using standard semver.

To pin any sandbox, you can set a tag such as v0.0.1 as the branch field. Use the value main to use the latest version at all times.

Sandbox Outputs

Sandbox outputs are used by the Nuon platform to install the runner, and made accessible to all components using variables.

You can use any output from your selected sandbox by setting a config value on your component:

Configure Sandboxes

Each managed sandbox has a set of variable inputs. Most variables are either supplied by the Nuon platform during install, via inputs, or by setting default values.

Use Default Values

To configure a sandbox parameter with a default value for your app:

Use App Inputs

App inputs allow you to collect customer input values such as resource IDs, tokens and more. These inputs are accesible to all components and your sandbox, using variables.

To configure a sandbox parameter using an app input:

Create a Custom Sandbox

While our open source sandboxes are a great starting point, you can always fork them, or create your own sandbox to support customizing.

To use a custom sandbox, simply update your config to point to your new sandbox code. Custom sandboxes can also use private GitHub repos, that are connected to Nuon.


If one of our managed sandboxes does not work for you, and you are considering creating a custom sandbox, we would love to hear about your use case!

Please get in touch.