Backstage Takes a Team to Run.
NOFire AI Does Not.

Most Backstage installations need a dedicated platform engineer just to keep the portal current. NOFire AI builds your catalog from what it observes in production. No YAML to write, no plugins to maintain, no upgrade cycles to plan.

NOFire.ai · Service Wiki
Service wiki
Generated from your environment · observed continuously
1 incident3 warning
Search by service name
CriticalityHealthOwner
⊞ List∿ Graph
frontend-proxywarning
TIER 2productionno owner1 gap
calls 6by 19deploy 1h ago
readiness88%
checkoutwarning
TIER 2productionbackend2 gaps
calls 9by 19deploy 6h ago
readiness44%
fraud-detectionincident
TIER 2productionno owner3 gaps
calls 3by 11deploy 5d ago
readiness31%
product-cataloghealthy
TIER 3productionbackend
calls 3by 14deploy 1d ago
readiness72%
paymenthealthy
TIER 3productionbackend
calls 1by 7deploy 3h ago
readiness90%
cartwarning
TIER 3qabackend2 gaps
calls 2by 8deploy 12h ago
readiness27%
18 services·sorted by criticality·last scan: 4s ago
Trusted by
LearnWorlds Adalat AI Pallma Ergeon Instacar HarborLab
Backstage pain points

The real cost of running Backstage

The catalog is always stale

Backstage populates entries from catalog-info.yaml files that engineers write once and rarely touch again. Trust collapses the moment entries no longer reflect production reality. A portal built on stale declarations becomes a single source of lies.

Upgrades ship every two weeks and break things

Backstage releases bi-weekly and does not honor semantic versioning. Patch releases carry breaking changes. Teams report spending a dedicated week on a single major upgrade, with ongoing version maintenance consuming 15-20% of one engineer's time per year.

It is a framework, not a finished product

Reaching a usable Backstage instance takes 70-plus setup steps and six to twelve months of TypeScript and React expertise. Each plugin is a separate codebase to write, test, and maintain. Cross-plugin queries are architecturally impossible.

NOFire AI vs Backstage

NOFire AI vs Backstage: what the two approaches actually do

Backstage catalogs from declaration. NOFire AI catalogs from observation. One approach works when nobody is watching.

CapabilityNOFire AIBackstage
Catalog populationInferred continuously from DNS/L7 observed calls, Prometheus rules, deploy events, and incident timelines. No input required.Engineers write and commit catalog-info.yaml files by hand. Accuracy depends on whether those files get updated.
Keeping the catalog currentAgents reconcile the entity graph against production signals on every change event. The catalog reflects what is running now.Catalog drifts the moment it is populated. Staleness is the documented default state for any team without a dedicated catalog-hygiene process.
Upgrade cadenceSaaS delivery. No version upgrades, no breaking changes, no migration sprints on your side.Bi-weekly releases that do not honor semantic versioning. A major version upgrade costs a dedicated sprint of one to two weeks.
Blast radiusCalculated from PageRank over the observed dependency graph. Shows which downstream services are at risk before an incident confirms it.Stores declared relationships from YAML. No dependency graph traversal, no criticality scoring, no blast radius computation.
Cross-domain queriesTelemetry, incidents, change events, and repository signals are fused into a single entity graph. Compound questions work.Each plugin has its own frontend and backend context with an independent database schema. Cross-plugin queries are architecturally impossible.
Platform engineer headcountZero dedicated headcount for catalog maintenance. Agents observe continuously and reconcile without human input.At 200-plus engineers, teams typically assign one to two dedicated platform engineers to keep Backstage healthy, plus plugin development overhead.
Time to first valueA working catalog from live production signals in under 30 minutes. No YAML, no plugin wiring, no React.Six to twelve months before the portal reaches a usable state. 70-plus setup steps. Requires TypeScript and React expertise.
Readiness scoringFour binary checks derived from observed facts: has owner, has metrics, has alerts, is not a single point of failure.No native readiness scorecard. Scoring requires a custom plugin, which requires a React developer and an ongoing maintenance commitment.
How it works

One panel. Every layer of service knowledge.

The service detail page in NOFire AI is populated entirely from what agents observe: entity graph, change events, Prometheus rules, incident history, and repository analysis. Nothing is declared. Nothing goes stale.

NOFire.ai · checkout · service detail
checkout
v24 · production
No SLO: No SLO / recording rule defined
Important · 1 gap
Overview

The checkout service orchestrates the end-to-end purchase flow, coordinating payment processing, inventory validation, and shipping arrangements. It acts as the central transaction coordinator, calling payment, product-catalog, cart, item validation, shipping, currency, email, kafka, and flagd.

Change timeline
deploya3f91cfeat: add circuit breaker for payment retriesm.chen
2h ago
hotfix7d204bfix: OOM crash at peak load (memory cap 20MB)p.moustafellos
4d ago
configc9e812chore: tune GC percent to reduce goroutine bloata.sapranidis
9d ago
deployf10a3drefactor: optimize product-catalog query batchingm.chen
19d ago
Observability
Scope: {service_name="checkout", k8s_namespace_name="otel-demo"}
Latency
rpc_server_duration_milliseconds_bucket (histogram): server-side RPC request duration
histogram_quantile(0.99, rate(rpc_server_duration_milliseconds_bucket{service_name="checkout",k8s_namespace_name="otel-demo"}[5m]))
rpc_client_duration_milliseconds_count (counter): client-side RPC call count
rate(rpc_client_duration_milliseconds_count{service_name="checkout",k8s_namespace_name="otel-demo"}[5m])
Throughput
traces_span_metrics_calls_total (counter): total span calls
rate(traces_span_metrics_calls_total{service_name="checkout",k8s_namespace_name="otel-demo"}[5m])
rpc_server_responses_per_rpc_count (counter): RPC responses per call
rate(rpc_server_responses_per_rpc_count{service_name="checkout",k8s_namespace_name="otel-demo"}[5m])
Custom
go_goroutine_count (counter): number of active goroutines
rate(go_goroutine_count{service_name="checkout",k8s_namespace_name="otel-demo"}[5m])
go_config_gogc_percent (gauge): Go GC target percentage
go_config_gogc_percent{service_name="checkout",k8s_namespace_name="otel-demo"}
Alerts
Service high error rate: warning, for 90s
Service high latency: warning, for 1m
Service traffic spike: warning, for 30s
When this breaks
All purchase flows halt. Checkout is the sole transaction coordinator.[INV-27]
frontend-proxy p99 latency spikes as retries queue; circuit breaker trips within 90s.[INV-26]
19 downstream services lose checkout context: fraud-detection, payment, shipping go idle.[INV-26]
Runbooks & Learnings
📄Checkout investigation: diagnose latency spikes, payment retries, and OOM events via p99 trend + goroutine countRunbook
📄Checkout service lacks Prometheus metrics instrumentation or scraping configuration, preventing o...Learning
📄Memory limit of 20MB insufficient for checkout service workload requiring 18-19MB, causing OOMKil...Learning
Ontology
Ownerbackend● observed
Lifecycleproduction
Criticality
ImportantTIER 2● inferred44%
Readiness
Ready · 100%
owner ✓metrics ✓alerts ✓resilient ✓
Health
No signal yet● unknown

Live health (SLO / error rate / saturation) arrives with the state engine.

Depends On
shipping
● observed
312/min
p99 18ms
email
● observed
198/min
p99 42ms
cart
● observed
1,840/min
p99 9ms
product-catalog
● observed
2,103/min
p99 11ms
otel-collector
● observed
async
p99 n/a
currency
● observed
876/min
p99 7ms
payment
● observed
420/min
p99 134ms
kafka
● observed
async
p99 n/a
flagd
● observed
654/min
p99 3ms
Structure
owned_bydeployment:checkout
100%
● observed
Blast Radius
accountingadcartcurrencyemailflagdfraud-detectionfrontendfrontend-proxyimage-providerkafkaload-generatorotel-collectorpaymentproduct-catalogproduct-reviewsquoterecommendationshipping
observed
Past Incidents
INV-27P1Checkout failing under payment load spike
resolved in 23 min
INV-26P1Checkout unresponsive after OOM kill
resolved in 41 min
INV-22P2ProductCatalogService intermittent UNAVAILABLE
resolved in 1h 12m
INV-20P2Checkout missing Prometheus scrape target
resolved in 55 min
INV-18P2Checkout latency p99 spike on EU traffic
resolved in 38 min
INV-12P3Checkout lacks alerting rule on error rate
resolved in 2h 4m
INV-10P3No SLO defined for checkout success rate
● open
INV-9P3Ownership unset: no team assigned to checkout
● open
Source
Production signals + repos
Manual input
None
Update frequency
Continuous
Maintenance required
Near zero

Deterministic facts. LLM-narrated prose.

The catalog structure, dependencies, readiness, and blast radius come from your system, not from an LLM. The LLM only narrates what it cannot invent: prose about what the facts mean.

Every claim cited.

Known mitigations cite actual investigation IDs and change event records. If there is no evidence, the section says so. NOFire AI does not fill in gaps.

Provenance on every dependency.

Each dependency carries a label: runtime (observed from DNS/L7 call graphs), synthesized (inferred), or intent (declared). You see exactly how confident the catalog is.

Setup

Connect your stack. Your catalog appears.

No migration project. No catalog entries to write. No plugins to configure.

01

Connect your signals

Link your observability stack, Kubernetes, CI/CD, and incident tooling. NOFire AI starts reading your entity graph and change history immediately.

02

Agents distill knowledge

Deterministic extractors build a structured skeleton: ownership, dependencies with provenance, readiness checks, blast radius. No LLM invents facts.

03

Catalog stays current

Every deploy, incident, rollback, and ownership change is reflected automatically. Engineers read the catalog instead of maintaining it.

Integrates withPrometheusGrafanaDatadogKubernetesGitHubGitLabPagerDutyLokiTempo
Also comparing
FAQ

Switching from Backstage

How long does it take to replace Backstage with NOFire AI?

Most teams have a working catalog from live production signals within 30 minutes of connecting their first integration. There are no catalog-info.yaml files to migrate and no plugin projects to rebuild. The catalog builds from what is already running in production.

Does NOFire AI support the same integrations as Backstage?

NOFire AI connects to Prometheus, Grafana, Datadog, Kubernetes, GitHub, GitLab, PagerDuty, Loki, Tempo, and other observability and CI/CD tooling. Instead of plugin maintenance, integrations are managed as a SaaS connection. No React or TypeScript required.

What happens to our existing Backstage catalog data when we migrate?

Nothing needs to migrate. NOFire AI rebuilds the catalog from observed production signals, not from your existing YAML. Services that exist in production appear automatically. Ownership, dependencies, and readiness checks are inferred from live telemetry, not imported from catalog-info.yaml files.

How does NOFire AI keep the service catalog accurate without YAML?

NOFire AI agents observe your entity graph (DNS and L7 observed calls), change event history, Prometheus rules, metric catalog, and incident investigations continuously. Every ownership change, new dependency, and readiness failure appears in the catalog as it happens. Nobody has to update a file.

Cut the Backstage overhead. Keep the catalog.

Connect your stack and NOFire AI builds the catalog from what it observes. No platform team required, no YAML to maintain, no upgrade sprints.

By submitting you agree to our privacy policy.

Book a demo