Environments

Environments are isolated deployment targets within a project. Run multiple versions of your application simultaneously—production, staging, development—without them interfering with each other. Each environment maintains its own deployment history with full audit trails and rollback capability.

​

What is an Environment?

An environment is an isolated namespace where you deploy your application:

• Isolated Infrastructure - Each environment has its own services, volumes, and configuration
• Separate Secrets - Environment variables don’t leak between environments
• Independent Scaling - Production can have 5 replicas while dev has 1
• Version Control - Full deployment history with rollback to any previous state

Every project starts with a default production environment. Create additional environments as needed.

​

Common Environment Types

​

Creating an Environment

From the environment dropdown in the top bar:

1. Click New Environment
2. Enter an environment name
3. Under Starting point, choose Clone from existing (and pick the source environment) or Empty environment
4. Click Create, then apply when you’re ready to deploy

​

Environment Isolation

Each environment is completely isolated: Separate Namespaces:

• Services in “production” cannot communicate with services in “staging”
• Private networking only works within the same environment

Independent Configuration:

• Different environment variables per environment
• Different secrets (database passwords, API keys)
• Different resource allocations (CPU, memory, replicas)

Separate Deployments:

• Deploy to production without affecting staging
• Each environment has its own deployment history
• Rollback independently per environment

​

Cloning an Environment

Clone from existing creates a complete, isolated copy of your infrastructure. All services, configuration, and volume definitions are duplicated to a new environment where you can experiment safely.

​

What Gets Copied

Copied:

• All services (containers and functions) with their images
• Resource allocations (CPU, memory, replicas)
• Networking configuration (HTTPS endpoints, TCP proxies)
• Volume definitions and mount paths
• Service connections and dependencies
• Environment variables, including their values

Not copied:

• Volume data (volumes are created empty)
• Deployment history (starts fresh)
• Logs and metrics

​

The Variable Review Step

After you name the environment and pick a source, Suga shows every variable it found, grouped by service. Each one has a checkbox and an editable value, so you can drop or change anything before the environment is created. Variables marked sensitive, and values Suga detects as secrets, start unchecked. Everything else starts checked. Tick a sensitive variable to carry its value over, or leave it off and set a fresh value later.

​

After Cloning

1. Fill in any variables you skipped - Set passwords, API keys, and other secrets you chose not to copy.
2. Apply - The new environment starts undeployed. Click Apply to provision infrastructure.
3. Populate Data - Volumes are empty. Load data from backups or seed manually if needed.

​

Clone vs. Empty

Clone when:

• Testing changes to existing infrastructure
• You need environment parity, such as staging matching production
• Debugging issues that require exact replication

Start empty when:

• Starting a new architecture from scratch
• Existing environments don’t match what you need
• Experimenting with a completely different setup

​

Switching Environments

1. Click the environment dropdown in the top-right
2. Select the environment
3. The canvas updates to show that environment’s infrastructure

​

Deleting Environments

​

Common Questions