Self-Hosting vs Managed Backstage

Once a team decides Backstage is the right portal, the next fork is whether to run it yourself or buy a managed distribution such as Spotify’s Portal or Roadie. The choice shapes your operational load, your upgrade cadence, and how much of your platform team’s time goes to running the tool versus improving it. This how-to gives you a decision framework and the concrete signals that point each way. It extends Choosing the Right Framework within Developer Portal Architecture & Frameworks.

Prerequisites

  • A rough sizing of your portal: number of services, expected users, and how custom your plugin needs are.
  • Honest visibility into your platform team’s capacity — self-hosting is an ongoing commitment, not a one-time setup.
  • A sense of your compliance constraints: data residency, network isolation, and audit requirements often narrow the options.
  • Familiarity with the Backstage upgrade cadence, since who owns upgrades is the crux of the decision.
Inputs to the hosting decision Sizing, team capacity, compliance constraints, and upgrade appetite feed the self-host versus managed choice. portal sizing team capacity compliance constraints upgrade appetite Clear decision host or buy
The decision is rarely about features — both paths run the same Backstage — and almost always about who carries the operational weight.

Exact Configuration

The “configuration” here is a scoring rubric. Weight each factor for your context and see which column wins.

  1. Score operational ownership. Self-hosting means you own uptime, upgrades, database, and scaling; managed means the vendor does.

    Factor                     Self-host   Managed
Uptime / on-call            you         vendor
Backstage upgrades          you         vendor
Deep plugin customization   unlimited   vendor-gated
Data residency control      full        vendor-dependent
Time to first value         weeks       days

  2. Estimate the true cost of self-hosting, which is dominated by engineer time, not infrastructure.

    Self-host annual cost ≈ (infra) + (0.5–1.5 platform engineers)
Managed annual cost   ≈ (per-seat licence) + (light integration effort)

  3. Check the customization ceiling. If you need bespoke backend plugins with unusual dependencies, confirm the managed option allows them before committing.

Where responsibility sits Self-hosting puts upgrades, uptime, and scaling on your team; managed shifts them to the vendor, trading control for time. Self-host full control you own upgrades + uptime unlimited customization Managed fast time to value vendor owns upgrades customization gated
The trade is symmetrical: control and customization on one side, saved engineer-time and a managed upgrade path on the other.

Validation

# This is a decision, so "validation" is a pre-commitment checklist.
# 1. Can you name who is on-call for the portal at 3am?
echo "Self-host requires a named owner for portal uptime."

# 2. Run a customization spike against the managed option's limits
#    before signing — build your hardest plugin on a trial.
echo "If the trial cannot host your hardest plugin, managed is ruled out."

# 3. Model 3-year cost both ways, including engineer time at loaded rate
python3 - <<'PY'
engineers, loaded = 1.0, 200000
infra, licence = 30000, 90000
print("self-host/yr:", infra + engineers*loaded)
print("managed/yr:  ", licence)
PY
Pre-commitment checks A named on-call owner, a passing customization spike, and a three-year cost model validate the choice. Named owner for uptime Spike passes hardest plugin Cost modelled 3-year, loaded
Run the customization spike before signing — discovering your hardest plugin is unsupported after migration is the expensive way to learn.

Edge Cases & Troubleshooting

Situation Signal Better choice
Small platform team, urgent need No spare capacity to run infra Managed — buy time to prove value
Heavy bespoke backend plugins Unusual native dependencies Self-host — avoid the customization ceiling
Strict data residency Data cannot leave your network Self-host, or a managed option with in-VPC deployment
Started managed, outgrew it Repeatedly blocked by vendor limits Plan a migration to self-host; the catalog is portable
Started self-host, drowning in ops Upgrades slip, on-call burns out Consider managed; you keep your plugins and config
Hosting pitfalls by class Capacity and residency drive the initial choice; outgrowing limits or drowning in ops drive a later switch. Initial choice low capacity data residency → managed / in-VPC Later switch outgrew limits ops overload → migrate, keep config
The choice is reversible: because the catalog and plugins are portable, an early decision that stops fitting is a migration, not a rewrite.

Frequently Asked Questions

Is managed Backstage locked-in?

Less than most SaaS. The catalog entities, TechDocs, and standard plugins are open-source Backstage underneath, so a well-run managed offering keeps your configuration portable. The lock-in risk lives in vendor-specific plugins and workflows — minimize it by preferring upstream plugins over proprietary ones.

Can we start managed and move to self-host later?

Yes, and many teams do exactly that — buy speed early, then bring it in-house once the value is proven and the platform team has grown. Because the underlying data model is the same, migration is mostly re-pointing infrastructure and re-homing plugins, not re-authoring content.