Environment configuration
Configure deployment behavior, Service groups, and automation for ephemeral Environments.
The environment section controls each ephemeral Environment. It selects
default Services, optional Services, and webhook automation.
Field reference
| Field | Type | Required | Description |
|---|---|---|---|
autoDeploy | boolean | No | Automatically deploy on PR updates |
defaultServices | array | No | Services active when an Environment starts |
optionalServices | array | No | Services available on demand |
ignoreFiles | array | No | Shared push-redeploy ignore patterns |
webhooks | array | No | Automation triggers on state changes |
enabledFeatures | array | No | Per-Environment behavior flags |
githubDeployments | boolean | No | Create GitHub deployment records |
Do not use useGithubStatusComment. It has no effect. Use configurable
labels for GitHub comment behavior.
defaultServices
Lifecycle automatically deploys the Services in defaultServices when it
creates an Environment. This field is optional. If defaultServices and
optionalServices are missing, Lifecycle activates all Services in the same
lifecycle.yaml.
Service reference fields
Each entry in defaultServices can include optional fields that override the
Service configuration:
| Field | Type | Description |
|---|---|---|
name | string | Required. Name matching a service in the services array |
repository | string | Override the repository for this service |
branch | string | Override the branch for this service |
Specify Services by name. Do not use serviceId. It causes an unsupported
field error. You can also add repository and branch.
optionalServices
Lifecycle does not deploy optionalServices by default. Add them through the
Lifecycle UI or API when an Environment needs them.
Optional Services are useful for components that are not always necessary. Examples include workers, caches, and more test databases.
autoDeploy
When autoDeploy is enabled, Lifecycle starts a deployment after each new
commit on the pull request.
With autoDeploy: true, Lifecycle automatically creates Environments for each
commit to the pull-request branch. No manual label is necessary.
ignoreFiles
ignoreFiles contains repo-relative glob patterns shared by all Services in
the Environment. An operator must also enable the global feature flag. See
Ignore File Patterns before relying on a
push skip.
enabledFeatures
You can use this feature value:
no-default-env-resolve— do not substitute an unselected service’s static Environment hostname.
webhooks
Webhooks start external actions at specified Environment states. See Webhooks for the configuration.
Examples
To select a subset explicitly, add defaultServices:
Environment and Service statuses
The UI, API, CLI, and webhook configuration have related but different status sets.
Environment statuses
| Status | Meaning |
|---|---|
pending | Waiting for orchestration to begin |
queued | Lifecycle queued the work |
building | Lifecycle builds one or more Service images |
built | Image builds completed |
deploying | Lifecycle deploys Services |
deployed | The Environment deployed without errors |
tearing_down | Teardown is in progress |
torn_down | Teardown completed |
error | Build or deployment failed |
config_error | Lifecycle could not apply configuration |
Service Deploy statuses
A Service can also report cloning, ready, waiting, build_failed, and
deploy_failed. Examine the affected Service when one of these appears.
Only lowercase deployed, error, and torn_down start lifecycle.yaml
webhooks. See Webhook configuration.