# Nojam: full site > 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, applied with a short-lived Vault credential, and kept on a tamper-evident audit record. # 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. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) In our first large test Nojam ran 37,707 Vault resources in 121 stacks without a single failure. [Read the test report](https://nojam.io/blog/on-our-first-tests.md) ## 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](https://nojam.io/vault-native.md#state-split) ## 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](https://nojam.io/security.md) Example job log: a plan logs in with a read-only role, receives a sealed token, plans five additions and one change, and the token is revoked. ## 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](https://nojam.io/vault-native.md) ## 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](https://nojam.io/compliance.md) ## 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. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/ Site map for AI agents: https://nojam.io/llms.txt # Vault-native safety for Terraform and OpenTofu General-purpose runners treat Vault as one more provider. Nojam knows what a Vault change means: which credential a job should get, which objects can never be rebuilt, and which policy quietly reaches every team. ## A credential for each job and each phase Each job logs in to Vault with its own short-lived credential: a JWT signed by Nojam's built-in OIDC issuer, or a hardened AppRole while you move off today's setup. Plans get a read-only role. The apply role is bound to `main`. The token is revoked when Terraform finishes. The issuer's public keys can be limited to your Vault servers, or handed to Vault directly so the endpoints are closed to everyone else. Nojam guards its own access too. Plans that would change the auth mounts or policies Nojam uses are denied. ## Protection for what can't be rebuilt Some deletes are routine and some are permanent. Nojam tells them apart. - Removing an audit device is refused. - Deleting KV data or a KV store, a Transit key, a PKI CA or a namespace, or touching the `admin` policies, needs a break-glass label and an extra approver, in every namespace. - Other mounts and auth methods are held only if you name them, for example `auth/oidc` or `database-prod*`. - You add your own rules by Vault path, such as `**/kv-prod/**`, and a pull request can't weaken them. Routine work isn't slowed down. In our tests, 50 policies that grant KV access were removed and recreated through normal review without a single hold. ## Break-glass that approvers can judge A risky change needs a stated reason before anyone may approve it, as many extra approvers as the target asks for, and optionally a ServiceNow incident or change that ServiceNow confirms at every approval. Approvers see one page: why the change is held, what it destroys, with KV data marked as not rebuildable, the reason, the pull request, the plan, the record and the approvals so far. It exports as PDF or PNG for a change board. On Vault Enterprise a target can send break-glass applies through a Vault control group. After Nojam's approvals, Vault holds the apply's token until the people it names, for example two members of `security-team`, authorise it in Vault itself. A compromised Nojam can't skip them. ## Policies that reach further than they look On Vault Enterprise, a policy in a parent namespace whose path starts with a wildcard, such as `"*"` or `"+/kv/*"`, also grants in every child namespace. Nojam holds that change for break-glass and names the path. Any change that lets a policy in one namespace reach into a child namespace says so on the pull request, and can be set to need an extra approver: ``` vault_policy.shared_read (in admin) newly reaches admin/team-a, admin/team-b ``` ## One namespace per team, at any number of teams Tested on real Vault Enterprise 2.2.1, not only the community edition. A team's jobs log in at the parent namespace, out of the team's reach, and work only in their own. In another team's namespace, or the parent, they get "forbidden". A new team is one line in `teams.yaml`. Nojam creates its namespace, its policies and its plan and apply roles on every cluster, through the same reviewed pull request. Removing a team is held for break-glass. Install the GitHub App on the whole organisation with a name mask such as `vault-ns-*`, and new team repositories are picked up as they appear. ## Providers a pull request can't change Providers come only from your mirror and an allow-list, and must match the lock file committed with each stack. A new provider or version shows up in the pull request summary and is passed to policy. Modules that follow a branch or a version range are flagged or refused. Nojam serves the verified mirror itself, so runners never reach a public registry. A strict site can fill the mirror from its own folder or artifact store with no download at all, and the same signature and checksum checks still apply. ## Clusters that change under you Behind a load balancer, the server and the runners may reach different Vault nodes. Nojam's sealed token hand-over works across performance standbys, and a revoked token is refused by every node within moments. During a leader election, a restart or a load balancer failover, a job waiting for credentials is held and tried again. In our tests on a three-node cluster with a leader change every 3 seconds, every plan went through. An outage longer than 15 minutes still fails the job, and the job says why. ## From one shared state to one per namespace `nojam state split` groups the resources of a shared state by namespace and rewrites their addresses to match each team's code. Where it can't tell where a resource belongs, it refuses to guess. Nothing in Vault changes, so there is no outage and nothing is recreated. Every new state must plan to `+0 ~0 −0` against Vault, checked by Nojam in shadow mode, before anything is applied. The original state file is your way back. Until you split, Nojam runs the shared state as it is, with size guardrails that warn before it grows too big. ## See it on your own Vault Bring one cluster and a few repositories. The pilot starts in shadow mode, so nothing in your current pipeline changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/vault-native/ Site map for AI agents: https://nojam.io/llms.txt # How Nojam is secured Nojam sits on the path to your Vault, so it assumes that a pull request, a runner or the network may be hostile. This page covers what Nojam does about each, and how to report a problem. ## Where the trust boundaries are Repository code runs on a runner host, in a Podman container, and reaches Vault only with a short-lived credential. The Nojam server talks to GitHub, keeps its own records and the audit log in PostgreSQL, and keeps plans and logs in a blob store. Nojam holds no Terraform state; that stays in your PostgreSQL or S3 backend. The threat model works through each boundary: what an attacker on that side could try, the control that stops it, and the items still open. ## Credentials that end with the job Every job gets its own Vault credential for its own phase: read-only for plans, and an apply role bound to `main`. It is revoked when Terraform finishes, and again when its lease expires. The token never crosses the wire in the clear. Each runner sends a fresh key, and Vault's answer is sealed to it with HPKE, using X25519 together with ML-KEM-768 so that recorded traffic stays safe from a future quantum computer. Nojam's own JWT signing key is sealed at rest. Where Vault Transit is approved, the key can live in Vault instead, and every signature then shows in Vault's audit log. ## Approval that proves a person A production approval needs a signed-in session, MFA and a recent step-up. API tokens and GitHub comments can't approve production, and the author of a change can't approve it. At the moment of apply, Nojam checks again that the approver still exists, still has access to the repository and is still in the approver group. The approval is bound to a keyed digest of the values in the plan, so a merge only inherits it if it makes exactly the same changes. ## A pull request can't bring its own provider Providers and modules run with the job's credentials, which makes them the easiest way to steal them. Nojam installs providers only from a mirror you control and an allow-list on the server, requires each stack's committed lock file, and shows any new provider or version on the pull request and to your policy. The Vault provider's address, namespace and login come from the target, never from the repository. A pull request can't define a production target. ## Secrets in plans and logs Sensitive values are masked in stored plans and in logs, on the runner and again on the server. Plan files and logs are encrypted at rest, and live logs are encrypted in the database. The support bundle you send when something is stuck holds the version, the settings and the request IDs. Secrets, plans and logs are never in it. ## A production profile that won't start insecurely With `NOJAM_PROFILE=production`, the server and every runner refuse to start until the protections are on, naming each one that is missing and how to fix it. - Runners use mTLS and the sealed hand-over. - The Vault and provider allow-lists are set. - Approval requires MFA, and Nojam is served over HTTPS. - The protection baseline is on, and no development token is set. - Runners use Podman with the provider mirror, verified images and a restricted network. ## Testing on every change Every pull request to Nojam runs these checks, and a gate fails the build if any test is skipped without a reason on file. | Tool | Looks for | | --- | --- | | govulncheck | Known vulnerabilities the code can actually reach | | staticcheck, gosec | Bugs and insecure Go patterns, including path, redirect and SSRF taint | | Semgrep | Insecure patterns and hard-coded secrets | | gitleaks | Secrets anywhere in the commit history | | Trivy | Vulnerable dependencies, and the runner image's packages | | Go fuzzing | Crashes in every parser of outside input | | OWASP ZAP, testssl.sh | A running server, scanned from outside | On top of that, manual testing with Burp Suite Professional runs in-house against a dedicated target. Every finding is recorded with its verdict, and a test is added so it can't come back. ## Fixing vulnerable dependencies When a vulnerability is found in released code, these are the time frames to ship a fixed release, counted from the day it is known. | Severity (CVSS) | Fixed within | | --- | --- | | Critical, 9.0 and above, or known to be exploited | 3 days | | High, 7.0 to 8.9 | 14 days | | Medium, 4.0 to 6.9 | 45 days | | Low | The next planned release | ## Releases you can verify Every release binary carries a cosign keyless signature, an SBOM and SLSA level 3 provenance. The runner image is signed too. The release guide shows how to check all three before you install. The threat model, the cryptographic inventory and our OWASP ASVS 5.0 level 2 self-assessment go to every pilot customer, and are published with the first public release. ## Reporting a vulnerability Email [hello@nojam.io](mailto:hello@nojam.io) with what you found and how to reproduce it. Please give us time to ship a fix before you publish. The same contact is in our [security.txt](https://nojam.io/.well-known/security.txt). ## Put it in front of your security team A pilot comes with the threat model and the self-assessment, so your reviewers can check our claims before anything runs. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/security/ Site map for AI agents: https://nojam.io/llms.txt # Change evidence for regulated Vault estates Nojam helps you evidence change management for Vault: who changed what, who approved it, on which plan, and that the record wasn't edited afterwards. It doesn't make you compliant on its own, and this page says where it stops. ## What Nojam records for every change - The commit, the pull request and the plan, with its SHA-256. - The policy bundle that judged the plan, and its result. - Each approval: who, when, and how they signed in, including the channel and the second factor. - The ServiceNow change or incident, where a target requires one, as ServiceNow confirmed it at each approval. - The runner that ran the job, and the signed audit anchor that covers it. - Every break-glass hold, with its stated reason and its extra approvers. ## A log you can prove wasn't changed Every audit event is chained to the one before it by SHA-256, so editing, deleting or reordering one breaks the chain at that point. Someone with database access could rebuild the chain, so Nojam signs its head every 10 minutes and writes it to a write-once bucket with S3 object lock. Events also stream as they happen to your own store: Splunk, syslog over TLS, S3 with object lock, PostgreSQL, a file or a webhook. A rewritten history no longer matches the signed anchors or your copy. The audit page shows both checks, and `nojam audit verify` checks an exported copy offline, without trusting Nojam. ## How it lines up with common change controls Your auditor decides what counts as evidence. This is what Nojam gives them to test against. | Control | What Nojam provides | | --- | --- | | SOC 2, CC8.1: changes are authorised, tested and approved | A plan on every pull request, policy checks on every plan, approval by someone who is not the author, and an apply of exactly the approved plan | | ISO/IEC 27001:2022, Annex A 8.32: change management | The same chain from commit to apply, plus change records from ServiceNow and promotion in a fixed order from dev to production | | PCI DSS 4.0, requirement 6.5: changes to system components are managed | The approved plan hash, the approver and the result of each change, in one export per job | | DORA: ICT change management | Recorded approvals, break-glass with a reason, and a tamper-evident log streamed to your own store | ## Exports that point back to the record Every job, the overview and the activity feed export as JSON, NDJSON, PDF or PNG. Each export names who made it, when, and the audit chain head at that moment, so a printed copy can be tied back to the record. The break-glass page exports on its own for a change board: why it was held, what it destroys, the reason, the record and the approvals. ## What Nojam doesn't cover - The log is tamper-evident, not tamper-proof. Someone with database access can still change rows; what Nojam guarantees is that the change shows. - It records changes made through Nojam. A change made by hand in the Vault UI or CLI doesn't pass through it, so keep Vault's own audit device on. - It doesn't review who has access to Vault or read secrets. Those controls stay with Vault and your identity provider. - Rollback re-applies the last known-good configuration. It is compensation, not a database transaction, and it can't bring back deleted KV data. ## Show your auditor a real change In a pilot, one job export covers a full change from commit to apply. Bring it to your next audit conversation. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compliance/ Site map for AI agents: https://nojam.io/llms.txt # Claims and the tests behind them Every claim on this site is backed by a test in the Nojam repository. A claim with no test doesn’t go on the site. Pilot customers get the repository and can run any of them. ## Claims and their tests | Claim | Test | | --- | --- | | A merge applies without a second approval only if its plan makes exactly the same changes as the reviewed one | `carryover_test.go` | | Production approval needs a session, MFA and a recent step-up; the author cannot approve | `approval_assurance_test.go, approvers_test.go` | | Each job gets its own Vault credential, sealed in transit and revoked when Terraform finishes | `vault_test.go, vaultsealed_test.go` | | The issuer can be closed to everyone except Vault | `TestIssuerAllowedCIDRs, TestIssuerKeyGivenToVault` | | Deleting what cannot be rebuilt needs break-glass; 50 KV-granting policies recreated without a hold | `TestCriticalMounts` | | A parent-namespace wildcard policy is held and named | `TestRecommendedBaseline, TestVaultEnterpriseParentPolicyReachesChild` | | Break-glass needs a reason, extra approvers and an optional ServiceNow record | `TestBreakGlassReason, TestBreakGlassApprovers, TestBreakGlassRecord` | | Break-glass through a Vault control group that Nojam cannot skip | `TestVaultEnterpriseControlGroupBreakGlass` | | Cross-namespace grants are named on the pull request | `TestCrossNamespaceGrants` | | One isolated namespace per team on Vault Enterprise | `TestVaultEnterpriseJobNamespace, TestVaultEnterpriseNamespaces` | | Namespace vending through a pull request | `TestVaultEnterpriseNamespaceVending` | | Jobs ride through Vault leader changes and performance standbys | `TestVaultEnterpriseLeaderChange, TestVaultEnterprisePerformanceStandby, TestStandbyRetries412` | | Providers only from your mirror, matching the committed lock file; changes shown | `TestProviderPinning, TestProviderLockfile, TestProviderChanges, TestModulePinning` | | A mirror filled with no network access at all | `TestDirectorySourceMirrorsWithoutTheNetwork, TestDirectorySourceRefuses` | | Your own pipeline steps run after every plan and cannot be dropped by a pull request | `TestPipelineSteps` | | The audit log is hash-chained and anchored, signed and write-once | `TestAuditAnchors, TestAuditAnchoringLine` | | One export ties a change together from commit to apply | `TestJobEvidence` | | The support bundle never contains secrets, plans or logs | `TestSupportBundle` | | Old plan files and webhook payloads are pruned; the change record stays complete | `TestRetentionJobs, TestPruneWebhooks` | ## Measured numbers and their conditions These ran on deliberately small machines with a local or in-memory Vault. A production Vault with persistent storage and audit devices answers more slowly, so expect longer plans. | What | Result | Conditions | | --- | --- | --- | | Resources in one state | 52,875 | 4 vCPU shared server, local Vault | | 30 days of daily changes on one shared state | 24,402 resources, 21.8 MB state, all passed | as above | | Plan time as one state grows | about 5 min at 12,000 resources, about 21 min at 24,000 | as above | | Applying an approved plan | about 800 resources in 20 to 40 s | as above; the saved plan is applied without a second refresh | | Created in one apply | 31,725 resources in 9 min 41 s | as above | | An estate of 121 stacks | 37,707 resources; bootstrap 1 h 6 min; one team’s change 24 s; no failures | 1 CPU, one runner with one slot, Vault in development mode | | Throughput, 100 stacks of 20 resources | opened to applied in 7 min 38 s with one runner slot, 5 min 4 s with four | server and runner on 1 vCPU, no provider downloads | | Footprint | peak memory 282 MB for server, runner and OpenTofu | 1 vCPU and 2 GB, 30 minutes of continuous plans and applies | | Failover | leader killed or database restarted mid-apply: applied exactly once | real processes, SIGKILL | ## What Nojam does for speed, and what it can't Nojam doesn't make a single large plan faster. That time is OpenTofu and Vault's API, the same under any orchestrator. It saves time around the plan: it plans only the stacks a change affects, applies the approved plan without refreshing again, carries the approval from pull request to merge when nothing changed, and makes it safe to split one large state so plans stay small and run side by side. Capacity follows CPUs. Give each runner host as many slots as it has CPUs, and add hosts as you need them. ## Run the tests on your own estate A pilot gives you the repository and the test farm setup, so your team can check any claim on this page. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/proof/ Site map for AI agents: https://nojam.io/llms.txt # Nojam compared with other Terraform runners Each page says what the other tool does better, where Nojam differs for a Vault estate, and when to choose which. Facts about other tools come from their own pages, read on 7 November 2026. ## Compare Nojam with - [AtlantisSelf-hosted, open-source pull request bot for Terraform.](https://nojam.io/compare/atlantis.md) - [HCP TerraformHashiCorp’s hosted Terraform platform, now part of IBM; Terraform Enterprise is the self-hosted edition.](https://nojam.io/compare/hcp-terraform.md) - [SpaceliftHosted infrastructure-as-code platform with private worker pools.](https://nojam.io/compare/spacelift.md) - [env0Hosted platform for Terraform and other infrastructure tools, priced by run.](https://nojam.io/compare/env0.md) - [StateGraphTerraform state kept as a graph in PostgreSQL, with plans run in your own CI.](https://nojam.io/compare/stategraph.md) ## Who holds the apply credential For a Vault estate, the most useful question to ask of any runner is where Terraform runs and which credential it runs with. | Tool | Model | Where Terraform runs | Apply credential | Audit | | --- | --- | --- | --- | --- | | Nojam | Self-hosted binary on PostgreSQL | Podman containers on your runner hosts | A per-job, per-phase Vault credential, revoked at the end | Hash-chained, signed, streamed to your store | | Atlantis | Self-hosted bot | On the Atlantis server | The server’s standing credentials | None; plans on disk | | HCP Terraform | Hosted; Terraform Enterprise self-hosted | HashiCorp’s VMs, or agents you run | Workload identity, or static variables | Premium tier | | Spacelift | Hosted; private workers | Spacelift’s containers or your worker pools | Short-lived cloud tokens by OIDC | Enterprise tier | | env0 | Hosted | Runners | The credentials you supply | Listed as a feature; details not stated | | StateGraph | Hosted, single-tenant or self-hosted | Your CI or a laptop | Your CI’s secret store | Attributed history, 30 or 365 days | ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/ Site map for AI agents: https://nojam.io/llms.txt # Nojam and Atlantis Atlantis is the open-source pull request bot many teams start with. It runs Terraform on its own server and comments the result on the pull request. Nojam is built for teams whose Terraform changes HashiCorp Vault and who need to prove each change afterwards. ## What Atlantis does better - It is open source under the Apache 2.0 licence, free, and has years of use and a large community behind it. - It is simple to run: one server, configured in a file, with no database. - It works with more Git hosts than GitHub. Nojam supports GitHub.com and GitHub Enterprise Server only. - It treats every provider the same way. Nojam’s safety features are built for Vault. ## Where Nojam differs - Atlantis runs plans and applies on its own server with that server’s standing credentials. Nojam gives each job its own short-lived Vault credential in an isolated Podman container, and revokes it when the job ends. - Atlantis keeps plans on disk and has no audit log. Nojam keeps a hash-chained, signed audit log and one export per change. - In Atlantis, stopping authors from approving their own changes is a Conftest option, off by default. In Nojam the author can never approve, and production approval needs MFA. - Atlantis published twelve security advisories on 25 October 2026, among them a critical fork-protection bypass. Nojam’s threat model goes to every pilot customer. ## Which to choose ### Choose Atlantis if You want a free, open-source bot, your Terraform is mostly not Vault, or your code lives on GitLab or Bitbucket. ### Choose Nojam if Your Terraform manages Vault, and you need per-job credentials, assured approvals and an audit trail an auditor can verify. Facts about Atlantis come from its own pages, read on 7 November 2026: [Atlantis security](https://www.runatlantis.io/docs/security), [Atlantis security advisories](https://github.com/runatlantis/atlantis/security/advisories). If something here is out of date, write to us and we’ll correct it. ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare the two on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/atlantis/ Site map for AI agents: https://nojam.io/llms.txt # Nojam and HCP Terraform HCP Terraform is HashiCorp’s own hosted platform for Terraform, sold by IBM since 2025, with Terraform Enterprise as its self-hosted edition. Nojam is a self-hosted runner for teams whose Terraform changes HashiCorp Vault. ## What HCP Terraform does better - It comes from the makers of Terraform and covers every provider the same way, with a private registry and a large ecosystem around it. - It is hosted: there is nothing to install or patch. - It offers workload identity to AWS, Google Cloud, Azure, Vault and Kubernetes, so jobs can avoid static cloud keys. - It has a free tier of 500 managed resources. ## Where Nojam differs - HCP Terraform is priced per managed resource per hour, from $0.10 to $0.99 per resource a month. Nojam doesn’t charge by resource, so putting more of Vault under management costs nothing extra. - Its audit logging is in the Premium tier. Nojam’s tamper-evident audit log is part of the product. - HashiCorp’s security model states that "the plan permission is equivalent to the write permission". In Nojam a plan gets a read-only Vault role, and production targets can require an approver before pull request code plans at all. - Plans and applies run on HashiCorp’s machines unless you run their agents or Terraform Enterprise. Nojam runs entirely inside your network. ## Which to choose ### Choose HCP Terraform if You want a hosted platform from the makers of Terraform for many providers, and per-resource pricing suits your estate. ### Choose Nojam if Vault is the centre of your Terraform, the code and credentials must stay inside your network, and audit evidence is a requirement. Facts about HCP Terraform come from its own pages, read on 7 November 2026: [HashiCorp pricing](https://www.hashicorp.com/en/pricing), [HCP Terraform security model](https://developer.hashicorp.com/terraform/cloud-docs/architectural-details/security-model). If something here is out of date, write to us and we’ll correct it. ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare the two on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/hcp-terraform/ Site map for AI agents: https://nojam.io/llms.txt # Nojam and Spacelift Spacelift is a hosted platform for infrastructure as code, with workers you can run yourself. Nojam is a self-hosted runner for teams whose Terraform changes HashiCorp Vault. ## What Spacelift does better - It is a mature hosted product with a SOC 2 Type II report. - It covers more than Terraform and OpenTofu, and many providers the same way. - Private worker pools let jobs run in your network while Spacelift runs the control plane. - It issues short-lived cloud tokens to jobs through OIDC. ## Where Nojam differs - Spacelift prices by worker, from $399 a month for its Starter plan, so more parallel jobs cost more. Nojam scales by adding your own runner hosts. - Its audit trail is in the Enterprise tier. Nojam’s audit log is hash-chained, signed and streamed to your own store. - Approvals are Rego policies; whether the author may approve is up to the policy you write. In Nojam the author can never approve, production needs MFA, and the approver is checked again at apply. - The control plane is Spacelift’s. Nojam’s control plane is a binary you run. ## Which to choose ### Choose Spacelift if You want a hosted platform that covers several infrastructure tools, and you are happy for the control plane to sit outside your network. ### Choose Nojam if Vault is what you manage, and the whole path from pull request to Vault must stay in your own network. Facts about Spacelift come from its own pages, read on 7 November 2026: [Spacelift pricing](https://spacelift.io/pricing), [Spacelift documentation](https://docs.spacelift.io/). If something here is out of date, write to us and we’ll correct it. ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare the two on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/spacelift/ Site map for AI agents: https://nojam.io/llms.txt # Nojam and env0 env0 is a hosted platform for running infrastructure as code, with approval policies written in OPA. Nojam is a self-hosted runner for teams whose Terraform changes HashiCorp Vault. ## What env0 does better - It is hosted, so there is nothing to run yourself. - It has a free tier of 250 runs. - It treats every provider the same way, while Nojam’s safety features are built for Vault. ## Where Nojam differs - env0 is priced per successful apply or per environment, which taxes planning and applying often. Nojam doesn’t charge per run. - Jobs use the credentials you supply. Nojam issues each job its own Vault credential for its phase and revokes it when the job ends. - Approval is an OPA policy you write. Nojam’s approval rules are built in: never the author, MFA for production, rechecked at apply. ## Which to choose ### Choose env0 if You want a hosted platform with a per-run price, across several clouds and tools. ### Choose Nojam if Your estate is Vault, you need the credentials and the audit trail to stay inside your network, and you want approval rules you don’t have to write. Facts about env0 come from its own pages, read on 7 November 2026: [env0 pricing](https://www.envzero.com/pricing), [env0 approval policies](https://docs.envzero.com/docs/approval-policies). If something here is out of date, write to us and we’ll correct it. ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare the two on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/env0/ Site map for AI agents: https://nojam.io/llms.txt # Nojam and StateGraph StateGraph keeps Terraform state in PostgreSQL as a graph instead of a file. It solves a different problem from Nojam: StateGraph removes the state-file bottleneck, and Nojam removes the credential, approval and audit bottleneck for a regulated Vault estate. ## What StateGraph does better - Its state model is the better answer to one large state making every plan slow: conflicts are detected per resource, without a global lock, and plans cover only the part of the graph a change touches. - It offers transactions across states. Nojam’s rollback is compensation, not a transaction. - It runs Terragrunt, Pulumi and CDKTF as well. Nojam runs Terraform and OpenTofu. - It is open source under MPL 2.0, publishes its prices, and has customers and a community. ## Where Nojam differs - StateGraph’s server never runs Terraform; plans and applies run in your own CI, so the apply credential lives in your CI’s secret store. Nojam gives each job its own short-lived Vault credential: read-only for plans, bound to main for applies, sealed in transit and revoked at the end. - StateGraph offers approval counts and CODEOWNERS. Nojam requires a signed-in session, MFA and a recent step-up for production, rechecks the approver at apply, and binds the approval to the plan’s values. - StateGraph keeps an attributed history with 30 or 365 days of retention. Nojam’s log is hash-chained, signed, write-once and verifiable offline. - Our answer to the slow state is to split it, one state per namespace, with `nojam state split`. It is plainer to run and keeps standard backends, but it doesn’t keep everything in one place. ## Which to choose ### Choose StateGraph if Your problem is one huge state that makes every plan slow, across several tools. ### Choose Nojam if Your problem is who holds the Vault credential, whether the approval was real, and what you can show an auditor. The two can work together: a platform team could keep its state in StateGraph and run it through Nojam. Facts about StateGraph come from its own pages, read on 7 November 2026: [StateGraph](https://stategraph.com/), [StateGraph on GitHub](https://github.com/stategraph/stategraph). If something here is out of date, write to us and we’ll correct it. ## Compare them on your own Vault A pilot runs next to your current pipeline in shadow mode, so you can compare the two on real changes. [Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md) --- Canonical page: https://nojam.io/compare/stategraph/ Site map for AI agents: https://nojam.io/llms.txt # Nojam licence Nojam is source-available. Personal and non-commercial use is free. Companies need a commercial licence, and a pilot starts with an evaluation licence. ## Free for non-commercial use Run Nojam for personal projects, study and research, or at a non-profit, under the PolyForm Noncommercial License 1.0.0. From the first public release you can read the code, change it and run it for those purposes at no cost. ## A commercial licence for companies A company that runs Nojam, in production or for evaluation, needs a licence from I.M. PR Inc.. We don't publish prices. Tell us about your Vault estate, the number of clusters and namespaces, and how you'd like to run it, and we'll send a quote. A pilot runs under an evaluation licence for its two weeks, so you can try Nojam on your own Vault before you buy. [Request a pilot](https://nojam.io/pilot.md) [Ask for a quote](mailto:hello@nojam.io?subject=Nojam%20licence) ## Questions about the licence **Is Nojam open source?** No. It is source-available: the code can be read, and the licence decides who may use it for free. Open source would let anyone use it commercially at no cost. **Do we need a licence to try it at work?** Yes. Evaluation at a company is commercial use, so a pilot comes with an evaluation licence. **Who owns Nojam?** I.M. PR Inc., Canada. The licence doesn't grant any rights to the name "Nojam" or its logo. **Who do we talk to?** Write to [hello@nojam.io](mailto:hello@nojam.io). --- Canonical page: https://nojam.io/licence/ Site map for AI agents: https://nojam.io/llms.txt # Request a Nojam pilot A pilot runs Nojam next to your current pipeline for two weeks, on one Vault cluster and up to ten repositories. It starts in shadow mode, planning every pull request without applying, so nothing you run today changes. ## What a pilot includes - Nojam on your own hosts, set up with you from the deployment guide. - Plans on every pull request in the pilot repositories, with approvals and the audit log switched on. - The threat model, the cryptographic inventory and our ASVS self-assessment for your security reviewers. - A written report at the end: plan and approval times, what Nojam would have held for break-glass, and the long-lived credentials your current pipeline holds that Nojam would retire. ## What we need from you - A small Linux VM with Podman and PostgreSQL. - A GitHub App installed on the pilot repositories. - A Vault role on one cluster for Nojam's issuer, set up from our Vault guide. - One person on your side who can approve changes. A pilot runs under an evaluation licence, so it is covered from the first day. To request a pilot, fill in the form at https://nojam.io/pilot/ or write to hello@nojam.io. --- Canonical page: https://nojam.io/pilot/ Site map for AI agents: https://nojam.io/llms.txt # Join the Nojam early access list Leave your work email and we’ll write when the first public release of Nojam is out. That is the only email you get from this list. To join the early access list, use the form at https://nojam.io/early-access/ or write to hello@nojam.io. ## Want it sooner? If you run Vault at a company and want Nojam on your own estate now, a pilot gets you there before the public release. [Request a pilot](https://nojam.io/pilot.md) --- Canonical page: https://nojam.io/early-access/ Site map for AI agents: https://nojam.io/llms.txt # Privacy notice This site is run by I.M. PR Inc., Canada. It collects only what you type into its two forms. ## What we collect The pilot form collects your name, work email, organisation, Vault edition, a rough number of namespaces and anything you write about your setup. The early access form collects your work email. ## Why Pilot details are used to reply to you and to arrange a pilot. An early access email is used once, to tell you about the first public release. ## Where it goes The site is hosted on Cloudflare Pages. When you send a form, it is passed to us by email at [hello@nojam.io](mailto:hello@nojam.io). We don't sell or share it. ## What this site doesn't do It sets no cookies, runs no analytics or tracking, and loads no fonts or scripts from other sites. Cloudflare, as the host, keeps standard request logs. ## Removing your details Write to [hello@nojam.io](mailto:hello@nojam.io) and we'll delete what we hold about you. --- Canonical page: https://nojam.io/privacy/ Site map for AI agents: https://nojam.io/llms.txt # Nojam blog Test reports, with their conditions, and notes on running Terraform for Vault safely. - [9 November 2026On our first tests: 37,707 Vault resources, 121 stacks, no failuresWe built a realistic Vault estate of 121 stacks and 37,707 resources and ran Nojam through it, from bootstrap to a shared module change across 36,000 roles.](https://nojam.io/blog/on-our-first-tests.md) --- Canonical page: https://nojam.io/blog/ Site map for AI agents: https://nojam.io/llms.txt # On our first tests: 37,707 Vault resources, 121 stacks, no failures *November 2026* Platform teams ask us one question before any other: will it hold up at our size? A realistic Vault estate in a large organisation is not one Terraform stack. It is a hundred or more Kubernetes clusters, each with its own auth mount and hundreds of roles. Next to them sits a platform layer of KV stores, AppRole, JWT, certificate auth, an SSH CA and a PKI. The KV stores hold thousands of secrets that no one manages with Terraform, and no deployment tool is allowed to touch them. Then one day someone changes the shared module that every cluster uses. So we built that estate and ran Nojam through it. ## What we built - **120 Kubernetes auth mounts, one Terraform stack each**, all built from one shared module. Each mount has: - 300 roles, each bound to 10 namespaces and 10 service accounts; - 10 policies. - **One platform stack** holds: - 10 KV v2 stores; - AppRole, JWT and TLS certificate auth; - an SSH CA and a PKI root CA, with 50 roles each. - **20,000 secrets** written straight into the KV stores through Vault's API, outside Terraform, the way application teams actually write them. That is **37,707 Terraform resources in 121 stacks**. Every change went through Nojam's normal flow: 1. a pull request; 2. a plan for each affected stack, summarised on the pull request; 3. approval by a second person; 4. an apply of exactly the approved plan. ## What we did to it 1. **Bootstrap.** All 121 stacks created from nothing. 2. **The change everyone fears.** One line added to the shared module, so all 36,000 roles in all 120 mounts are updated in one pull request. 3. **An ordinary day.** One team adds five roles to its own mount. 4. **A platform change with live data.** The KV stores' settings change while the 20,000 secrets sit in them. After each phase the test checked the exact number of stacks planned and resources changed. Anything planned that shouldn't have been, or anything left behind, fails the test. ## How it went | Phase | Stacks | Resources changed | Time | Failures | | --- | --- | --- | --- | --- | | Bootstrap | 121 | 37,707 | 1 h 6 min | 0 | | Shared module change | 120 | 36,000 | 1 h 24 min | 0 | | One team, five roles | 1 | 5 | 24 s | 0 | | Platform change, secrets in place | 1 | 10 | 21 s | 0 | - **Every phase changed exactly what it should, and nothing else.** The module change planned 120 stacks and updated 36,000 roles. The team's change planned one stack. The platform change updated the 10 KV stores, and all 20,000 secrets were still there afterwards. - **Nojam stayed small.** With 37,707 resources under management: - the server's memory stayed under 16 MB; - its database stayed under 70 MB; - Vault used about 1 GB. The time goes into OpenTofu and Vault, where it belongs. - **A team's change doesn't slow down as the estate grows.** Five roles in one mount took 17 seconds in a 20-mount estate and 24 seconds in a 120-mount one. Each stack plans only its own state. ## And with more than one job at a time? We repeated the 20-mount version on a small server with two dedicated CPUs, running one, two and then four jobs at once: | Jobs at once | Bootstrap (21 stacks) | Shared module change (20 stacks) | | --- | --- | --- | | 1 | 2 min 34 s | 3 min 0 s | | 2 | 2 min 8 s | 2 min 34 s | | 4 | 2 min 6 s | 2 min 30 s | The lesson is plain: - **Dedicated CPUs mattered most.** The same work took 5 min 57 s in our first run, on one shared CPU, and 2 min 34 s here. - **Running jobs side by side helped up to the number of CPUs, and then stopped helping.** On that box, OpenTofu, Vault and the database were all competing for the same two CPUs. - **Every run was still exact and failure-free.** Capacity grows with CPUs. Give each runner host as many slots as it has CPUs, add hosts as you need, and keep Vault on its own machines. Nojam itself used under 9 MB of memory throughout. ## What the test caught The first, smaller run (20 mounts) found a real bug. When one change touched many stacks, the summary Nojam posts on the pull request grew past GitHub's 65,536-character comment limit. GitHub refused it, and the pull request kept showing an out-of-date status table. An approval in Nojam is always tied to the exact plan, so nothing wrong could be applied. But reviewers deserve a page that is current. We fixed it before the full run. The summary now always keeps: - the status of every stack; - every destructive change; - the approval instructions. The full detail for stacks that don't fit points to the Nojam UI. At 120 stacks the largest summary was 60 KB, and GitHub accepted every one. The test also surfaced three Vault provider configurations that never settle and show a change on every plan: - a PKI TTL written as `"720h"`, which Vault returns in seconds; - a JWT public key with a trailing newline; - keys generated inside the configuration. They are mistakes in Terraform code, not in Nojam, but real teams make them. They are now in our documentation. ## The fine print We would rather you hear the conditions from us: - **A deliberately small machine.** The main run used one CPU for everything: Nojam, PostgreSQL, Vault and OpenTofu. One runner ran one job at a time. The hour-long phases are 120 jobs back to back. More runners run them side by side. - **A test Vault.** Vault ran in development mode, in memory, and GitHub was simulated. A production Vault with persistent storage and audit devices answers more slowly, so expect longer plans. - **No speed-up of Terraform itself.** Nojam doesn't make a single plan faster. It plans only the stacks a change affects, applies the approved plan without planning again, and makes it safe to split state so that plans stay small. These are our first tests at this size, and we'll publish the next ones the same way. --- Canonical page: https://nojam.io/blog/on-our-first-tests/ Site map for AI agents: https://nojam.io/llms.txt # Nojam documentation How to install and run Nojam, set up Vault for it, move from one shared state to one per namespace, and check its security. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. ## Start here - [Install Nojam for a pilot](https://nojam.io/docs/install.md): The host, the GitHub App, the Vault role, the runner image and the checks to run before production. - [Your first pull request](https://nojam.io/docs/first-pull-request.md): A stack in runner.yaml, a plan on the pull request, an approval and an apply, end to end. ## Concepts - [Stacks and targets](https://nojam.io/docs/stacks-and-targets.md): How a repository declares stacks, how each stack maps to targets such as dev, uat and production regions, and how they are discovered. - [Plans and approvals](https://nojam.io/docs/plans-and-approvals.md): What is planned on a pull request, who may approve, how approval binds to the plan, and when a merge needs approval again. - [Vault credentials for jobs](https://nojam.io/docs/vault-credentials.md): How a job logs in to Vault, the sealed hand-over, read-only plan roles, apply roles bound to main, and revocation. - [Deployments and rollback](https://nojam.io/docs/deployments-and-rollback.md): Promotion order, canary regions, all-or-nothing deployments, and what rollback restores and what it cannot. ## Vault - [Vault setup](https://nojam.io/docs/vault-setup.md): What Nojam needs on each cluster: the JWT auth mount, the roles, the policies and the issuer, with a platform stack in Terraform. - [Namespaces and vending](https://nojam.io/docs/namespaces.md): One namespace per team on Vault Enterprise, and creating a team namespace from one line in teams.yaml. - [Splitting a shared state](https://nojam.io/docs/state-split.md): Moving from one shared state to one per namespace with nojam state split, proven with zero-diff plans before anything applies. - [Protection rules](https://nojam.io/docs/protection.md): The built-in baseline, break-glass, critical mounts, grants across namespaces and your own rules by Vault path. - [Providers and modules](https://nojam.io/docs/providers.md): The provider mirror, the allow-list, lock files, provider changes on the pull request, and module pinning. ## Operating Nojam - [Configuration reference](https://nojam.io/docs/configuration.md): Every server and runner setting, runner.yaml, sign-in, ServiceNow, OPA, audit anchoring and compliance streaming. - [Pipeline steps](https://nojam.io/docs/pipeline-steps.md): Your own checks after every plan, declared once by the platform team, that a pull request cannot drop. - [High availability](https://nojam.io/docs/high-availability.md): Several replicas on PostgreSQL, leader election, durable webhooks and fenced runner attempts. - [Alerts](https://nojam.io/docs/alerts.md): The Prometheus alert rules and the runbook for each one. - [Backup and restore](https://nojam.io/docs/backup-and-restore.md): What to back up, how to restore, and the restore drill. - [Retention](https://nojam.io/docs/retention.md): What Nojam keeps and for how long: webhook payloads, plan files, job logs and the audit log. - [Support bundle](https://nojam.io/docs/support-bundle.md): What to send when something is stuck, and what is never in it. ## Security - [Threat model](https://nojam.io/docs/threat-model.md): What Nojam protects, the actors and trust boundaries, the threats and controls, and the open items. - [Cryptographic inventory](https://nojam.io/docs/cryptography.md): The keys Nojam holds and the algorithms it uses. - [Security testing](https://nojam.io/docs/security-testing.md): The checks on every change, the fix time frames, and how findings are handled. - [Verifying a release](https://nojam.io/docs/verifying-releases.md): Checking cosign signatures, SBOMs and SLSA provenance before you install. --- Canonical page: https://nojam.io/docs/ Site map for AI agents: https://nojam.io/llms.txt Start here # Install Nojam for a pilot The host, the GitHub App, the Vault role, the runner image and the checks to run before production. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/install/ Site map for AI agents: https://nojam.io/llms.txt Start here # Your first pull request A stack in runner.yaml, a plan on the pull request, an approval and an apply, end to end. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/first-pull-request/ Site map for AI agents: https://nojam.io/llms.txt Concepts # Stacks and targets How a repository declares stacks, how each stack maps to targets such as dev, uat and production regions, and how they are discovered. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/stacks-and-targets/ Site map for AI agents: https://nojam.io/llms.txt Concepts # Plans and approvals What is planned on a pull request, who may approve, how approval binds to the plan, and when a merge needs approval again. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/plans-and-approvals/ Site map for AI agents: https://nojam.io/llms.txt Concepts # Vault credentials for jobs How a job logs in to Vault, the sealed hand-over, read-only plan roles, apply roles bound to main, and revocation. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/vault-credentials/ Site map for AI agents: https://nojam.io/llms.txt Concepts # Deployments and rollback Promotion order, canary regions, all-or-nothing deployments, and what rollback restores and what it cannot. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/deployments-and-rollback/ Site map for AI agents: https://nojam.io/llms.txt Vault # Vault setup What Nojam needs on each cluster: the JWT auth mount, the roles, the policies and the issuer, with a platform stack in Terraform. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/vault-setup/ Site map for AI agents: https://nojam.io/llms.txt Vault # Namespaces and vending One namespace per team on Vault Enterprise, and creating a team namespace from one line in teams.yaml. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/namespaces/ Site map for AI agents: https://nojam.io/llms.txt Vault # Splitting a shared state Moving from one shared state to one per namespace with nojam state split, proven with zero-diff plans before anything applies. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/state-split/ Site map for AI agents: https://nojam.io/llms.txt Vault # Protection rules The built-in baseline, break-glass, critical mounts, grants across namespaces and your own rules by Vault path. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/protection/ Site map for AI agents: https://nojam.io/llms.txt Vault # Providers and modules The provider mirror, the allow-list, lock files, provider changes on the pull request, and module pinning. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/providers/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Configuration reference Every server and runner setting, runner.yaml, sign-in, ServiceNow, OPA, audit anchoring and compliance streaming. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/configuration/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Pipeline steps Your own checks after every plan, declared once by the platform team, that a pull request cannot drop. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/pipeline-steps/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # High availability Several replicas on PostgreSQL, leader election, durable webhooks and fenced runner attempts. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/high-availability/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Alerts The Prometheus alert rules and the runbook for each one. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/alerts/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Backup and restore What to back up, how to restore, and the restore drill. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/backup-and-restore/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Retention What Nojam keeps and for how long: webhook payloads, plan files, job logs and the audit log. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/retention/ Site map for AI agents: https://nojam.io/llms.txt Operating Nojam # Support bundle What to send when something is stuck, and what is never in it. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/support-bundle/ Site map for AI agents: https://nojam.io/llms.txt Security # Threat model What Nojam protects, the actors and trust boundaries, the threats and controls, and the open items. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/threat-model/ Site map for AI agents: https://nojam.io/llms.txt Security # Cryptographic inventory The keys Nojam holds and the algorithms it uses. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/cryptography/ Site map for AI agents: https://nojam.io/llms.txt Security # Security testing The checks on every change, the fix time frames, and how findings are handled. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/security-testing/ Site map for AI agents: https://nojam.io/llms.txt Security # Verifying a release Checking cosign signatures, SBOMs and SLSA provenance before you install. **This guide is published with the first public release.** Pilot customers get the full guide now, with the source repository. [Request a pilot](https://nojam.io/pilot.md) or [join early access](https://nojam.io/early-access.md) to hear when it is out. --- Canonical page: https://nojam.io/docs/verifying-releases/ Site map for AI agents: https://nojam.io/llms.txt