/
Backstage vs. Cycloid: 2026 IDP Comparison
As platform teams scale, day-to-day issues surface in places engineers actually touch: a Terraform change applies without review, a short-lived cluster keeps running after a sprint, or nobody knows who owns a service when it breaks.
vs
Written by
The Cycloid team
Platform engineering
Updated
October 2026
Read time
11 min read
Backstage vs. Cycloid
Teams compare Backstage and Cycloid when their portal shows the estate but can’t change it, or when they’ve spent a year building one and still maintain the glue behind it.
Backstage gives you a framework for a portal. Cycloid gives you the portal and the platform behind it as one product: a software catalogue with ownership and scorecards, plus the Blueprints, Forms and runners that act on it.
The core trade-off
Backstage
Backstage is an open-source developer portal framework, originally built by Spotify and now a CNCF project. It gives you a Software Catalog, TechDocs and Scaffolder templates to build on. Backstage doesn’t run infrastructure; it describes it, and everything beyond the core is plugins your team assembles and maintains.
The single platform
Cycloid is an internal developer portal and platform in one. The catalogue, ownership and scorecards sit on the same record as the Blueprints that create and change resources, so the page that shows a service is the page you act from. Forms validate input, four-layer authorisation checks every action, and runs go through the Native Runner or the CI you already have.
FLEXIBILITY vs. TIME-TO-VALUE
Decision matrix
Decision matrix: Backstage vs. Cycloid
Comparing Backstage and Cycloid comes down to one trade-off: flexibility vs. time-to-value. Backstage is open source and highly customisable, but someone has to build and run it: at least two platform engineers is a typical starting point, at a European average of $118,028 each (State of Platform Engineering, 2024). Cycloid is a product your platform team configures, live in weeks: cloudXcelerate went from cloud migration to full production in under four weeks.
01
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 runs as SaaS, a dedicated managed instance, or fully self-hosted, including air-gapped environments. Runs go through the Native Runner, under your control, or through GitHub Actions, GitLab CI or any other CI via a webhook, with credentials managed centrally in the platform.
Most teams self-host Backstage: they build and deploy their own instance, typically on Kubernetes, with a PostgreSQL database and a custom Docker image that bundles the plugins they use. Managed and supported options exist: Spotify Portal for Backstage and Roadie as SaaS, and Red Hat Developer Hub as a supported distribution on OpenShift.
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
BACKSTAGE
Deployment model
SaaS, dedicated managed, or fully self-hosted including air-gapped
Mostly self-hosted; managed options from Spotify Portal and Roadie, supported distribution from Red Hat
Data residency control
State, run logs and credentials can stay inside customer-controlled networks
Teams control data by operating the platform themselves, or accept a vendor’s hosting
Platform runtime ownership
Cycloid operates SaaS and managed dedicated instances; self-hosted instances run on your infrastructure and upgrade with each release
Teams own the full runtime: image builds, plugin updates, database, and upgrades
Infra credentials handling
Cloud credentials stored and scoped in the platform, used at run time
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
02
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. Blueprints run Terraform and OpenTofu, Ansible, Helm, scripts and API calls on the Native Runner, or hand the run to your CI and show its status in the portal. Developers request through Forms, which only accept the values the platform team allows, and every action passes four-layer authorisation before it runs.
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
BACKSTAGE
Infrastructure-as-Code execution
Runs Terraform and OpenTofu, Ansible and Helm on the Native Runner, or triggers your CI
Does not execute IaC; Scaffolder can trigger external pipelines that do
Terraform state awareness
Reads Terraform and OpenTofu state to inventory what’s managed and show IaC coverage
No state management; links to repositories or external tools
Environment lifecycle control
Creates, updates and decommissions environments through Blueprint actions, with Day-2 actions on the same record
Environment lifecycle is managed in external CI pipelines or IaC tools
Infrastructure visualisation
Relationship graph of resources and services per environment, built from inventory, IaC and declared relationships
Displays service metadata, repository links, and CI status without infrastructure topology
03
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 covers the first deploy and everything after it. Developers request or change environments through Forms that expose only the fields the platform team chose, then promote them and run Day-2 actions from the resource page. Approvals run before anything executes where a request needs sign-off.
FEATURE
BACKSTAGE
What a developer can do in the platform
Create or change environments from approved Blueprints, promote them and run Day-2 actions
Run Scaffolder templates to create new components; browse and update service catalog entries
How environment creation happens
The platform runs the Blueprint’s create action, on the Native Runner or your CI, and records the result
Scaffolder triggers external pipelines; actual provisioning happens outside Backstage
Guardrails on inputs
Form fields limited to approved values and validated before submission
Template inputs can be validated within a template, but there’s no enforcement on external pipeline parameters
Approval flow
Approval steps before the run, routed to the right approver (Enterprise)
No native infra approval flow; approvals handled in source control or external CI
What happens if policy fails
The request is refused before anything is created
Policy enforcement must exist in the external CI or IaC tooling
04
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 checks every action through four layers: what you can see, your role, conditions on the request, and approval where it’s needed. Roles are predefined (Admin, Lead, Member, Viewer), and a Tenant Admin can delegate specific permissions. The audit log records who asked, who approved, what ran and what was refused, whether a person or an assistant acted.
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
BACKSTAGE
Role-based access control
Predefined roles scoped to teams and Resource Groups, controlling who can request, approve or run
Controls access to catalog metadata and Scaffolder templates; inherits from Git provider and CI for infra
Policy enforcement
Form validation and conditions run before the run and refuse non-compliant requests
No policy evaluation on external deployments; Backstage doesn’t intercept CI or IaC execution
Approval workflows
Native approval steps required before the run proceeds
Approvals occur in external systems; Backstage links to them but doesn’t enforce them
Audit logging
One log of requests, approvals, refusals and changes, for people and assistants
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
05
Where Ownership, Docs and Standards Live
This is where Backstage is strongest, and where Cycloid meets it head on.
Backstage’s Software Catalog tracks components, APIs, systems and owners from catalog-info.yaml files. TechDocs renders documentation next to each entity, and scorecards come from plugins such as Spotify’s Soundcheck. All of it needs plugins configured and kept current by your team.
Cycloid’s software catalogue lists every service, API and resource with its owner, its dependencies and its scorecard level, on the same record as the Blueprint that created it. Documentation and API specs (OpenAPI, AsyncAPI, GraphQL) sit on the resource page. Scorecards rank each service against your standards and tell the owner what’s missing, and the owner fixes it with a Day-2 action or a property update.
FEATURE
BACKSTAGE
Software catalogue
Services, APIs, resources and owners, with faceted search, built in
Software Catalog from catalog-info.yaml, extended by plugins
Ownership
Configurable ownership fields on every resource
Owner field per entity
Scorecards
Built-in rule engine with levels, trends and exemptions
Through plugins such as Soundcheck (commercial) or community plugins
Docs and API specs
Documentation, plus OpenAPI, AsyncAPI and GraphQL specs, on the resource page
TechDocs plugin for docs; API docs plugin renders OpenAPI, AsyncAPI and GraphQL
Acting on what you see
Deploy, promote and run Day-2 actions from the same page
Links out to external tools and pipelines
If the information above is inaccurate or outdated, please contact us at marketing@cycloid.io and we will set it right straight away.
Migration
Moving from Backstage
You don’t need to rewrite your descriptors to try Cycloid. Connect your GitHub or GitLab repositories and Cycloid discovers the catalog-info.yaml files Backstage already reads. Each entity is proposed for review before it’s imported, mapped to a Cycloid resource with its owner and relationships, and its Backstage ID is kept as an external ID, so the two can run side by side while you compare. Templates don’t carry over: your platform team rebuilds them as Blueprints.
How to decide
How to Decide
Enterprise platform teams rarely face one isolated problem. Execution, ownership and standards break down together, and the team fixing them stays small.
Backstage fits teams that want to build their own portal and have engineers to keep building it: a framework, a plugin ecosystem and full control over every screen.
Cycloid fits teams that want the portal and the platform as one product: a catalogue with owners and scorecards, and governed paths to act on it, live in weeks instead of after a year of assembly.
The two can run side by side while you compare. The difference shows when a developer finds a problem in the catalogue: in Backstage they follow a link to another tool, in Cycloid they fix it from the same page.
Frequently Asked Questions
Backstage is an open-source portal framework from Spotify: you get a catalogue and a plugin system, and your team builds and maintains the rest. Cycloid is an internal developer portal and platform in one, with the catalogue, ownership, scorecards, Blueprints, Forms and governance as product, live in weeks. The trade-off is customisation ceiling versus time to value and running cost.
Backstage is free under the Apache 2.0 licence. The cost sits in people: building and running it typically takes at least two platform engineers, and the European average salary for one is $118,028 a year (State of Platform Engineering, 2024).
A production-ready Backstage deployment typically takes 6–12 months. The first install is fast, but configuring plugins, authentication and integrations with internal systems adds the time. Cycloid is live in weeks: cloudXcelerate went from cloud migration to full production in under four weeks.
For teams without engineers to dedicate to portal development, a product like Cycloid gives you the software catalogue, Blueprints and Forms for self-service, and governance out of the box.
Cycloid usually costs less to own for teams that don’t already have a squad maintaining Backstage. Backstage’s licence is free, but two engineers at the European average is about $236,000 a year in salary before the portal reaches production. Cycloid starts from €39 per user per month on Advanced.
Yes. Connect your repositories and Cycloid discovers your catalog-info.yaml files, proposes each entity for review, and keeps its Backstage ID as an external ID, so both can run side by side while you switch.
Want to see how Cycloid compares to Backstage for your team?
See Cycloid’s software catalogue, Blueprints and governance in action, side by side with what you run today. Or keep exploring the internal developer platform, and learn how Cycloid delivers platform engineering value without the DIY overhead.