Environments

An environment is a deployment target within a project — typically production, staging, or development. Each environment has its own infrastructure, secrets, domain, and deployment history.

Creating an environment

Environments are created in the dashboard: open the project, select Add environment, enter a name, pick the cloud provider and region, choose whether it is protected, and select Create environment. Right after creating a project, the setup page’s Create this environment opens the same form with the name from its Environment field filled in.

Each environment is tied to a specific cloud provider and region. You can have environments on different providers — for example, staging on GCP and production on AWS.

Environment settings

Setting	Description
name / slug	Identifier for the environment
cloud_provider_id	Which connected provider to use
region	Cloud region for deployment
network_id	Optional VPC/network for private resources
database_id	Optional database instance
cache_id	Optional cache instance
vanity_url	The environment’s URL at its cloud provider (API Gateway on AWS, CloudFront for a static site, Cloud Run on GCP), set by its first deploy
maintenance_mode	Whether the environment is in maintenance mode
protected	Whether the environment requires elevated permissions to deploy

Protected environments

Mark an environment as protected to require additional permissions for deployment. This prevents accidental deploys to production by team members who only have staging access. Turn it on or off with the Protected switch under the environment’s Settings, Protection; it is saved straight away.

A protected environment can’t be deleted, and the cloud provider it runs on can’t be removed, until its protection is off.

Environment isolation

Each environment is fully isolated:

• Separate container image version
• Separate secrets and environment variables
• Separate cloud resources (database, cache connections)
• Separate deployment history
• Separate custom domains

A deployment to staging never affects production. Rolling back one environment has no effect on others.

Environment configuration

An environment’s configuration (runtime and build, compute, queues and scheduler, deploy hooks, domains, linked resources) is kept in SKE. Change it under the environment’s Settings in the dashboard.

The VPC setting (the subnets and security groups the functions run in, under Advanced) can change after a deploy too. The next deploy moves the functions to the new subnets; an env sync keeps them in the subnets they run in now.

Targeting an environment

ske link saves a default environment for the directory. The --env flag targets another one on any environment-scoped command:

ske secret list --env production
ske deploy --env staging
ske status --env production

You can also set --project to target a different project entirely:

ske deploy --project api --env production

In CI, SKE_PROJECT and SKE_ENV do the same as the flags.