DocsSetup and installationInstall Lifecycle

Install Lifecycle

Select the OpenTofu-managed or standalone Helm installation path. Make sure that the API, UI, identity, and cluster are healthy.

Select one installation owner for the Lifecycle Helm release. Do not let OpenTofu and a manual Helm command manage the same release.

🚫

The starter OpenTofu module and stock installation are evaluation paths, not a production-hardening profile. The stock installation is not a complete authentication-on profile for shared-network exposure. Before exposure, use a complete authentication-on procedure for the installed release. If the release does not supply this procedure, keep the deployment isolated. Also examine the security boundaries.

Path A: OpenTofu-managed installation

The starter infrastructure flow enables app_lifecycle_enabled by default. In that mode, tofu apply installs a Helm release named lifecycle. Do not install the chart a second time.

Set the namespace that you selected in secrets.auto.tfvars. Examine the managed release:

OpenTofu pins its own chart and application versions. Before a module upgrade, examine the plan and pinned versions. Test a standalone chart version before you replace a module pin.

Path B: operator-managed Helm installation

If you operate a compatible Kubernetes cluster, use this path. You can also use it after you set app_lifecycle_enabled = false in the starter module.

Use chart 0.9.10 with this procedure. Pin the version. Do not install an untested latest release.

Examine the generated file. Replace all example.com values. The core API, UI, identity provider, registry, and BuildKit registry must use one domain:

lifecycle.example.org is a documentation-only domain. Use a domain that you control. Configure its DNS, ingress class, certificate issuer, storage classes, resource limits, secrets, backup policy, and identity integration. Do not put credentials in a committed values file or command line.

Before installation, render the Kubernetes objects. Examine the output:

After you examine the output, install the same pinned version:

Test the installation

An installed Helm release is not, by itself, proof that Lifecycle is ready. Make sure that each boundary is correct:

  1. helm status reports the expected release and chart version.
  2. All necessary pods are ready, and no workload is in a restart loop.
  3. The core API hostname answers its health endpoint with trusted TLS.
  4. The UI hostname loads with trusted TLS.
  5. After sign-in, make sure that the identity provider returns the user to Lifecycle.
  6. Lifecycle rejects an unauthenticated v2 API request. The request does not receive an administrator identity.

See Authentication for the full sign-in and security checks. If a workload is unhealthy, start with platform monitoring rather than continuing setup.

Continue setup

When the API, UI, and sign-in flow are healthy:

  1. Create the GitHub App.
  2. Onboard a repository.
  3. Create the first Environment.

The repository-installation step grants GitHub App access. Onboarding is a different Lifecycle step. Lifecycle cannot use the repository before onboarding.

Set up an evaluation clusterCreate the GitHub App