What is Backstage?
Backstage is an open-source developer portal framework created at Spotify and donated to the CNCF. At its centre is a software catalog that records every service, API, library and resource your organization owns and who owns it. Around that sit Scaffolder templates for creating new services from golden paths, TechDocs for documentation-as-code, and a plugin architecture that pulls CI status, cloud cost, incidents and security findings into one place.
The critical thing to understand before committing: Backstage is a framework, not a finished product. There is no install-and-go edition. You assemble your own instance, model your own entities, write your own plugins in React, and own the upgrade path forever. That flexibility is exactly why large engineering organizations choose it — and exactly why implementations stall when teams budget for a deployment and get a product.
SquareOps provides Backstage consulting for teams at both ends of that journey: organizations starting from zero who want the entity model right the first time, and organizations with a stalled instance nobody uses that needs rescuing. We also build Internal Developer Platforms more broadly, including on Kubernetes and GitOps foundations.
Atmosly is a SquareOps product. It is mentioned on this page where it is genuinely a better fit than Backstage, and we have tried to be explicit about where it is not.
Backstage Implementation Services
The six areas where Backstage projects succeed or quietly fail. Each is a service we deliver, and each maps to a failure mode we have seen first-hand.
Service Catalog Modeling
Most failed Backstage rollouts fail here. Teams model entities loosely, ownership goes stale within a quarter, and the catalog becomes a directory nobody trusts.
What We Do
Design the entity model — components, systems, APIs, resources, domains — against how your organization is actually structured. Automate ingestion from Git so catalog-info.yaml stays accurate without manual upkeep.
Plugin Development
The community plugin you need either does not exist, is unmaintained, or breaks on the next Backstage release. Plugins are React and TypeScript — a skill set many platform teams do not have.
What We Do
Build custom plugins for your internal systems, and integrate and harden community ones. We prefer configuration over code wherever possible — every custom plugin is a maintenance liability you carry.
Scaffolder Golden Paths
A catalog alone changes nothing about how software gets built. Without templates, developers keep starting services the way they always have, and standards stay in documentation nobody reads.
What We Do
Build Scaffolder templates that produce a correct service from day one — repository layout, CI pipeline, Helm chart, monitoring, security defaults — so the approved path is also the fastest path.
TechDocs and Discovery
Documentation lives in five places, none of them current. New joiners spend their first fortnight asking colleagues questions that were answered in a wiki page nobody can find.
What We Do
Set up TechDocs so documentation lives beside the code, is reviewed in the same pull request, and is discoverable from the catalog entry it belongs to. Migrate existing content and wire up search.
Upgrades and Ongoing Support
Backstage releases often and plugin APIs shift between versions. Instances fall several releases behind, upgrading becomes a project in itself, and the portal slowly rots.
What We Do
Run the upgrade cycle — compatibility testing, plugin maintenance, catalog hygiene, new templates and developer onboarding — either as a retained engagement or as handover training for your team.
Deployment, SSO and Permissions
Backstage ships as a Node application you host yourself. Many instances end up as a single container with a shared login and no real access boundary — fine for a pilot, a problem the moment it holds production ownership data.
What We Do
Deploy on Kubernetes with high availability, a managed database and proper secret handling. Wire SSO to your identity provider and implement Backstage's permission framework so each team sees what it should.
What Backstage Actually Costs
Backstage is free to licence and expensive to run. Most Backstage consulting pages skip this. Here is the arithmetic so you can budget honestly.
| Cost line | Self-hosted Backstage | Managed Backstage |
|---|---|---|
| Licence | None — Apache 2.0 | Per-developer subscription |
| Initial build | 3–6 months of a platform engineer | Weeks — catalog modeling still yours |
| Ongoing maintenance | 0.5–1 FTE, permanently | Vendor handles upgrades and hosting |
| Frontend skill needed | React and TypeScript, in-house | Only for custom plugins |
| Realistic first year | ~$100K–$200K, almost all staff cost | Subscription plus part-time ownership |
These are estimates, not quotes, and they are built from staff time rather than sourced from a vendor. The arithmetic is simply 3–6 engineer-months to build plus 0.5–1 engineer ongoing, at a fully loaded platform engineering salary. Your figure will move with location, seniority and how much customization you genuinely need. The point is not the exact number — it is that the dominant cost of an open-source portal is the engineer attached to it, and that line item is the one most often left out of the business case.
When Backstage Is Not the Right Choice
We would rather say this before an engagement than after one. Three alternatives are genuinely better in specific situations — here is how we would advise you in each.
Roadie
Managed BackstageChoose when the framework fits but running it does not.
Roadie hosts the instance and absorbs the upgrade treadmill while you keep Backstage and its plugin ecosystem. Below roughly 30 developers, a subscription usually costs less than the half-engineer that self-hosting consumes.
Trade-off: you still own catalog modeling. No vendor can do that part for you.
Port
No-code portalChoose when you need a portal in weeks, not quarters.
Port is configuration-driven rather than code-driven, so there is no React work and no plugin maintenance. A small team can run it without dedicated frontend capability on the platform team.
Trade-off: lower ceiling. When you need something it does not model, you wait on a vendor roadmap.
Atmosly
Our productConsider when the bottleneck is execution, not cataloguing.
Portals catalog what exists and trigger actions elsewhere. If provisioning, fragile deploys or opaque Kubernetes cost are what is actually slow, Atmosly is the execution layer underneath — clusters, pipelines, environments, cost and security.
Trade-off: not a catalog replacement. If a service catalog is the need, Backstage or Roadie is the better tool.
The distinction that matters most is the last one, and it is the one teams get wrong most often. Backstage, Roadie and Port are all portals — none of them provisions a cluster, runs a pipeline or remediates an incident. So ask what is actually slow. If nobody knows what services exist or who owns them, a portal fixes that directly and Backstage is a strong choice. If the real complaint is that shipping is slow, a portal will document the bottleneck without removing it. The two layers also coexist perfectly well — several teams run Backstage as the front door with an execution platform underneath.
Not sure which of these you actually need?
A free assessment maps your current developer experience bottlenecks and tells you whether a portal, a managed portal or an execution platform solves them. If the answer is that you do not need us, we will say so.
Book a Backstage AssessmentOur Backstage Approach
Five steps, run as a product engagement rather than an infrastructure deployment. The software is the easy part — adoption is what determines whether the portal is still in use a year from now.
We start with the entity model because it is the decision that is hardest to reverse once teams have populated the catalog.
1. Assess
Interview developers about where time actually goes. Establish whether a portal is the right intervention at all, and which of Backstage, managed Backstage or an execution platform fits the bottleneck we find.
2. Model
Design the entity model — components, systems, APIs, resources, domains, ownership — against your real team topology. This is the step most implementations rush and later regret.
3. Build
Stand up the instance: authentication against your identity provider, automated catalog ingestion, TechDocs, the plugins that matter, and the first two Scaffolder golden paths for your most common service shape.
4. Adopt
Onboard teams in waves rather than all at once, starting with the ones whose pain is sharpest. Measure catalog coverage and template usage — a portal nobody uses is a project that failed quietly.
5. Sustain
Own the upgrade cycle, plugin compatibility and catalog hygiene — or train your team to. We are explicit at the start about which of those two you are buying.
