A platform team adopts Backstage, stands up the portal, imports the service catalog, and announces it to the org. A few months later it is a ghost town: the catalog is half-populated and stale, engineers still use their old bookmarks, and the platform team is stuck maintaining a portal nobody relies on. Backstage was not the problem; the expectation was. The team treated Backstage as an install-and-done product, when it is a framework you build a product on, and a Backstage that is stood up but not owned, populated, and integrated becomes a stale portal engineers route around. This is more than a rollout that fizzled. It is treating a framework as a finished product. Backstage in production is more than installing the portal. It is building and operating an internal developer portal on the Backstage framework, populating and keeping the catalog accurate, integrating the tools and golden paths engineers actually use, and owning it as a product with ongoing investment, so it becomes the place engineers go rather than a stale directory they route around. However, many teams adopt Backstage as an install-and-done product, and discover that without ownership, catalog accuracy, integration, and ongoing investment, it becomes a portal nobody uses. If you are a CTO or VP of Platform Engineering adopting Backstage, the intent of this article is:
- Define what adopting Backstage in production actually requires
- Show why install-and-done leads to a stale, unused portal
- Lay out the adoption lessons and pitfalls that decide whether it sticks To do that, let's start with the basics.
Sub-100ms Trading on AWS
P95 latency that used to drift past 100ms during peak now holds the target, and the trading desk stopped routing around the platform.
What Is Backstage in Production? The Basic Definition
At a high level, Backstage in production is running an internal developer portal built on the open-source Backstage framework: a service catalog, software templates, tech docs, and plugins, integrated with the org's real tools and golden paths, kept accurate, and owned as a product. Backstage provides the framework and building blocks; the production reality is the work of populating, integrating, operating, and continuously improving a portal engineers rely on. It is a platform you build on, not a finished tool you install. To compare: Adopting Backstage is like buying a powerful CMS framework and thinking you now have a website. The framework is real and capable, but the site, the content, the integrations, the upkeep, is the actual work, and without it you have an empty shell. Backstage gives you the developer-portal framework; the portal engineers use is what you build and operate on it.
Why Is Deliberate Backstage Adoption Necessary?
Issues that it addresses or resolves:
- A portal stood up but half-populated and stale
- Engineers routing around it to old tools and bookmarks
- The platform team maintaining a portal nobody relies on
Resolved Issues by Real Adoption
- The catalog is populated and kept accurate
- Real tools and golden paths are integrated, so the portal is useful
- The portal is owned as a product engineers rely on
Core Components of Backstage in Production
- A populated, accurate service catalog
- Integration with the org's real tools and golden paths
- Software templates surfacing the golden paths
- Ownership and ongoing investment as a product
- Adoption driven by real usefulness, not mandate alone
Modern Backstage Adoption Tools
- Automated catalog population and freshness checks
- Plugins integrating the org's actual tools
- Software templates wired to golden paths
- Metrics on portal usage and catalog accuracy
- A product owner and roadmap for the portal These tools make Backstage a real portal; owning it as a product, keeping the catalog accurate, and integrating what engineers use is what makes it stick rather than stall.
Other Core Issues They Will Solve
- The catalog stays trustworthy, so engineers rely on it
- Golden paths are discoverable and usable through the portal
- The portal earns usage rather than being mandated and ignored In Summary: Backstage in production is building and operating a developer portal on the framework, populated, accurate, integrated, and owned as a product, so it becomes the place engineers go, rather than an install-and-done portal that goes stale and unused.
Importance of Deliberate Backstage Adoption in 2026
Backstage is a popular default for developer portals, and the gap between adopting the framework and running a used portal is where teams stall. Four reasons explain why deliberate adoption matters now.
1. Install-and-done produces a ghost town.
Standing up Backstage without populating, integrating, and owning it yields a stale portal engineers route around. The install is the smallest part.
2. Catalog accuracy is everything.
A catalog that is stale or half-populated is not trusted, and an untrusted catalog is unused. Keeping it accurate, ideally automatically, is central.
3. Integration is what makes it useful.
A portal that does not connect to the tools and golden paths engineers actually use gives them no reason to come. Integration is the value.
4. It needs an owner and a roadmap.
Backstage is a product to run, not a project to finish. Without an owner and ongoing investment, it decays.
Traditional vs. Modern Backstage Adoption
- Install-and-done vs. build and operate as a product
- Half-populated, stale catalog vs. populated and kept accurate
- Disconnected portal vs. integrated with real tools and golden paths
- Mandated and ignored vs. useful and used In summary: A modern approach treats Backstage as a framework you build a product on, populated, integrated, owned, and improved, so the portal is used, rather than an install that goes stale.
Details About the Core Components of Backstage in Production: What Are You Designing?
Let's go through each component.
1. Catalog Layer
An accurate service catalog. Catalog decisions:
- The catalog populated, ideally automatically
- Freshness checks keeping it accurate
- Trust in the catalog maintained
2. Integration Layer
Connecting real tools. Integration decisions:
- Plugins integrating the org's actual tools
- The tools engineers use surfaced in the portal
- The portal as a hub, not an island
3. Golden-Path Layer
Surfacing paved routes. Golden-path decisions:
- Software templates wired to golden paths
- Paved routes discoverable through the portal
- Creation and shipping starting in Backstage
4. Ownership Layer
Running it as a product. Ownership decisions:
- A product owner and roadmap for the portal
- Ongoing investment, not a one-time project
- The portal improved over time
5. Adoption Layer
Earning usage. Adoption decisions:
- Adoption driven by real usefulness
- Usage and accuracy measured
- The portal earning its place, not mandated alone
Benefits Gained from Backstage in Production
- A trusted, accurate catalog engineers rely on
- Golden paths and real tools integrated and discoverable
- A portal that is used because it is useful and owned
How It All Works Together
The team treats Backstage as a framework to build a product on, not an install. The service catalog is populated, ideally automatically from real sources, and kept fresh with accuracy checks, because an inaccurate catalog is not trusted and an untrusted catalog is unused. Plugins integrate the org's actual tools, so the portal is a hub engineers have a reason to visit, not an island. Software templates wired to golden paths make the paved routes discoverable and let service creation and shipping start in Backstage. A product owner and roadmap keep the portal invested in and improving, rather than decaying after launch. And adoption is driven by genuine usefulness and measured, so the portal earns its place instead of being mandated and ignored. Because Backstage is populated, integrated, owned, and improved, it becomes the place engineers go, unlike an install-and-done portal that goes stale and gets routed around.
Common Misconception
Adopting Backstage means installing it and importing your services. Installing Backstage and importing a catalog is the very beginning, not the finish. Backstage is a framework; the production reality, an accurate catalog, integrations with the tools and golden paths engineers use, a product owner, and ongoing investment, is the actual work, and it is what determines whether the portal is used or becomes a ghost town. Teams that treat it as install-and-done get a stale shell. The framework is powerful, but the portal engineers rely on is something you build and operate on it. Key Takeaway: Backstage is a framework you build a product on, not an install-and-done tool. The catalog accuracy, integration, ownership, and investment are the work that decides adoption.
Real-World Backstage in Production in Action
Let's take a look at how it operates with a real-world example. We worked with a platform team whose Backstage install had become a ghost town, with these constraints:
- Make the catalog accurate and trusted
- Integrate the tools and golden paths engineers actually use
- Own the portal as a product so it stops decaying
Step 1: Populate and Keep the Catalog Accurate
Earn trust.
- The catalog populated, ideally automatically
- Freshness checks keeping it accurate
- Trust maintained
Step 2: Integrate Real Tools
Give engineers a reason.
- Plugins integrating the org's actual tools
- The tools engineers use surfaced
- The portal as a hub
Step 3: Surface Golden Paths
Make paved routes discoverable.
- Templates wired to golden paths
- Paved routes discoverable in the portal
- Creation starting in Backstage
Step 4: Own It as a Product
Stop the decay.
- A product owner and roadmap
- Ongoing investment
- The portal improved over time
Step 5: Earn Adoption
Useful, not mandated.
- Adoption driven by usefulness
- Usage and accuracy measured
- The portal earning its place
Where It Works Well
- Orgs that will own and invest in the portal as a product
- Platforms with golden paths and tools worth integrating
- Teams that keep the catalog accurate
Where It Does Not Work Well
- As an install-and-done project with no owner
- With a stale, half-populated catalog nobody trusts
- Mandated with no real usefulness behind it Key Takeaway: Backstage in production pays off when owned, populated, integrated, and improved as a product; it becomes a ghost town as an install-and-done project.
Common Pitfalls
i) Treating Backstage as install-and-done
Standing it up without ownership, population, and integration yields a stale shell. Build and operate it as a product.
- The catalog goes stale and untrusted
- Engineers route around the portal
- The platform team maintains a ghost town
ii) A stale or half-populated catalog
An inaccurate catalog is not trusted and not used. Populate automatically and keep it fresh.
iii) No integration with real tools
A portal disconnected from what engineers use gives them no reason to visit. Integrate the real tools and golden paths.
iv) No owner or roadmap
Backstage without ongoing investment decays. Give it a product owner and roadmap. Takeaway from these lessons: Backstage in production fits orgs that will run it as a product, but only with an accurate catalog, real integrations, ownership, and investment, not install-and-done.
Backstage Adoption Best Practices: What High-Performing Teams Do Differently
1. Treat Backstage as a product, not an install
Own it, invest in it, and give it a roadmap, because the framework is only the starting point.
2. Keep the catalog accurate automatically
Populate from real sources and enforce freshness, because an untrusted catalog is unused.
3. Integrate the tools and golden paths engineers use
Make the portal a hub connected to real workflows, so engineers have a reason to come.
4. Surface golden paths through templates
Wire software templates to paved routes so creation and shipping start in Backstage.
5. Measure and earn adoption
Track usage and accuracy, and win adoption through usefulness, not mandate alone. Logiciel's value add is helping platform teams adopt Backstage as a product, accurate catalog, real integrations, golden paths, and ownership, so the portal is used rather than a stale install. Takeaway for High-Performing Teams: Run Backstage as a product with an accurate catalog, real integrations, golden paths, and an owner, so it becomes the place engineers go, not a ghost town.
Signals You Are Running Backstage Well in Production
How do you know your Backstage is a real portal rather than a ghost town? Not by whether it is installed, but by whether engineers rely on it. These are the signals that separate a run-as-a-product portal from an install-and-done shell. Engineers use it. The portal is where they go, not a bookmark they ignore. The catalog is trusted. It is accurate and fresh, so people rely on it. Real tools are integrated. The portal connects to the workflows engineers actually use. Golden paths live there. Service creation and shipping start in Backstage. It has an owner. A product owner and roadmap keep it invested in and improving.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. Backstage in production depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake. The golden paths are what the portal surfaces. The platform tools are what it integrates. The service ownership and catalog data keep it accurate. Naming these adjacencies upfront keeps the work scoped and helps leadership see Backstage as a product to run, not a tool to install. The common mistake is treating each adjacency as someone else's problem. The catalog accuracy is your problem. The integrations are your problem. The ownership is your problem. Pretend otherwise and Backstage becomes a stale shell. Own the adjacencies you depend on, partner with the teams that hold them, and share the timeline.
Conclusion
When a team adopts Backstage as install-and-done, the portal becomes a ghost town: a stale, half-populated catalog engineers route around while the platform team maintains something nobody relies on. Backstage is a framework you build a developer portal on, and the production reality, an accurate catalog, real integrations, golden paths, ownership, and ongoing investment, is the work that decides whether it sticks. Run Backstage as a product, and it becomes the place engineers go rather than a shell they ignore.
Key Takeaways:
- Backstage is a framework you build a product on, not an install-and-done tool
- A stale, disconnected, unowned Backstage becomes a ghost town engineers route around
- Catalog accuracy, real integrations, golden paths, and product ownership are what make it stick Adopting Backstage well requires running it as a product. When done correctly, it produces:
- A trusted, accurate catalog engineers rely on
- Golden paths and real tools integrated and discoverable
- A portal that is used because it is useful and owned
- Ongoing improvement rather than post-launch decay
Cut Your Kubernetes Bill
You are paying for the cluster you requested, not the one you use, and the gap is enormous.
What Logiciel Does Here
If your Backstage install has become a stale ghost town, we help you run it as a product, accurate catalog, real integrations, golden paths, and ownership, so engineers actually use it.
Learn More Here:
- Golden Paths: What Backstage Should Surface
- Keeping the Service Catalog Accurate
- Owning the Developer Portal as a Product At Logiciel Solutions, we work with platform engineering leaders on Backstage adoption as a product. Our reference patterns come from production internal developer portals. Book a technical deep-dive on making your Backstage portal one engineers actually use.
Frequently Asked Questions
What does running Backstage in production actually involve?
Building and operating an internal developer portal on the Backstage framework: populating and keeping the service catalog accurate, integrating the org's real tools and golden paths, surfacing software templates, and owning it as a product with a roadmap and ongoing investment. Backstage supplies the framework and building blocks; the used portal is what you build and operate on it.
Why do Backstage rollouts often become ghost towns?
Because teams treat Backstage as install-and-done, standing up the portal and importing a catalog, then stopping. Without an accurate catalog, integration with the tools engineers use, golden paths, and an owner investing over time, the portal goes stale and engineers route around it to their old tools, leaving the platform team maintaining something nobody relies on.
Why is catalog accuracy so important in Backstage?
Because a stale or half-populated catalog is not trusted, and an untrusted catalog is unused, engineers will not rely on data they suspect is wrong. Keeping the catalog accurate, ideally through automated population and freshness checks, is central to Backstage adoption; it is the foundation everything else in the portal builds on.
How do golden paths relate to Backstage?
Golden paths are the paved, opinionated routes through the platform; Backstage is where you surface and launch them, via software templates that let engineers create and ship services on the golden path from the portal. Backstage without golden paths is a catalog; golden paths without a portal are hard to discover, so they work together.
Is Backstage a finished product you install?
No. Backstage is an open-source framework and set of building blocks, not a finished product. The production portal, accurate catalog, integrations, golden paths, and ongoing operation, is what you build on it, and it needs a product owner and continued investment. Treating it as install-and-done is the single most common reason adoptions stall.
