What is Firstlume

Firstlume is an Infrastructure as Code automation platform for OpenTofu, Terraform and Terragrunt. You install it with Helm in any Kubernetes cluster. It runs your code in short-lived Jobs, shows what a plan will change resource by resource, waits for approval, applies exactly what was planned, and keeps your state.

What happens in a run

1. Plan. An agent picks up the run and starts a Job. The Job checks out your commit, writes the files and variables the run needs, and runs plan.
2. Review. Firstlume lists what will be deleted, replaced, updated and created, resource by resource, with the attributes that change.
3. Approval. The run waits for someone to approve it. Approval is on by default, and you can turn it off per organization, folder or stack.
4. Apply. A new Job checks out the same commit and applies the saved plan file. Each resource on the list shows its progress and, if it fails, its error.
5. State. Each unit's state is saved as a new encrypted version in Firstlume, with a lock per unit.

Read more in Runs and approval.

Main capabilities

• Organizations, folders and stacks. Variables, secrets and rules are set once at a high level and inherited below, with overrides where needed. See Organizations, folders, stacks.
• Review by resource. Replacements are counted apart from creations and deletions. You can require someone to confirm each deletion or replacement.
• Confirmation per resource. With an optional setting, every delete or replace must be confirmed one by one before approval. See Runs and approval.
• Scheduled drift detection. A drift check is a plan that only reports. See Drift detection.
• Built-in state backend. It uses the http backend of Terraform and OpenTofu, with no plugin. State is kept per unit, with locks and versions. See State backend.
• State for pipelines that don't run here yet. Your CI can use Firstlume's state with a token before its runs move over. See State-only tokens.
• Files, variables and registry logins declared in the repository. See .firstlume/config.yaml and Registry credentials.
• Vault secrets without a second vault. The run's own pod reads Vault with an identity tied to the stack and the phase. See Vault secrets.
• Agents anywhere. The agent only makes outbound requests, so it can run in another cluster or on a client's network. See Architecture.
• Sign-in with Gitea (OIDC), group-based access and invitations to organizations.

What is planned

These are not built yet:

• GitHub and GitLab integration, and plan on pull request, commit status and apply on merge for any Git host
• Native Terragrunt units: discovery, dependency graph, one run per unit, and agents with labels by network or zone
• Finer roles, approvers by person or group, and an audit trail
• A State tab in the UI: versions, diff, rollback and forced unlock
• OpenTelemetry export and notifications
• Phase hooks, scheduled tasks, OPA policies, backup and restore

See also Known limitations.

Two ways to run it

• Self-hosted. Install it with Helm in your own cluster. See Install with Helm.
• Hired from us. We set it up and keep it running. Runners on our infrastructure are planned, for customers who choose them; otherwise runs stay in your cluster. Write to [email protected].

Where to go next

• Install with Helm
• Your first run