Does self-hosting Terrakube cost less than Scalr per run?
Terrakube itself carries no license fee, because it is licensed under Apache 2.0, so the comparison turns on what Scalr bills per run against what you pay to host, operate and migrate. If your renewal or invoice rises with pull requests and environments, ask Scalr for a written quote that states exactly how it counts a run, whether dry runs (plans without applies) are included, and how the price changes as volume grows. The Scalr pricing itself is not part of the information available here, so take those figures from Scalr's quote rather than from this page. Then price your side of the comparison, which is the part you control.
On the self-hosted side, the recurring costs are the infrastructure that runs Terrakube (installed with a Helm chart or Docker Compose), a relational database supported by Liquibase such as PostgreSQL, executor capacity sized to your concurrent runs, and the staff time to patch and upgrade the platform. Terrakube 2.33.2 was released on September 14, 2026, so plan a recurring upgrade cadence and check the Terrakube releases page for changes before each one. The one-time costs are the migration of state, workspaces, variables and VCS connections. Dry runs typically count toward a per-run bill, but on Terrakube they show up as executor and database load, so plan-heavy pull request workflows still need capacity.
The break-even point depends on two inputs: your run volume and how many people on your team can operate the platform without outside help. Confirm the run count for the last twelve months from your Scalr usage data, estimate the hours your platform team would spend on backups, upgrades and incidents, and compare that with the quoted per-run cost. If the internal skills are thin, ask for a fixed-scope implementation from DeployOpen, with scope, deliverables and timelines agreed in writing before work starts, and consider a retainer for ongoing support and upgrades. Ask any implementation partner to show its assumptions in the quote so you can test them against your own numbers.
Which cost components change when you self-host Terrakube
This table compares the cost components of running Scalr with those of running Terrakube in your own cloud or data center, and marks which ones are one-time and which recur. Scalr's per-run billing counts dry runs as well as applies, so confirm the exact metering terms in your order form before you model usage. The main takeaway is that Terrakube removes the license and per-run fees but moves hosting, compute, upgrades and support to your team or your implementation partner.
| Cost component | Commercial side (Scalr) | Self-hosted side (Terrakube) | One-time or recurring |
|---|---|---|---|
| Software license | Subscription plus per-run billing; dry runs count as well as applies | Terrakube is Apache 2.0 with no license or per-run fee | Recurring for Scalr; none for Terrakube software |
| Run and state platform | Scalr hosts runs and state; confirm where state is stored and retained | You host the Terrakube API, UI and state storage in your own infrastructure | Recurring |
| Compute for runs | Scalr agents or hosted capacity; confirm what the subscription includes | Executors you size, run and scale with run volume | Recurring |
| Database | Managed by Scalr as part of the service | PostgreSQL, MySQL, Oracle or SQL Server through Liquibase; you provision and back it up | Recurring |
| Identity and SSO integration | Available per plan; confirm which identity providers are included | Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML; you map groups | One-time setup, then recurring upkeep |
| Migration effort | Confirm with Scalr what export help exists for workspaces, variables and VCS links | Pull state through the remote backend, recreate environments, variables, VCS links and policies | One-time |
| Upgrades | Handled by Scalr as part of the subscription | You plan, test and apply Terrakube releases and database changes | Recurring |
| Support | Depends on your subscription tier; confirm response terms in writing | Depends on your arrangement; compare community options with a scoped retainer | Recurring |
| Internal skills | Admins learn Scalr workspace, policy and agent concepts | Staff need container platform, database and identity administration skills | Recurring |
What moves the comparison most
Scalr's bill and the cost of running Terrakube respond to different inputs, so the comparison turns on a few operating facts about your own estate. Each card below names one driver, the direction it pushes cost, and the figure to pull from your own run logs and change records before you ask for a quote.
Run volume including dry runs
Scalr bills per run, and dry runs count alongside applies, so a plan-heavy workflow raises the bill even when few changes reach production. Self-hosted Terrakube has no per-run fee, so its cost moves with executor capacity and storage rather than with how often engineers plan. Pull a 90-day count of plans and applies per workspace from your own run history, then separate dry runs from applies, and check which of those runs Scalr's pricing actually counts.
Workspaces and environments
Scalr's commercial terms depend on how environments and workspaces are counted, so growth in either changes the quote in ways that are not always linear. In Terrakube, each additional workspace adds database rows and a few queued runs, and the main new cost is the work of organizing them under groups and permissions. Ask the vendor how workspaces and environments are metered and count yours today and in the next year of planned projects.
Number of VCS repositories
Each connected repository adds webhook traffic, a VCS connection to maintain and a set of permissions to keep aligned with identity groups. Terrakube retrieves code from GitHub, GitLab, Bitbucket and Azure DevOps, so cost rises with the number of connections and the upkeep of their tokens and access. List every repository that triggers runs and note who owns each connection, because unowned connections are the ones that break during staff changes.
Availability and on-call needs
A hosted service carries the uptime work for the run platform, while a self-hosted Terrakube makes your team responsible for the database, executors, upgrades and recovery. The cost is mostly staff time and on-call rotation, and it grows if pipelines block releases or policy gates. Confirm the required run availability and the hours your teams expect support, then price that coverage against the work of keeping an in-house platform patched and monitored.
Data residency and air-gap requirements
If state files, plans and variables must stay inside specific accounts, regions or networks, a hosted run service may need extra contractual review or may not fit the requirement at all. A self-hosted Terrakube keeps state in your own database and storage, but it also requires you to build the network paths and backups for that footprint. OpenTofu can encrypt state and plan files on the client side with key providers such as AWS KMS, GCP KMS and OpenBao, which can reduce what a platform operator can read. Document where state and plan files are stored and which key provider protects them before comparing costs.
Internal platform skills
Running Terrakube well requires people who can operate a Kubernetes or Docker Compose deployment, a relational database supported by Liquibase, and Dex-based identity integration. Teams that already run these platforms carry lower one-time migration effort and lower recurring effort, while teams without them should price training or an implementation partner into the first year. Inventory who on your team already runs databases, identity providers and container platforms, and record how many hours each change takes today.
How to build the comparison with your own numbers
This sequence turns Scalr's per-run billing and your own workspace inventory into a like-for-like total cost of ownership for a self-hosted Terrakube setup over a period you choose. Each step produces a figure you can check against your invoices and quotes.
Export twelve months of run counts from Scalr
Ask your Scalr administrator or account contact to export run history for the last twelve months, split into plan, apply and dry run runs for each workspace and environment. Confirm with Scalr how it counts dry runs and failed runs, because the billing definition decides whether those runs add to your total. The step is done when you have one table with monthly totals per run type and a written note of Scalr's counting rules.
Obtain the written per-run quote from Scalr
Request a written quote from Scalr that states the per-run rate, any included run allowance, the volume tiers that apply, minimum commitments and the treatment of dry runs and retries. Ask which of your run types are billable and whether any are excluded. The step is done when the quote is on file and every billing rule in your run table can be traced to a line in it.
Inventory workspaces, environments, state and VCS links
List every workspace and environment, its Terraform or OpenTofu version, the size of its state file, the number of resources it manages, its VCS connection and the team that owns it. Note which workspaces use agents and which variables or policies they depend on. The step is done when the inventory covers all workspaces, because the executor sizing and migration price in later steps depend on it.
Estimate executor and database hosting in your cloud
Using the run counts and concurrency needs from your inventory, estimate the compute for Terrakube executors and the relational database it needs, in the cloud accounts or data centers you already run. Ask your platform team for current instance and database prices from your provider, and include storage for state backups, logging and ingress. The step is done when you have a monthly hosting figure with its assumptions written beside it, such as peak concurrent runs and retention period.
Price the one-time migration as a fixed-scope quote
Request a fixed-scope quote for the migration work: pulling state through the remote backend, recreating environments, variables and VCS links, porting OPA policies, replacing Scalr agents with Terrakube executors and switching each workspace's backend configuration. Ask for the scope, deliverables and timeline in writing before work starts. The step is done when the one-time cost is a signed figure tied to the inventory from the previous step.
Price recurring operations as a fixed-scope quote
Separate the recurring cost of running the platform: upgrades to Terrakube and OpenTofu, patching, backups, monitoring, access reviews and on-call coverage. Your own staff time counts here too, so record the hours your team expects to spend each month. Ask any implementation partner whether support is offered as a retainer and what the written scope covers. The step is done when recurring costs are listed by component with an owner for each.
Compare totals over a stated period
Add the one-time migration cost to the recurring hosting and operations cost for the period you choose, and set it against Scalr's per-run charges for the same period using your twelve-month run data. Show the result with its assumptions, and run it again with higher and lower run volumes to see what changes the outcome. For reference only, HashiCorp's pricing page lists HCP Terraform paid tiers at $0.10, $0.47 and $0.99 per resource per month, and Terraform Enterprise at custom pricing, so state that source if you include it. The step is done when one document shows both totals, their assumptions and the quotes they rest on.
How the two run models differ by team size and setup
For a small team with a handful of workspaces, the per-run invoice is the most visible cost, and it is easy to see how it grows with plan and apply volume. The self-hosted side is mostly a fixed block of hosting and one person's time to install, upgrade and back up the platform. Illustrative: a team that runs a few pipelines each week may find the invoice modest, while the hours spent on operations are less visible.
- Invoice shape: Confirm how Scalr counts dry runs, applies and retries under your current contract, since those counts drive the bill.
- Hosting: Terrakube can be installed with a Helm chart or Docker Compose, so a small footprint can stay modest, but compute and database storage still recur.
- Operator time: Identify who installs, patches and backs up the platform, and whether that person has other duties.
- Atlantis option: For pull-request-only work, Atlantis may need less to run, though it does not host state or a module registry.
Ask your current vendor for a sample invoice and your run count for the last year, then compare them with the hours your team would spend on upgrades.
At scale, per-run billing grows with the number of environments and with every run a pipeline produces, including dry runs triggered by each pull request. Self-hosting moves cost toward shared infrastructure, executor capacity and the ongoing work of the platform team. Illustrative: an organization with many environments may see run volume, not environment count alone, drive its invoice.
- Run volume: Count runs per environment per week, including pull request plans and drift checks, because they often outnumber applies.
- Executors: Terrakube executors handle concurrent runs, so plan capacity for peak merge windows rather than average load.
- Shared modules: The Terrakube private registry can hold Terraform modules and providers; confirm it fits your module versioning process.
- Policy and cost tooling: Terrakube extensions add OPA policy checks and Infracost estimates; confirm these match your existing review workflow.
- Platform staffing: Name the engineers who would own upgrades, the database, and access groups for each environment.
Model the cost per environment for both options using your actual run logs, and include the staff hours the platform owner would spend.
When state files, plans and credentials must stay in a named region or on your own network, the cost question changes. The per-run invoice may matter less than whether the platform can be placed where the data must live. Self-hosting puts Terrakube or Atlantis, the state backend and the database inside your boundary, and shifts cost toward controls, evidence and operations.
- Placement: Host the platform, its database and its backups in the region or network your data rules require.
- State encryption: OpenTofu supports client-side encryption of state and plan files with key providers such as AWS KMS, GCP KMS and OpenBao; confirm who controls the keys.
- Access control: Terrakube assigns permissions by group through Dex-backed identity providers; map those groups to your existing approval roles.
- Evidence: Budget time for logging, change records and access reviews that a managed vendor might otherwise supply. DeployOpen prepares controls and evidence, but independent auditors decide sufficiency.
- Vendor data handling: Ask Scalr, in writing, where run logs, state and plans are stored and for how long.
Confirm placement, key custody and evidence requirements with your assessor before comparing invoices.
What moving state out of Scalr costs in time and risk
State leaves Scalr through the remote backend, so the migration cost is mostly verification, locking discipline and backend reconfiguration rather than new software. Each workspace's state has to be pulled from Scalr's storage, validated against the live infrastructure, and then written to the Terrakube backend before any run is allowed to touch it. The work is one-time, but its size grows with the number of workspaces, the number of resources in each state file, and how many teams share a workspace. Confirm the exact export path with Scalr's documentation and your account team, including whether state can be downloaded per workspace and in which format, before you estimate the effort. Then compare that path with the Terrakube CLI-driven workflow documentation, which describes the remote backend, the state migration support and how terraform login authenticates against the Terrakube API hostname.
Locking discipline is the main operational risk during the cutover. A workspace that is still being planned or applied in Scalr while its state is copied can produce a state file that no longer matches the infrastructure. Freeze runs in each workspace, confirm that no run is pending, and record the state serial or version before and after the copy. Reconfigure the backend block or cloud block only after the copied state has been checked with a plan that shows no unexpected changes. Keep the Scalr workspace read-only for a defined rollback period so the previous state can be restored if a verification step fails.
The costs that recur are the ones you take on after cutover: database and executor capacity, upgrades, backups of the state store and the time spent on access and policy maintenance. Ask any implementation partner for a written scope that lists the workspaces in scope, the verification steps for each, the rollback criteria and who signs off on each cutover. A fixed scope makes the one-time cost predictable, and it makes it clear which risks are yours to plan for, such as a state file that cannot be exported cleanly or a workspace whose variables depend on Scalr-specific features.
Questions buyers ask before comparing Scalr and Terrakube costs
Is Terrakube free to use?
Yes, the software is licensed under Apache 2.0, so there is no license fee to run it. The cost is what you operate: compute for the Terrakube services, which install with a Helm chart or Docker Compose, a supported relational database such as PostgreSQL, executors that run Terraform or OpenTofu, storage, backups, and the staff time to run it. Zero license cost does not mean zero total cost. Ask for a written scope that lists each component, who provides it, and what recurs each month.
How do dry runs affect Scalr cost?
Under per-run billing, every counted run adds to the bill, and dry runs (plans without an apply) are counted alongside applies. Teams that plan often, through pull requests or scheduled drift checks, see run volume grow even when few changes reach production. Confirm the exact counting rules, any included allowance and the overage terms in Scalr's current agreement. Then pull a run history from your own workspaces and ask for a calculation based on it. Self-hosted Terrakube has no per-run meter, so plan frequency mainly changes compute and executor load.
Can our team run Terrakube without outside help?
It depends on your container platform skills, database administration, identity integration and how many workspaces and VCS connections you need. Terrakube documents Helm and Docker Compose installs and a minikube test path, and it authenticates through Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. Platform teams often run a pilot in-house. Teams that also need hardening, tested backups and documented controls for an assessment may prefer a fixed-scope engagement, in which DeployOpen plans, implements, hardens and documents the platform inside your own environment.
How long does a migration from Scalr take?
No fixed duration applies to every team. The main drivers are the number of workspaces, the size and backend type of each state file, how many environments, variables and VCS links must be recreated, how many OPA policies need porting, how many Scalr agents must be replaced with Terrakube executors, and how many teams must cut over. Terrakube supports the remote backend and state migration, and users authenticate with terraform login against the Terrakube API hostname. Start with a written inventory, then agree a fixed-scope plan and timeline before work begins.
What ongoing work does a self-hosted Terrakube need?
The recurring work includes applying Terrakube releases, such as the 2.33.2 release published on September 14, 2026, which shows how often upgrades arrive. Other tasks are database maintenance and tested backups, executor image updates, managing which Terraform and OpenTofu versions executors support, keeping Dex and identity settings current, monitoring, security patching and updating extensions such as OPA policy checks and Infracost estimates. Decide early who owns each item. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope and frequency are agreed in writing.
Is Atlantis cheaper for pull-request-only use?
Atlantis is also Apache 2.0 and runs in your own infrastructure, so its license cost is zero too. The difference lies in scope. Atlantis runs plans and applies from pull request comments and locks a directory or workspace until the pull request is merged or the lock is deleted. It does not host state, provide a module registry or offer a workspace UI, so you run your own state backend, which can be any type except local state. If pull requests are your only workflow, the footprint may be smaller, but you will build the parts that Terrakube provides. Compare the components you would keep before deciding.
Does choosing OpenTofu change the cost comparison?
Both Terrakube and Atlantis document running OpenTofu as well as Terraform, so the run platform choice and the CLI choice are separate decisions. OpenTofu is an MPL-2.0 fork under the Linux Foundation and was accepted into the CNCF Sandbox on April 23, 2025, which removes Business Source License terms from the CLI. Its client-side encryption of state and plan files works with key providers such as AWS KMS, GCP KMS and OpenBao. That encryption adds key management work to your operations budget, so include it in the scope and the quote.
How DeployOpen scopes a fixed-price Terrakube implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Scalr to Terrakube, the work starts with a written scope that sets out which workspaces, pipelines and controls are in and out before any build begins.
How we scope
- Inventory Scalr environments, workspaces, run triggers, variables and VCS links to define what the written scope covers.
- Confirm which Terraform or OpenTofu versions each workspace uses and where state is stored today.
- Agree in writing which policy, cost estimation and identity requirements Terrakube must meet, and what stays out of scope.
How we build
- Deploy Terrakube with its documented Helm chart or Docker Compose option in your cloud account, data center or air-gapped network.
- Connect Terrakube to your identity provider, group permissions and version control systems, then test access by role.
- Port OPA policy checks and extensions, and test runs in a non-production workspace before any cutover.
How we hand over
- Deliver runbooks for backend configuration, state migration through the remote backend and rollback steps for each workspace.
- Document the executor setup that replaces Scalr agents, along with the access model and the change records your reviewers need.
- Run a handover session with your platform and security teams and confirm the agreed deliverables against the written scope.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, which you can ask us to quote alongside the initial scope.
- Ask for a quote that separates the one-time implementation from any recurring retainer so you can compare it with per-run billing.
