DocsLifecycle schemaSchema overview

Schema overview

Understand the lifecycle.yaml configuration file and its structure.

Lifecycle reads its configuration from the repository root. The supported filenames are:

  • lifecycle.yaml (recommended)
  • lifecycle.yml
  • .lifecycle.yaml
  • .lifecycle.yml

Keep only one supported file in each repository. If the repository has multiple files, Lifecycle does not guarantee which file it selects.

File structure

A lifecycle.yaml file has three primary sections:

SectionDescription
versionSchema version. Use "1.0.0"
environmentControls deployment behavior, service grouping, and webhooks
servicesArray of service definitions with their configurations

Service types

Each entry in services must have one Service type only. Select the type for your deployment.

Service typePurpose
githubSource build and deployment from a GitHub repository
dockerDeploy pre-built Docker images, such as databases and caches
helmDeploy using Helm charts (local or remote)
codefreshTrigger external Codefresh pipelines for deployment
externalHttpUse an existing internal and public HTTP endpoint
auroraRestoreRestore AWS Aurora database snapshots
configurationProvide shared values without a workload

Select a Service type

Shared Service fields

These fields sit directly on each services[] entry with its Service type:

FieldTypeRequiredDescription
namestringYesService name used by references and template keys
appShortstringNoShort application identifier
defaultUUIDstringNoStatic Environment fallback for an unselected service
ignoreFilesstring[]NoService-specific push-redeploy ignore patterns
requiresobject[]NoServices to include with this service
deploymentDependsOnstring[]NoSelected services that must deploy first

requires controls inclusion. deploymentDependsOn controls order. See Service Dependencies.

External HTTP Service

Use externalHttp for an endpoint that Lifecycle does not build or deploy:

The two endpoint fields are necessary. Lifecycle marks this Service ready without a source build. It makes the resolved URLs available to template variables.

Minimal example

Use this minimal lifecycle.yaml for one Service:

Expanded example

An expanded example with multiple Service types:

Template variables

Use template variables in your configuration. For example, {{api_publicUrl}} and {{database_internalHostname}} supply dynamic values from other Services.

See Template variables for the full list and examples.