Backstage vs. Cycloid: 2026 IDP Comparison
As platform teams scale, day-to-day issues start surfacing in places engineers actually touch: a Terraform change applies without review, a short-lived cluster keeps running after a sprint, or a service owner isn’t clear when something breaks. The first is operational: a Terraform change applies to production before anyone reviews the plan, a proof-of-concept cluster keeps running because no team owns its teardown, or an environment drifts from its declared state and no one notices until something breaks. The second is organizational: a developer cannot quickly identify who owns the payments service, and onboarding a new engineer turns into searching Slack threads, old pull requests, and internal docs to piece together context.
Teams start evaluating Cycloid vs Backstage when their Internal Developer Platform either stops at service catalog visibility or fails to control how infrastructure changes are executed, leading to gaps in enforcement, ownership, or auditability. They address different problems, at different layers, with different assumptions about where enforcement needs to happen.
The core trade-off
Backstage vs. Cycloid
Backstage is an open-source developer portal framework, originally built by Spotify and now a CNCF project. It centralizes service ownership, technical documentation, and golden-path templates in one interface. Teams use it to reduce the friction of finding what exists, who owns it, and how to build new things consistently. Backstage doesn’t run infrastructure; it describes it.
Cycloid is an internal developer platform that treats infrastructure delivery as something the platform itself must own and govern. Terraform plans, approvals, policy checks, and cost estimates all run through a controlled path before anything touches the cloud. Developers request changes through forms backed by Git-versioned stacks, and the platform enforces scope and permissions at each step.
Both address distinct platform concerns; one structures service ownership and reduces the effort required to locate systems and context. The other governs how infrastructure actually changes. By the end of this breakdown, you’ll be able to tell which gap is the one costing your organization the most.
FLEXIBILITY vs. TIME-TO-VALUE
Decision matrix: Backstage vs. Cycloid
Comparing Backstage and Cycloid comes down to one core trade-off: flexibility vs. time-to-value. Backstage is open-source and highly customisable – but typically requires 2–4 dedicated platform engineers to install, maintain, and extend. Cycloid is deployable in under 2 hours, with multi-cloud governance and FinOps built in. This page gives you the side-by-side data to decide which fits your team.
1. Where Terraform Execution Runs and Where Credentials Live
The deployment model matters because it determines where credentials, state files, and audit logs live. For teams subject to data residency requirements or operating in air-gapped environments, this isn’t an aesthetic preference; it’s a compliance requirement.
Cycloid supports SaaS, dedicated managed instances, and fully self-hosted deployments, including environments without outbound internet access. Cycloid orchestrates Terraform execution through its pipeline engine, where plans and applies run in controlled execution environments with access to centrally managed credentials. The platform is designed with this requirement in mind, not added as an afterthought.
Backstage is typically self-hosted, and while Spotify does not offer an official managed Backstage SaaS, commercial managed offerings and distributions are available from vendors such as Spotify and Red Hat partners. Teams build and deploy their own instance, typically on Kubernetes, with a PostgreSQL database and a custom Docker image that bundles the plugins their organization uses.Backstage provides tooling to build a Docker image for your instance, but teams are expected to assemble and build that image themselves, including any required plugins and configuration, before deployment. Red Hat offers a supported enterprise distribution (Developer Hub) for organizations that want a commercially maintained build on OpenShift, but upstream Backstage itself requires teams to own the build pipeline, dependency updates, and plugin compatibility across upgrades. That’s a non-trivial operational commitment at scale.
Out of the box, Backstage does not handle infrastructure credentials or Terraform state, so its security footprint is narrower; extending it to manage or interact with those layers typically requires additional plugins or custom integration work. It connects to source control, CI systems, and observability tools, but it doesn’t execute privileged infrastructure operations. Cycloid’s broader execution responsibilities come with stronger data isolation requirements and a corresponding set of deployment controls to match.
FEATURE
CYCLOID
BACKSTAGE
Deployment model
SaaS, dedicated managed, or fully self-hosted including air-gapped
Self-hosted only; teams build and operate their own instance
Data residency control
Infra state, execution logs, and credentials can be kept inside customer-controlled networks
No managed offering; teams control data by operating the platform themselves
Platform runtime ownership
Cycloid operates the SaaS tier; dedicated instances can be customer-operated or managed by Cycloid
Teams own the full runtime: image builds, plugin updates, database, and upgrades
Infra credentials handling
Cloud credentials stored and used within the platform’s runtime during plan and apply
No credential storage; infra access happens in external CI systems
Regulated environment fit
Suitable where infra execution and approvals must stay inside private or isolated networks
Suitable where the team can absorb the engineering overhead of operating the portal itself
2. Who Owns Terraform Plan and Apply Execution
Backstage’s Scaffolder can trigger external workflows, including ones that run Terraform. A template can create a repository, push configuration files, and start a GitHub Actions workflow that runs terraform apply. That’s not the same as owning execution. The governance guarantees of that apply depend entirely on how the external CI pipeline is configured, what branch protections are in place, and whether anyone has wired in a policy check. Backstage initiates workflows but does not participate in their execution. Once a pipeline is triggered, enforcement depends entirely on external systems, such as CI configuration, IAM permissions, and repository controls, none of which Backstage governs.
Cycloid owns the execution path; terraform and Ansible runs happen within the platform’s pipeline engine, backed by Git-versioned stacks that the platform team controls. Developers submit requests through StackForms, which restrict inputs to predefined variables, instance types, and policy-validated parameters. The platform evaluates InfraPolicies before execution, performs drift detection by comparing Terraform state and planned changes against live infrastructure during policy evaluation, and tracks state centrally across environments. An environment can’t be abandoned without the platform knowing about it, because the platform manages the lifecycle.
If issues trace back to forgotten clusters, plan bypasses, or production changes that didn’t go through the expected path, Cycloid addresses those failure modes at the source. Backstage, by design, does not.
FEATURE
CYCLOID
BACKSTAGE
Infrastructure-as-Code execution
Runs Terraform and Ansible plans and applies as part of the platform workflow
Does not execute IaC; Scaffolder can trigger external pipelines that do
Terraform state awareness
Tracks Terraform state centrally across environments and workspaces
No state management; links to repositories or external tools
Drift detection
Compares declared configuration against live infrastructure per environment via InfraPolicy
No built-in drift detection; available only through third-party plugins (e.g., Firefly)
Environment lifecycle control
Creates, updates, and decommissions environments through governed workflows
Environment lifecycle is managed in external CI pipelines or IaC tools
Infrastructure visualization
Shows live infrastructure topology and resources tied to each environment via InfraView
Displays service metadata, repository links, and CI status without infrastructure topology
3. How Environment Changes Are Requested and Applied
Backstage’s self-service model centers on standardized templates for creating services and components. The Scaffolder lets platform teams publish templates that developers run to create new services, repositories, or components in the correct shape from day one. A developer picks a template, fills in a form, and gets a repository with the CI pipeline, monitoring hooks, and ownership metadata already wired. That standardization at creation time is valuable; it reduces the number of services that drift from organizational norms before they’re a week old.
What Backstage doesn’t do is govern day-2 operations on existing infrastructure. Updating an environment, resizing a cluster, or decommissioning a resource all happen outside Backstage, in external pipelines where Backstage’s permission model doesn’t apply. The permission framework does let platform teams restrict who can trigger which Scaffolder templates, but those controls cover template execution, not the infrastructure changes those templates initiate downstream.
Cycloid’s self-service model covers both initial provisioning and ongoing changes. Developers request environments or modifications through StackForms, which expose only the variables the platform team has chosen to expose for each stack. Approval workflows run before execution, not alongside it. Every action, whether it’s creating a new environment or changing a database instance size, follows the same governed path with the same audit trail.
FEATURE
CYCLOID
BACKSTAGE
What a developer can do in the platform
Submit requests to create or modify environments using approved Terraform stacks
Run Scaffolder templates to create new components; browse and update service catalog entries
How environment creation happens
Platform generates Git-backed stack configuration and runs controlled Terraform execution
Scaffolder triggers external pipelines; actual provisioning happens outside Backstage
Guardrails on inputs
Input fields restricted to predefined variables, instance types, and policy-validated parameters
Template inputs can be validated within a template, but there’s no enforcement on external pipeline parameters
Approval flow
Built-in approval steps before Terraform plan and apply
No native infra approval flow; approvals handled in source control or external CI
What happens if policy fails
Change is blocked before apply
Policy enforcement must exist in the external CI or IaC tooling
4. Where Policy Checks and Approvals Are Enforced
Governance fails when it relies on convention rather than enforcement. If your protected-branch rule is the primary control preventing unreviewed Terraform changes, then anyone who can override that rule, or who works in a repository without it, is outside the governance model. That’s not a hypothetical; it’s a gap that widens as teams, repositories, and pipelines multiply.
Cycloid enforces RBAC at the stack and environment level. Roles control who can request, approve, plan, or apply infrastructure changes, and those roles are checked by the platform before execution begins. InfraPolicy evaluations run before terraform plan and can block changes based on resource type, target environment, or declared inputs. Audit logs capture the full chain: who requested the change, who approved it, which policy checks ran, and what infrastructure was modified. That audit chain lives in Cycloid, not distributed across three systems that each need to be queried separately.
Backstage’s permission framework, introduced progressively since 2022, lets platform teams control who can trigger Scaffolder templates, view catalog entities, or perform scaffolder task operations. It’s a meaningful set of controls for the portal itself. It does not extend to the infrastructure pipelines that Backstage triggers. A GitHub Actions workflow that runs terraform with elevated IAM permissions runs with whatever access the workflow has, regardless of what the Backstage permission framework says. The governance boundary ends where Backstage’s execution scope ends.
Compliance teams asking “can we prove this infrastructure change was reviewed and approved before it was applied?” get a complete answer from Cycloid’s audit log. From Backstage, that question requires aggregating data from the repository, the CI system, and whatever approval mechanism was configured there.
FEATURE
CYCLOID
BACKSTAGE
Role-based access control
Enforced at stack and environment level, controlling who can request, approve, plan, or apply
Controls access to catalog metadata and Scaffolder templates; inherits from Git provider and CI for infra
Policy enforcement
InfraPolicy (policy-as-code) runs before Terraform plan and apply, blocking non-compliant changes
No policy evaluation on external deployments; Backstage doesn’t intercept CI or IaC execution
Approval workflows
Native approval steps in the delivery workflow, required before plans or applies proceed
Approvals occur in external systems; Backstage links to them but doesn’t enforce them
Audit logging
Centralized logs capture requests, approvals, policy results, and infrastructure changes in one place
Audit data split across Git commits, CI logs, and Jira; Backstage surfaces references but doesn’t consolidate them
Compliance posture
Prevents non-compliant changes by enforcing controls in the delivery path
Documents compliance status through scorecards and ownership metadata without blocking execution
5. When Cost Impact Is Calculated and Can Block Changes
An infrastructure change that doubles the cloud bill lands the same way whether it went through code review or not. Review processes catch logic errors. They don’t catch cost surprises unless someone runs infracost locally, reads the output, and decides to do something about it, which is three voluntary steps that break under deadline pressure.
Cycloid integrates cost estimation directly into the delivery path via its open-source TerraCost engine. Before a StackForms-triggered change executes, the platform calculates the estimated cost delta from the Terraform plan. Platform teams can configure budget thresholds that block applies automatically; a change that would exceed an approved threshold doesn’t proceed without explicit escalation. Live cost data aggregates across projects, environments, and cloud providers in a single view. The platform also tracks carbon footprint associated with deployed infrastructure, giving sustainability metrics the same visibility as financial ones.
Backstage can surface cost information through plugins. The Infracost plugin, for example, displays cost estimates for catalog entities. But no Backstage plugin gates infrastructure execution based on cost. The plugin shows the data; what happens to that data, and whether it changes anyone’s behavior before a deployment runs, is not something Backstage controls. Cost visibility in Backstage is informational. Cost control in Cycloid is structural.
This setup becomes operationally heavy, since cost visibility depends on third-party tools such as Kubecost, which introduces additional dependencies and a degree of vendor lock-in.
FEATURE
CYCLOID
BACKSTAGE
Pre-deploy cost estimation
TerraCost calculates estimated cloud cost from the Terraform plan before apply
Infracost plugin can display cost data, but doesn’t gate deployments
Budget enforcement
Budget thresholds enforced through policy checks; changes that exceed limits are blocked
No mechanism to block deployments based on cost
Live cost visibility
Multi-cloud spend aggregated by environment, project, and provider in a single view
Cost data available only through external integrations surfaced in the portal
Sustainability signals
Carbon footprint tracked per deployed environment
No native sustainability tracking
Cost control timing
Cost evaluated before resources are created or modified
Cost visible only after resources exist
How to Decide
Enterprise platform teams rarely deal with a single isolated issue; problems show up across execution, ownership, and cost, while the team responsible for fixing them stays small. The choice between Cycloid and Backstage depends on where the breakdown happens inside your Internal Developer Platform.
Cycloid fits teams where the failure shows up during infrastructure execution: Terraform plans run outside a controlled path, environments remain active without lifecycle tracking, and policy requirements exist but are not enforced at runtime. Cycloid routes all changes through its pipeline engine using Git-backed stacks, with StackForms controlling input, InfraPolicy evaluating changes before execution, and centralized state tracking across environments. Cost estimation and approval steps are part of that same flow, so changes are evaluated before they reach apply. In these conditions, knowing what exists is not enough; control over how changes execute is what prevents drift and untracked environments.
Backstage fits teams where the breakdown is in service ownership and discoverability: developers spend time identifying owners, onboarding depends on scattered documentation, and standards vary because there is no consistent entry point. Backstage addresses this through its Software Catalog and Scaffolder, which structure service metadata and provide templates for creating new components. It improves how teams discover and start work, but it does not participate in how infrastructure changes are executed after a workflow is triggered.
The two tools can co-exist, and for large organizations they often do. The honest version of the trade-off is this: if your incidents have root causes in the execution path, a developer portal won’t prevent them. If your slowdowns have root causes in coordination and discoverability, an infrastructure control plane won’t fix them.
Frequently Asked Questions
What is the difference between Backstage and Cycloid?
Backstage is an open-source developer portal framework by Spotify that gives teams full control over customisation but requires 2–4 dedicated platform engineers to build, maintain, and extend. Cycloid is a commercial internal developer platform deployable in under 2 hours, with native multi-cloud governance, built-in FinOps modules, and no dedicated ops team required. The core trade-off is customisation ceiling (Backstage) vs. time-to-value and lower operational overhead (Cycloid).
Is Backstage free? What are the hidden costs?
Backstage is free to download under the Apache 2.0 licence. The hidden costs sit in people: a minimum of 2-4 dedicated platform engineers to install, maintain, and extend the portal. At an average fully-loaded cost of €120k/year per engineer, that translates to €240k-480k/year in staffing alone. Teams also report spending 30-40% of platform engineering time on plugin maintenance rather than feature development.
How long does it take to set up Backstage?
A production-ready Backstage deployment typically takes 6–12 months. The initial install is fast, but configuring plugins, building custom integrations, setting up authentication, and connecting internal systems adds significant lead time. Cycloid, by contrast, is deployable in under 2 hours with pre-built modules for CI/CD, governance, and FinOps – reducing the path to first value from months to days.
What is a good alternative to Backstage for small platform teams?
For platform teams without 2-4 spare engineers to dedicate to portal development, a commercial IDP like Cycloid is a practical alternative. Cycloid provides a self-service portal, service catalog (Stacks and StackForms), multi-cloud governance, and FinOps out of the box – without requiring a dedicated portal team. It fits teams that need to deliver platform engineering value quickly without taking on the maintenance overhead of a DIY build.
Backstage vs. Cycloid: which IDP has lower TCO?
Cycloid typically has a lower total cost of ownership for teams that do not already have a dedicated platform engineering squad maintaining Backstage. Backstage’s licence is free, but 2-4 FTE engineers at €120k/year each means €240k-480k/year in people cost before the portal reaches production. Cycloid’s commercial licence includes support, built-in FinOps, and multi-cloud governance – removing the hidden staffing and maintenance burden.
Want to see how Cycloid compares to Backstage for your team?
See Cycloid’s self-service portal, FinOps modules, and multi-cloud governance in action. Or keep exploring the internal developer platform, and learn how Cycloid delivers platform engineering value without the DIY overhead.
If the information above is inaccurate or outdated, please contact us at marketing@cycloid.io and we will set it right straight away.