Why the Free plan change forces a stay or move decision
If your team depends on HCP Terraform runs and state, the legacy Free plan ended on March 31, 2026, and remaining accounts moved automatically to the enhanced Free tier of up to 500 managed resources with unlimited users. The account still works, so the decision is not about access. It is about whether your managed resource count stays under that allowance as workspaces, environments and modules multiply. HashiCorp's announcement of the enhanced Free tier sets out the terms, and you should check them against your own inventory instead of assuming your estate fits.
The short answer has three parts. The free tier may be enough for a small estate with a stable set of resources. Paid tiers scale with resource count, and the HashiCorp pricing page lists Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per resource per month, with Terraform Enterprise quoted separately. Self-hosted OpenTofu with Terrakube or Atlantis moves the spend to infrastructure you run, state storage, and the people who operate and upgrade the platform. Neither path wins on every estate: the answer depends on how many resources you run, how much platform time your team can spare, and what your own infrastructure already costs.
Before choosing, record the current managed resource count for every workspace in the organization, then project it across the next budgeting cycle with the teams that add infrastructure. Confirm where HCP Terraform displays that count and whether it includes resources you expect to retire. Price the paid tier and the self-hosted option from the same resource count, and ask every vendor or integrator for a quote that separates one-time work from recurring cost. DeployOpen plans and implements self-hosted platforms inside your own infrastructure under a written, fixed scope, so the platform side can be quoted once your inventory is known.
What the constraint requires from your Terraform platform
The March 31, 2026 end of the legacy Free plan does not force a single answer, but every path has to meet the same requirements. Each card below names one requirement, what HCP Terraform supplies today, and the open-source component that covers it, so you can test either path against the same list.
Stay inside the managed resource allowance
The enhanced Free tier covers up to 500 managed resources with unlimited users. Before you decide, count the managed resources in every workspace, not the number of workspaces, and track how that count moves over a quarter. Count resources in every workspace now, including modules pulled in by several configurations, because a single growing stack can push the whole organization past the limit. If you move, Terrakube or Atlantis has no per-resource meter, so the question shifts to the infrastructure and people that run the platform.
Predictable cost as resource counts grow
HCP Terraform bills paid tiers per managed resource, so spend rises with every resource you add. Model your growth against the published Essentials, Standard and Premium rates, and ask HashiCorp for a Terraform Enterprise quote if you need self-managed licensing. Self-hosted cost is different in kind: Terrakube and Atlantis are Apache 2.0 software with no per-resource fee, so the recurring cost is the compute, database and state storage you run, plus the engineering time to maintain them.
Keep state and run history under your control
HCP Terraform stores each workspace's state and exposes it through the state versions API, so state is only as portable as your last export. A self-hosted path moves state into a backend you choose. Atlantis cannot use local state and needs a backend such as S3 or GCS, while Terrakube runs its own database, which Liquibase-supported databases such as PostgreSQL can host. Confirm where state, plan logs and run history will be stored, who can read them, and how they are backed up.
Encrypt state and plans at rest
State files hold secrets in plain text, so the storage path matters as much as the platform. OpenTofu encrypts state and plan files on the client side before they reach local storage or a remote backend, using key providers such as AWS KMS, GCP KMS, OpenBao or Azure Vault. Decide which key provider your organization already governs, and confirm that the chosen run platform does not store unencrypted copies of plans in its logs or artifacts.
Keep existing configurations working
Your .tf files, modules and provider versions represent years of work, and a platform change should not rewrite them. OpenTofu is a drop-in replacement for Terraform that preserves existing workflows and configurations, but the OpenTofu FAQ does not guarantee compatibility with future Terraform releases. Run tofu init and tofu plan against a copy of each workspace and expect no changes before any production state moves. Also check any terraform_remote_state data sources, which OpenTofu's migration guide flags for extra care.
Own the run platform and its license
HCP Terraform runs are operated by HashiCorp, so access control, uptime and upgrades follow its roadmap. A self-hosted run platform puts those decisions with your team, and the license terms matter more than they did before the BSL change in August 2023. Terrakube and Atlantis are both Apache 2.0, and both document OpenTofu, so you can keep the CLI open source too. Confirm the license of every extension and plugin you plan to use, since some tools in the chain may be licensed differently.
How managed resources are counted and when growth forces a paid tier
HCP Terraform bills its paid tiers per managed resource, at $0.10 per resource per month on Essentials, $0.47 on Standard and $0.99 on Premium, as listed on the HashiCorp pricing page. Terraform Enterprise, the self-managed edition, is custom priced. The supplied material does not define the counting rules in detail, so confirm these points with HashiCorp's current documentation before you decide: which resource types count, whether data-only resources count, how resources destroyed during a billing period are treated, and whether billing covers every managed resource or only those above the 500-resource allowance of the enhanced Free tier. The answer to the last question decides whether your estate pays from the first resource or only beyond the allowance.
Build the inventory from state, not from source code, because module calls and count or for_each expressions decide how many instances exist. For each workspace, run tofu state pull > workspace-name.json (or terraform state pull with the current CLI) against the existing HCP Terraform backend before you cancel anything. Then count managed instances with jq '[.resources[] | select(.mode=="managed") | .instances | length] | sum' workspace-name.json, and group by the module key to see which modules drive the total. Count instances, not resource blocks, since one block with a count of 20 creates twenty resources. If you cannot pull state directly, the state versions API provides a JSON download URL for states created by Terraform 1.3 or later, and the file has the same structure.
Repeat the count whenever the configuration changes, because growth rarely shows up as a visible diff. A module that adds a for_each over regions or tenants can multiply its instance count without any change to its resource blocks. Store each summary as a dated record next to the state export, and rerun the check after major module changes. Then compare the total with the confirmed counting rules. If the count stays well under 500 managed resources and no workspace grows quickly, the enhanced Free tier may remain the lowest-cost option. If it crosses the allowance, the per-resource rates show when a paid tier costs more, and the comparison with self-hosted OpenTofu must also include infrastructure and staff time for the platform team.
Which option fits: staying on the free tier, paying or self-hosting
This table compares five routes for teams that lost the legacy Free plan: the enhanced Free tier, a paid HCP Terraform tier, Terraform Enterprise, and self-hosted OpenTofu with either Terrakube or Atlantis. Read each row against your managed resource count, your need for a workspace UI or registry, and who will run the platform. Confirm current feature lists and prices with each vendor before you decide.
| Option | How it meets the requirements | What recurs and what is one-time | Main trade-offs |
|---|---|---|---|
| Enhanced Free tier | Up to 500 managed resources with unlimited users, under HashiCorp's hosted workspace and run model | Free for organizations within the limit; no platform to run. Confirm what happens when usage exceeds 500 resources | Hosted control plane and BSL-licensed Terraform; growth beyond 500 resources moves you to a per-resource paid tier |
| Paid HCP Terraform tier | Hosted runs, state and registry, billed per managed resource on Essentials, Standard or Premium | Recurring per-resource fees; one-time work is limited to migrating workspaces and state | Cost rises with resource count; confirm which features each tier includes and whether your data location is acceptable |
| Terraform Enterprise | Self-managed edition of the HCP Terraform model, run inside your own infrastructure | Recurring license fees on custom pricing; one-time installation and hosting; ongoing upgrades and operations | Keeps the Terraform model and vendor support; needs a quote, a platform team and continued BSL-licensed Terraform use |
| Self-hosted OpenTofu with Terrakube | Remote backend and cloud block, workspace UI, private registry, VCS integrations, Dex-based SSO and group permissions, OPA and Infracost extensions | Apache 2.0 software with no license fee; recurring hosting, database, state storage and staff time; one-time setup and migration | Requires you to run the platform; confirm current extensions and supported VCS and identity options for your version |
| Self-hosted OpenTofu with Atlantis | Plan output posted as pull request comments, apply on command, and directory or workspace locking until merge | Apache 2.0 software with no license fee; recurring compute, state backend and review time; one-time atlantis.yaml and workflow work | No registry, no workspace UI and no managed state; you must provide an S3, GCS or other remote backend, and local state is not supported |
Which path fits a team's size and workflow
If your estate is expected to stay under the enhanced Free tier allowance of 500 managed resources, staying on HCP Terraform's Free tier may cost you nothing in licensing while the estate stays small. The first check is a current count of managed resources across every workspace, because that count, not the number of users or workspaces, is what the allowance measures. Confirm with HashiCorp exactly how resources are counted for your configurations, including modules and data sources, and whether the count is reviewed on a schedule.
- Count from the state, not from memory: list resources in each workspace's state and record the total per organization.
- Project the next twelve months: add planned services, environments and regions, since growth is what pushes you past the allowance.
- Watch for duplicated environments: development and staging copies of production each count toward the same total.
- Plan the exit early: if the count is close to 500, decide now whether you would move to a paid tier or to OpenTofu with Terrakube or Atlantis.
- Confirm terms in writing: ask HashiCorp what happens when the allowance is exceeded and whether there is a grace period.
Before you rely on the Free tier, confirm the current allowance and counting rules with HashiCorp, since they are the basis for every decision on this tab.
A team that is growing past the allowance but wants HashiCorp to run the service usually compares paid HCP Terraform tiers first. Those tiers bill per managed resource, so the cost follows your resource count and the tier you select. The first check is the resource count trend, combined with your data residency and support expectations, because the hosted service runs in HashiCorp's environment rather than yours. Confirm the tier features, regional options and contract terms with HashiCorp before committing.
- Model cost per resource: multiply your projected resource count by the tier rate listed on HashiCorp's pricing page and compare tiers.
- Check which features each tier includes: confirm SSO, policy, run tasks and audit features against your requirements.
- Confirm data location: ask where state and plan data are stored and processed for the hosted service.
- Ask about Terraform Enterprise: if you need a self-managed edition, request a custom quote, since its pricing is not public.
- Account for the exit path: note what would need to be exported later, including state and workspace settings.
If hosted operations remain the priority, confirm the tier, the data location and the contract terms in writing before you decide that the hosted path is still the right fit.
A team that needs run history, a workspace UI and a private registry on its own servers is the main case for Terrakube. Terrakube is Apache 2.0 licensed, supports both the remote backend and the cloud block, and can run OpenTofu as well as Terraform. The first check is data residency and identity: confirm where state, plan logs and variables must live, and which identity provider must handle sign-in and group-based permissions. Confirm with your own platform team how Terrakube's Dex-based authentication fits your identity setup.
- Map the workspace model: list organizations, workspaces, teams and VCS connections you need to recreate.
- Choose a database: Terrakube supports any relational database that Liquibase supports, so confirm which one your operations team will run and back up.
- Plan the installation method: Terrakube documents a Helm chart and Docker Compose, so decide which matches your cluster standards.
- Decide on extensions: OPA policy checks and Infracost estimates are available as extensions, and each needs its own review.
- Confirm the release you will run: check the current release on the GitHub releases page before you pin a version.
Before committing, have your platform team run a test installation and confirm that group permissions, state migration and registry use behave as your teams expect.
A team that reviews infrastructure changes in pull requests may not need a hosted run UI at all. Atlantis runs terraform plan when a pull request is opened, posts the output as a comment, and runs apply when someone comments the apply command. It is licensed under Apache 2.0 and supports GitHub, GitLab, Gitea, Forgejo, Bitbucket and Azure DevOps. The first check is the approval workflow: decide who must approve a plan before apply runs, and confirm that your version control platform and branch protection rules enforce it. Atlantis does not provide a registry, a workspace UI or managed state, so plan those separately.
- Pick a state backend: Atlantis cannot use local state, so choose an backend such as S3 or GCS and confirm access controls for it.
- Write atlantis.yaml: define projects, workspaces and custom tfvars layouts for each repository.
- Set the approval gate: confirm that apply requires an approved pull request and that directory locks behave as your change process expects.
- Run OpenTofu if wanted: Atlantis supports OpenTofu through a custom workflow with the tofu binary in an init container.
- Confirm team access: check which people may comment apply and who can delete a stuck lock.
Before adopting this model, test the approval gate and lock behavior on a non-production repository so you understand how your reviewers will use it.
How to deploy a self-hosted OpenTofu platform before the cutover
This sequence moves an HCP Terraform estate onto OpenTofu with Terrakube or Atlantis in your own infrastructure, proving each workspace produces the same plans before the hosted workspaces are retired.
Inventory workspaces, managed resources and integrations
The platform owner lists every HCP Terraform organization, workspace, managed resource count, variable set, VCS connection, team and registry module, and notes which workspaces share data through the terraform_remote_state data source. Count managed resources per workspace now, because that count determines whether the enhanced Free tier of 500 managed resources still covers the estate. This step is done when the inventory names an owner and a cutover order for each workspace, and the shared-state dependencies are flagged for separate review.
Back up state and code before any change
Before anything else changes, the team takes a copy of the code repositories and downloads the current state of every workspace. This is the first step of the OpenTofu migration overview, which describes backing up state and code as the start of a process designed to be safe and reversible. Store the backups in a location the HCP Terraform workspace does not control. This step is done when each workspace has a state file and a matching commit reference that the team can restore from.
Export each workspace's state through the state versions API
For each workspace, the operator calls the HCP Terraform state versions API and downloads the current state, using the JSON download URL where the state was created by Terraform 1.3 or later. Record the serial and the source version alongside each file so the copy can be matched to the hosted state later. Do not start a run in the hosted workspace during the export. This step is done when every exported file opens as valid state and its serial matches the value recorded in the hosted workspace.
Deploy Terrakube or Atlantis in your infrastructure
The platform team installs Terrakube with its Helm chart or Docker Compose, or installs Atlantis with one of its documented deployment methods, inside the cloud account, data center or network the organization controls. Terrakube needs a supported relational database, such as PostgreSQL, and Atlantis needs a remote state backend such as S3 or GCS, since it cannot use local state. Confirm the chosen database or backend, backup schedule and access path with the vendor documentation before go-live. This step is done when the instance starts, accepts a test login or webhook, and has a tested restore path for its own data.
Configure identity, VCS connections and access groups
The identity team connects the platform to the identity provider through Dex in Terrakube, or to the chosen forge and webhook settings in Atlantis. Rebuild VCS links for GitHub, GitLab, Bitbucket or Azure DevOps and map permissions on workspaces, modules and connections to groups rather than individual users. Store cloud credentials and state encryption keys in the organization's secrets store. This step is done when a test user sees only the workspaces their group allows and a test commit triggers the expected run or plan.
Switch one non-production workspace to OpenTofu
Choose a non-production workspace with a small resource footprint and point its cloud block or remote backend at the new platform, with the CLI switched to the tofu binary. Import the state exported in step three, then run a plan. The OpenTofu migration overview describes initializing and verifying the configuration before any change, and the expected result is a plan that reports no changes. If the plan shows changes, stop and find the cause before touching another workspace. This step is done when the plan is clean and the team has recorded the output.
Verify outputs and run a small test change
The team compares outputs, provider versions and tag values between the hosted workspace and the new one, then makes one small, reversible change, such as a tag update, and applies it through the new platform. The migration overview's final step is this small-change test, and it confirms that runs, locks and state writes behave as expected. Check that the change appears in state with a new serial. This step is done when outputs match, the test change applies cleanly, and a second plan again reports no changes.
Move remaining workspaces and freeze the hosted originals
The team repeats the export, import, plan and verification sequence for each remaining workspace in the agreed order, handling shared-state workspaces last and with the extra care the migration overview recommends. Keep each HCP Terraform workspace set to read-only, blocking new runs and state writes, until its verification is signed off. Retire the hosted workspaces only after the owner confirms that every plan is clean and the exported backups are stored. This step is done when every workspace has a signed-off verification record and the hosted originals are no longer used for runs.
What changes in state, configurations and remote data sharing
State is the first thing to move, and it leaves HCP Terraform through the state versions API. For each workspace, the current state can be downloaded through that API, including a JSON download URL for states created by Terraform 1.3 or later. Confirm the Terraform version that produced each state before you plan the download, because older states follow a different path. Whichever platform you choose, it needs a permanent state backend. Atlantis cannot use local state because it has no permanent storage and does not commit state files back to version control, so you must pick an S3, GCS or similar backend before the first pull request run. Terrakube's remote backend also supports migrating state, which is worth checking against your own workspaces.
Configurations that read other stacks need a separate review before cutover. OpenTofu's migration guidance warns that configurations sharing data through the terraform_remote_state data source typically need additional care, and it links a separate guide for that case. Make an inventory of every root module that reads another workspace's outputs, and note which producer and consumer are on the legacy Free plan. If a producer moves to a new backend while a consumer still points at HCP Terraform, the consumer may read stale or missing outputs. Plan a sequenced cutover per dependency chain rather than moving workspaces one at a time without checking their readers.
Decide on client-side encryption during setup, and plan for the compatibility caveat. OpenTofu encrypts state and plan files at rest, for local storage and remote backends, using key providers that include AWS KMS, GCP KMS, OpenBao and Azure Vault, among others. Choose the key provider with your security team before the first migrated state is written, because changing it later means re-encrypting existing state. Also note that OpenTofu aims to keep feature parity with Terraform, but the project decides which features it adopts, so compatibility with future Terraform releases is not guaranteed. Test your configurations against each OpenTofu release you pin, and record which Terraform features your modules depend on.
Questions teams ask before they choose between staying, paying and self-hosting
What does the self-hosted path cost, and which parts are one-time?
The self-hosted path has no per-resource licence fee for OpenTofu, Terrakube or Atlantis, so the cost sits in components you pay for: the infrastructure that runs the platform, a database for Terrakube, state storage in your cloud account or data center, and the people who install, patch, back up and support it. Setup work, such as the first installation, identity integration, workspace re-creation and the migration itself, is one-time. Infrastructure, state storage, backups, upgrades and on-call time recur every month or year. Ask any implementation partner for a written quote that separates these lines, and compare it with your current managed resource count multiplied by the rate on your own plan. The HashiCorp pricing page lists Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per managed resource per month, and Terraform Enterprise at custom pricing.
How long does a migration take, and what makes it longer?
Duration depends mostly on how many workspaces you run, how much state each one holds, and how many inherit data through the terraform_remote_state data source. A small set of workspaces with no shared state can move in a short programme, while a large estate with many VCS connections, teams and custom pipelines takes longer. OpenTofu's migration guide describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, and test with a small change. It also warns that configurations sharing data through terraform_remote_state need additional care. Other drivers are the number of VCS connections, the identity integration you need through Dex or your existing provider, and how many pipelines call the CLI directly. Ask for a timeline tied to a written scope rather than a generic estimate.
What does our internal team need to provide?
Your team needs ownership of the decision, access to the cloud accounts or clusters where the platform will run, and people who know the workspaces well enough to confirm variables, team permissions and VCS links. Platform engineers must be able to operate a Kubernetes or Docker deployment, a relational database, and a state backend such as S3 or GCS if you use Atlantis. Security reviewers should own the identity provider configuration and the OpenTofu state encryption key provider choice, such as AWS KMS, GCP KMS or OpenBao. Someone must also be accountable for upgrades, since Terrakube 2.33.2 and Atlantis v0.48.1 are current examples of releases you will track over time. Confirm these roles with your own staff before you commit to a scope.
Can our team run this without outside help?
Teams with strong Kubernetes, CI and Terraform experience can often run Atlantis or Terrakube in-house, because both are Apache 2.0 projects with public documentation and Helm chart or Docker install paths. The harder parts are usually not the installation but identity integration, state migration without downtime, hardening, backups, and the ongoing upgrade cycle. If your team has no one who can own those areas, an outside partner can plan, implement and document them, then hand over or support the platform under a retainer. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts.
How do we keep the paid tier as a fallback during cutover?
Keep your existing HCP Terraform organization active and unchanged until every workspace has been verified on the new platform. Download current state through the state versions API before any change, and keep those backups in a location you control. Run a small change against a non-production workspace first, then move production workspaces one at a time. Because OpenTofu is designed as a drop-in replacement, a rollback to Terraform or to the previous backend is possible if the state and configuration were backed up first. Do not delete workspaces or cancel the subscription until the new pipeline has completed several successful plans and applies. Confirm with HashiCorp how your plan's billing and cancellation terms apply during a parallel run.
What should we ask for in a written quote?
Ask for a fixed scope listing each workspace, VCS connection, identity integration, state backend and the target platform, whether Terrakube or Atlantis. Request deliverables with named outputs, such as documented runbooks, backup and restore tests, and a migration checklist per workspace. Ask which items are one-time and which are recurring, and whether support, upgrades or continuous testing are separate retainers. Confirm who provides the infrastructure, who pays for cloud usage, and what happens if a workspace turns out to depend on terraform_remote_state. Also ask how changes to scope are priced and what acceptance criteria close the engagement. A quote should follow from that written scope.
Are OpenTofu and Terrakube licensed for commercial use?
Yes, both are open-source licences that permit commercial use. Terrakube and Atlantis are licensed under Apache 2.0, and OpenTofu is licensed under the Mozilla Public License 2.0. Both licences allow you to run the software inside your organization, including for commercial purposes, subject to their conditions such as retaining notices. Licence terms are not legal advice, so have your counsel review the specific licence texts and any third-party extensions or images you add. Note that OpenTofu's compatibility with future Terraform releases is not guaranteed, since its FAQ describes an aim of feature parity while the community decides which features it adopts.
Evidence to keep for the decision and the cutover
A move off the legacy Free plan is easier to defend when each step leaves a dated record. The cards below cover what a CIO, auditor or finance lead is likely to ask for, from the resource count to the sign-off on each workspace. DeployOpen can prepare these records, but independent auditors and certification bodies issue any attestation.
Dated resource inventory
Record every workspace, its managed resource count and the date you counted it, along with the counting method you applied. The count must match the vendor's definition of a managed resource, so confirm that definition with HashiCorp before you rely on the number. Keep the inventory from before and after the March 31, 2026 change, so the baseline for the 500-resource Free tier is visible to anyone who reviews the decision.
Plan and billing records
Keep the HCP Terraform plan and invoice history for each period before and after the move, including any paid tier charges per managed resource. Finance needs these to compare what was paid with the estimated cost of running Terrakube or Atlantis. Ask your account contact which billing documents are available for download, because the format and history depth vary by account.
State export checksums and encryption
For each exported state file, record a checksum taken at download and again after it lands in the new backend, so you can show it was not altered in transit. Record the encryption configuration too, including the key provider and key identifier used for OpenTofu state and plan encryption. Store these records apart from the state files themselves.
First OpenTofu plan output
Save the plan output from the first run after switching to OpenTofu for each workspace. Compare it with the last plan from HCP Terraform on the same configuration, and treat any unexpected diff as a blocking finding until it is explained. This record shows that the switch did not change the infrastructure the code describes.
Access and group assignments
Export the group memberships and workspace permissions set in Terrakube or the pull request approval rules set in Atlantis. Auditors will check that only the people who held access in HCP Terraform have equivalent access, and that no one gained rights during the cutover. Record the identity provider configuration used for sign-in as well.
Workspace sign-off records
Keep one signed record per workspace moved, naming the owner, the state checksum, the first successful plan and the date the HCP Terraform workspace was disabled. Mark any workspace held back, along with the reason, so the inventory and the sign-offs reconcile. Each record gives a rollback point if a later issue traces back to the move.
How DeployOpen plans the move from HCP Terraform to self-hosted OpenTofu
DeployOpen starts with a written scope that records which HCP Terraform workspaces, managed resources and integrations you run today, then decides whether you stay on the enhanced Free tier, move to a paid tier or self-host OpenTofu with Terrakube or Atlantis. We plan and implement the self-hosted path inside your own cloud accounts or data centers, and we document each step so your team can run it afterward.
How we scope
- We inventory workspaces, managed resource counts and VCS links so the written scope reflects your actual footprint.
- The scope states whether the target is the enhanced Free tier, a paid HCP Terraform tier or a self-hosted Terrakube or Atlantis platform.
- Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before any migration work begins.
How we build
- We install the chosen platform in your infrastructure, pairing Terrakube with its remote backend or Atlantis with your pull request workflow.
- We back up current state through the state versions API, verify each workspace and test with a small change before cutover.
- Where you choose OpenTofu, we configure state and plan encryption with your key provider and check remote_state dependencies first.
How we hand over
- We document workspace layouts, variables, access groups and runbooks so your platform team can operate the system independently.
- We provide a rollback path for each migrated workspace, keeping the original HCP Terraform state available until cutover is confirmed.
- We walk your engineers through the CLI login, run triggers and atlantis apply or run approval steps with recorded sessions.
How we support
- Ongoing support, platform upgrades and continuous testing are available as a retainer after handover is complete.
- Upgrades to Terrakube, Atlantis and OpenTofu releases are planned and tested against your configurations before rollout.
- Compliance readiness work prepares systems and evidence for your assessors, while independent auditors issue any audit reports.
