No jam. Ever.

Nojam runs Terraform and OpenTofu for HashiCorp Vault. Every change is planned on the pull request, approved by a second person on the exact plan, and applied with a Vault credential that lives for minutes.

In our first large test Nojam ran 37,707 Vault resources in 121 stacks without a single failure. Read the test report

One shared state puts every team in one queue

Many Vault estates run from a single Terraform state. Every change, in any namespace, takes the same lock and refreshes every resource, so teams wait for each other's work before their own can start.

Plan time grows faster than the state does. In our load tests a state of 12,000 resources took about 5 minutes to plan, and one of 24,000 took about 21.

The pipeline doing all that waiting usually holds a long-lived admin token for the whole cluster.

One state and one lock for each namespace

Nojam plans and applies each stack on its own. Different stacks run side by side; one stack's state is changed by one job at a time, so running in parallel never corrupts a state.

Getting there is part of the product. nojam state split cuts one shared state into one per namespace, and every new state has to plan to zero changes against Vault before anything is applied. Nothing in Vault moves, only the bookkeeping.

See how the split works

From pull request to every region

  1. Plans on the pull request

    Every affected stack and target is planned. Each target gets its own commit status, and one summary comment says what will change.

  2. Approval of the exact plan

    A signed-in reviewer who is not an author approves the plan's hash. Production also needs MFA and a recent step-up.

  3. Promotion after the merge

    Nojam plans the merge commit again, then applies dev, uat and each production region in turn, with a canary region first if you want one.

  4. A credential per job

    Each job logs in to Vault with its own credential, scoped to its target and revoked as soon as Terraform finishes.

Nothing in the pipeline worth stealing

Plans log in with a read-only Vault role. The apply role only works for the main branch. The token reaches the runner sealed, and it is revoked when Terraform finishes and again when its lease runs out.

Repository code can't set the Vault address, the token or the login. A plan that would change the auth mounts or policies Nojam itself depends on is denied.

Read how Nojam is secured

Your Vault configuration can't delete itself

Nojam knows which Vault objects can't be rebuilt from code, and treats them that way. Routine work goes through normal review.

  • Removing an audit device is refused outright.
  • Deleting KV data, a Transit key, a PKI CA or a namespace needs a stated reason, a break-glass label and an extra approver.
  • On Vault Enterprise, break-glass can run through a Vault control group, so the people Vault names approve it in Vault, and Nojam can't skip them.
  • A policy that newly reaches into another team's namespace is named on the pull request.
  • See every Vault-specific safeguard

Audit evidence your auditor can verify

Every event is chained to the one before it by SHA-256. Every 10 minutes the head of the chain is signed and written to a write-once bucket, and events stream to your own compliance store as they happen.

One job's report ties together the commit, the approved plan hash, the policy bundle that judged it, each approval with how the approver signed in, and the runner that ran it. Every export carries the chain head, so a printed copy points back to the record.

See how it maps to your controls

Runs inside your network

One Go binary and PostgreSQL, on a small VM or several replicas behind a load balancer. Jobs run in Podman containers on your own runner hosts, on a network that can only reach what it must.

Providers come from your own mirror, and a strict site can fill that mirror without touching the internet. Nothing phones home.

282 MB

Peak memory of the server, a runner and OpenTofu together, running plans and applies for 30 minutes on 1 vCPU and 2 GB.

Try Nojam on your own Vault

A pilot runs next to your current pipeline in shadow mode, on one cluster and up to ten repositories, for two weeks. It ends with a written report.