Scalr vs Terrakube: which fits your team
Scalr fits teams that want the vendor to operate the platform and can accept per-run billing. Terrakube fits teams that have platform engineers to run it and need state, runs and the module registry inside their own boundary. Most renewals and per-run cost reviews turn on that split, and a data residency requirement usually settles it in favor of self-hosting. The decision rests on three things: how much operating capacity you can staff, how strictly state and run data must stay in your accounts, and how many runs your teams trigger each month, since per-run billing grows with volume.
Scalr fits when a small platform group would rather buy operations than build them, when the cost of run volume is acceptable, and when the features your teams depend on are confirmed in Scalr's current documentation. Terrakube fits when you already run Kubernetes or similar clusters, can own upgrades, backups and database operations, and want the remote backend, the cloud block, VCS integration and the private registry under your own identity provider. Terrakube's ownership cost is staff time and infrastructure rather than a per-run invoice, so it is worth modeling against your real run counts before deciding.
Before you commit either way, check Scalr's specific features against its current documentation rather than relying on comparisons, including its environment model, agent options, OPA policy handling and identity integrations. Then confirm Terrakube's fit in a proof of concept with one non-production workspace, measuring who will be on call for it and what it takes to restore state. The Terrakube documentation is the natural starting point for that test.
Which option fits which scenario
This table matches common team situations to the option that usually suits them better, Scalr or self-hosted Terrakube. Each row names the condition under which the fit holds, so you can check it against your own environment. Read it as a starting point for your own requirements, not a verdict on either product.
| Scenario | Better fit | Why |
|---|---|---|
| Small team with low run volume | Depends on run count | If your dry runs and applies stay low and you have no one to operate a platform, a managed service may cost less in staff time. Ask Scalr for its current per-run terms and compare them with your expected monthly run count. |
| Regulated team that must keep state in its own cloud account | Self-hosted Terrakube | The fit holds when state, logs and run data must stay in an account you control. Terrakube runs in your infrastructure, and you choose where its database and storage sit. Confirm the storage and database placement with your assessor. |
| Platform team already running Kubernetes | Self-hosted Terrakube | Terrakube documents installation with a Helm chart, so it fits an existing cluster and GitOps practice. The fit holds if your team can own upgrades, backups and the Dex and database dependencies. |
| Team that wants vendor support for upgrades | Scalr | If contractual support, a named escalation path and managed upgrades are required, a commercial vendor is the more direct route. The fit holds if you cannot staff platform operations internally. A partner such as DeployOpen can also support a self-hosted deployment on a retainer. |
| Team using Atlantis for pull request plans only | Atlantis (self-hosted) | If the main need is plans and applies from pull requests, Atlantis is a narrower, lighter tool. The fit holds when you do not need a state backend, a module registry or a workspace UI, which Terrakube provides. |
| Many workspaces across several VCS providers | Self-hosted Terrakube | Terrakube integrates with GitHub, GitLab, Bitbucket and Azure DevOps and assigns permissions by group. The fit holds when your team can manage group mappings and connection credentials for each provider. Confirm that your specific VCS edition is supported. |
Capabilities side by side: what each platform documents
This table compares the capabilities each platform documents for Scalr and self-hosted Terrakube. Terrakube cells come from its published documentation, while Scalr cells list what to confirm with Scalr directly, since its feature details were not verified here. Use the table as a checklist for your own evaluation, not as a verdict on either product.
| Capability | Scalr (confirm with Scalr) | Terrakube (documented) |
|---|---|---|
| Environments and workspaces | Confirm how Scalr models environments, whether workspaces sit under them, and how access is scoped at each level | Workspaces are the unit of runs, variables and state, with permissions assigned per workspace by group |
| Remote backend compatibility | Confirm which Terraform and OpenTofu versions Scalr supports as a remote backend and how state is migrated in | Supports the remote backend, which also supports migrating state, for CLI-driven runs |
| Cloud block | Confirm whether Scalr supports the Terraform cloud block and the minimum CLI version it requires | Supports the cloud block; it needs Terraform v1.1 or later, and earlier versions can use the remote backend |
| Agents or executors | Confirm how Scalr agents are deployed, where they run, and what they need from your network | Runs work through executors; confirm sizing and placement against your own network design |
| OPA policy checks | Confirm whether policy enforcement uses OPA and how policies are attached to workspaces | Available through extensions that add OPA policy checks to runs |
| Private registry | Confirm whether Scalr provides a private registry for modules and providers and how access is controlled | Provides a private registry for Terraform modules and providers |
| Identity and group permissions | Confirm supported identity providers, SSO protocols and whether permissions can be granted by group | Uses Dex for identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML; permissions assigned by group |
| VCS integrations | Confirm which Git providers and self-managed editions Scalr connects to | GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps |
| Database support | Confirm where Scalr stores its own data and whether a self-managed database option exists | Any relational database Liquibase supports, such as PostgreSQL, MySQL, Oracle and SQL Server |
| Installation methods | Confirm whether Scalr can run in your own infrastructure and which deployment models it offers | Helm chart or Docker Compose; testing documented with minikube |
| License | Confirm the license and terms that apply to the self-managed option, if one is offered | Apache 2.0; OpenTofu is MPL-2.0 and documented as supported |
Where state, plans and credentials live under each model
Scalr and self-hosted Terrakube differ mainly in who operates the systems that hold state, plan files and credentials. The four cards below separate where data sits, how it is encrypted, who controls access and what evidence you must produce. Each one names the condition under which the difference starts to matter for your team.
Where the data sits
With Scalr, state, plans and run logs are held by the vendor's hosted service, so your residency position depends on where that service stores them and on the terms you sign. With Terrakube, the API, database and executors run in your own cloud account, data center or air-gapped network, and you decide the storage location. This matters most when a data residency rule names specific regions or forbids external hosting of infrastructure metadata. Ask Scalr in writing which regions and subprocessors hold your workspace data.
State and plan encryption
OpenTofu encrypts state and plan files at rest, for local storage and remote backends, using key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault. The feature was introduced in v1.7, and it applies whichever platform runs the CLI, so it is a property of the tool rather than of the platform. Your key ownership, rotation and loss procedures still belong to you. Confirm which key provider your team will use before any state migration starts, because losing the key means losing the state.
Identity and access controls
Terrakube authenticates users through Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and grants permissions on workspaces, modules and VCS connections by group. That gives you directory-driven access with your own identity provider. Scalr's SSO and role model must be checked directly with the vendor, including how groups map to environments and whether audit logs can be exported. Map your current roles to each platform before cutover so that no team gains rights during migration.
Compliance evidence
Under either model, the platform and the cloud account generate the logs and configuration records that an assessor will ask for, but the assessor, not the vendor or DeployOpen, issues any report or attestation. DeployOpen prepares the controls, configurations and evidence collection for a self-hosted Terrakube deployment and can document them for your assessor. With Scalr, you depend on the vendor's own attestations and the evidence they expose to customers. Ask which evidence each platform can export, how long it is retained and who holds the logs.
Who runs what on each side
The platform team carries most of the operating work when you run Terrakube. Terrakube installs with a Helm chart or Docker Compose, so the team owns the cluster or host, ingress, and the relational database behind it. Terrakube supports any engine that Liquibase supports, such as PostgreSQL, MySQL, Oracle and SQL Server, and that database holds run and workspace metadata, so it needs its own backup and restore plan alongside the state backups. The team also sizes executor capacity for peak run concurrency, plans upgrades across Terrakube releases, and tests each upgrade in a non-production copy before rolling it out. Each of these is recurring work, and each needs a named owner before cutover.
The security team sets the control boundary. Terrakube authenticates through Dex with identity providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML, and it assigns permissions on workspaces, modules and VCS connections by group, so access reviews should map to group membership in your identity provider. OPA policy checks run as a Terrakube extension, and the security team should own the policy repository and its change approval. State is the sensitive asset: confirm where state is stored, who can read it, and whether OpenTofu state encryption with a KMS key provider will apply to each workspace. Make these decisions in writing before any workspace moves.
Scalr's managed model moves much of this operation to the vendor, but the boundary has to be confirmed in its service terms rather than assumed. Ask which parts of upgrades, database operations, backups and restore testing Scalr runs, which parts stay with your team, and where state and run logs are hosted. Developers are the group least affected by either choice. The CLI-driven workflow with terraform login against the Terrakube API hostname keeps their day-to-day commands close to what they already use, and the cloud block needs Terraform v1.1 or later, while earlier versions can use the remote backend. Terrakube's CLI-driven workflow documentation lists the details to check against your current Terraform versions.
How a move from Scalr to Terrakube runs, at a high level
The sequence moves each workspace's state, environments, variables, VCS links and policies from Scalr into Terrakube in a controlled order, with a test change confirming each workspace before its old backend is retired.
Inventory workspaces, environments and policies
Platform or DevOps engineers list every Scalr workspace, the environment each belongs to, its variables and secrets, its VCS connection and branch, and every OPA policy attached to it. Record which workspaces read other workspaces' outputs through the terraform_remote_state data source, because those need extra care later. The inventory is done when every workspace has one row with its state location, dependencies and owner, and the list is reviewed by the teams that own the code.
Stand up Terrakube in a test environment
The platform team installs Terrakube in a non-production environment using the Helm chart or Docker Compose options documented in its README, connects it to a relational database that Liquibase supports, and configures identity through Dex with the groups your organization already uses. Confirm the test instance is reachable at its API hostname and that a sample workspace can run a plan. Installation details and the database choice should be confirmed against the Terrakube documentation for your version.
Pull state for each workspace through the backend
For each Scalr workspace, the team downloads the current state from the source backend and keeps a dated copy in secure storage before any change. Terrakube's remote backend supports migrating state, so the state is then pushed into the matching Terrakube workspace. The check is that a plan run in Terrakube against unchanged code reports no changes, which shows the state moved intact. Keep the original backend untouched until the step is confirmed.
Recreate environments, variables and VCS connections
Terrakube workspaces, variables and VCS links are recreated by the platform team, using the inventory as the checklist. Secrets are re-entered from the secrets manager rather than copied from Scalr exports, and VCS connections are attached to GitHub, GitLab, Bitbucket or Azure DevOps repositories with access granted by group. Done means each workspace's variables match the inventory and a manual run pulls the expected branch.
Port OPA policies and replace agents with executors
Each OPA policy is reviewed, tested against sample plan output, and attached to the matching Terrakube workspace through its policy checks extension, which is documented in the Terrakube README. Scalr agent pools are replaced by Terrakube executors sized for your largest runs. Confirm each policy produces the same allow and deny decisions on a set of known plans before any workspace relies on it. Policy language and extension behavior should be verified against current Terrakube and OPA documentation.
Switch each workspace's backend configuration
The engineers who own each configuration change its backend block or cloud block to point at the Terrakube workspace and run terraform login against the Terrakube API hostname. They run an init with state migration so the state is accepted by Terrakube. The step is complete when the configuration initializes cleanly, the state reads correctly, and the old Scalr backend is marked read-only for that workspace. Workspaces that share outputs through terraform_remote_state should be switched in dependency order, with the producing workspace moved first.
Test with a small change and keep the rollback path
Each migrated workspace receives a small, low-risk change, such as a tag on a non-critical resource, which runs through plan and apply in Terrakube and is checked against the expected result. OpenTofu's migration guidance describes the overall process as designed to be safe and reversible, so keep the original state copy and Scalr configuration until the team signs off. Retire Scalr only after every workspace has passed its test. For the detailed steps, follow the separate migration page for Scalr to Terrakube.
Questions buyers ask before switching from Scalr
How much effort does moving off Scalr take?
The effort depends mainly on how many workspaces, environments and integrations Scalr holds for your teams, and on how much of your configuration lives in Scalr-specific features. Each workspace needs its backend block switched to the Terrakube remote backend or cloud block, its variables and environments recreated, its VCS connection rebuilt, and its policies reviewed. Teams with a small number of workspaces, plain variables and standard VCS links usually have the simplest move. Teams with many shared variable sets, custom policy logic or pipelines that call Scalr's API will need more time for inventory and testing. Ask for a workspace inventory before you request any quote.
Can we migrate from Scalr without outside help?
Yes, a team with experienced Terraform or OpenTofu engineers can do the migration in-house, because the core steps are documented: back up code and state, install OpenTofu, initialize and verify each configuration, and test with a small change. The work that most often slows internal teams is the inventory of Scalr-specific features and the parallel running period. Outside help is useful when you need a fixed scope with written deliverables, or when your staff are committed to other work. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under fixed-scope engagements, so you can compare an in-house plan against a written quote.
What does the work need from our platform and security teams?
Platform engineers need to provision the Terrakube deployment, which is documented for installation with a Helm chart or Docker Compose, and connect it to a relational database that Liquibase supports, such as PostgreSQL. Security teams need to review identity, since Terrakube uses Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and assigns permissions on workspaces, modules and VCS connections by group. They also need to decide where credentials for cloud accounts live and how Terrakube executors reach those accounts from your network. Confirm each of these details against the current Terrakube documentation for your chosen version.
How long will the transition from Scalr take?
This page does not give a duration, because the time depends on the scope you agree. The main factors are the number of workspaces, the number of environments that must run in parallel during cutover, the complexity of your OPA policies, and how many external systems call Scalr. A fixed scope sets the timeline in writing before work starts, so ask for a scope that lists the workspace inventory, the cutover order, the test plan and the rollback steps. Confirm with your own team which change freezes and approval windows apply to your production workspaces.
Does Terrakube work with both OpenTofu and Terraform?
Yes, Terrakube runs remote infrastructure as code operations with either Terraform or OpenTofu, and it supports both the remote backend and the cloud block. The cloud block needs Terraform v1.1 or later, while earlier versions can use the remote backend, which also supports migrating state. Users authenticate with terraform login against the Terrakube API hostname. 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, so test each upgrade of either tool in a staging workspace.
How is state protected during and after the move?
State is protected in two layers: the storage behind Terrakube and the encryption that OpenTofu applies to state and plan files. OpenTofu encrypts state and plan files at rest for local storage and remote backends, with key providers including PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault, a feature the website tags as introduced in v1.7. During migration, pull state from Scalr through the remote backend and verify it before the first apply on Terrakube. Ask your team to confirm the key provider, key rotation process and access controls before any production state moves.
What happens to our Scalr-specific policies?
OPA policy checks are not automatically carried over, so each Scalr policy has to be reviewed, rewritten or re-tested against Terrakube's extensions. Terrakube extensions add tools such as OPA policy checks and Infracost cost estimates to runs, so the policy logic can usually be kept in OPA, but the wiring, input data and enforcement points must be rebuilt. Confirm which policies block runs, which only warn, and who approves exceptions. Run each policy against recent plans in a test workspace before enforcing it in production.
Does the move break terraform_remote_state references?
It can, so treat cross-workspace data sharing as a separate work item. The OpenTofu migration guide warns that configurations sharing data through the terraform_remote_state data source typically need additional care during migration, and it links a separate guide for that case. List every workspace that reads another workspace's outputs, then move the producer and consumer workspaces in the same change window where possible. Confirm the outputs and backend paths in each consumer before cutover.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenTofu with Terrakube. For Scalr versus Terrakube, we start from your workspaces, policies and identity setup, then agree a fixed scope in writing before any work begins.
How we scope
- Inventory of Scalr environments, workspaces, agents, OPA policies and VCS links to be reviewed
- Decision on whether Terrakube executors or the remote backend fit each team's runs
- Written statement of which workspaces move, which stay and what is out of scope
- Identity mapping from your current provider to Dex groups and workspace permissions
How we build
- Terrakube deployed with Helm or Docker Compose in your cloud account or data center
- Database, state storage and encryption configured to your residency and key management rules
- OPA policy checks and any Infracost extension ported and tested against sample plans
- Test workspaces run with OpenTofu, with a small planned change verified before cutover
How we hand over
- Runbooks for workspace creation, variable changes, state recovery and executor maintenance
- Backup and restore procedure documented and exercised against your own environment
- Evidence pack describing controls, access settings and run logs for your assessors to review
- Handover session with platform, security and compliance owners before the Scalr contract ends
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Upgrade plan for Terrakube and OpenTofu releases, tested in a staging workspace first
- Periodic security testing of the Terrakube deployment and its API, if you request it
- Quote follows directly from the written scope, so the retainer size reflects agreed work
