Skip to content

Services and environments

A service is a deployable unit inside a project. Its kind is one of container, helm, kustomize, serverless, vm, terraform or custom. Its artifact spec says how versions are found (registry and repository, bucket prefix, and so on) and it can carry a health check.

Services are not pipelines. One pipeline can build several services; one service can be fed by several pipelines.

An environment is a place a service runs. It has a name, an order (its position in the lifecycle), a kind (dev, test, staging, prod or custom) and an optional url.

Every environment carries protection rules:

Rule Effect
required_approvals and approvers How many approvals, from which users, teams or roles
allowed_branches Only releases built from these branches may be deployed
deployment_windows Deploys only inside these time windows
freeze_periods No deploys during these periods
policies CEL expressions that must evaluate to true
change_ticket_required A linked, approved change request (Business and above)

Infrastructure is a target attached to an environment: where and how the deployment is applied. Kinds: kubernetes, helm, kustomize, ecs, lambda, cloudrun, azure_app_service, azure_container_apps, vm_pool, terraform and script. It holds config (cluster reference, namespace, and so on), a connection_id for the cloud or Kubernetes integration, and a runner_pool_id saying which runners can reach it.

Because infrastructure names a runner pool, deployments run inside the network that owns the target. Credentials never need to leave it.

Variables are scoped key/values (project, environment, target, tenant), templated and secret-aware. A deployment resolves them into a snapshot you can preview before you run it. See Variables.

The board shows what is deployed where, with drift between desired and live state (for Kubernetes) and health signals from metric providers. Free allows 5 environments per project; paid tiers are unlimited.