Backstage or Port evaluation

Separate the platform from its front door

An internal developer platform includes the supported workflows and systems that perform work. A developer portal helps people discover and invoke them. It may display a catalog, offer request forms and link to operating evidence. A portal can be useful without hiding every underlying tool.

A portal presents a platform

The capstone connects an interface to the working Ship Boring delivery system. It does not replace image builds, configuration review, policy evaluation, reconciliation, or application verification. A form that returns a request ID is only the start of that journey.

Backstage provides an extensible framework you operate. Port provides a hosted product with catalog and self-service capabilities. Compare them using current documentation and the actual integrations you need; do not assume identical features, free pricing, or zero maintenance.

Evaluate the same small task

Use the task defined in the first module: request a reviewed local MicroBank change, follow the resulting Git change, and see authoritative status. Compare catalog modelling, input validation, execution integrations, authentication, permissions, audit evidence, and the behavior when a dependency is unavailable.

For Backstage, include backend/plugin upkeep, database choice, and local process memory. For Port, include account permissions, execution backend, data sent to the service, and current plan limits. Either can link to existing tooling before deeper integration is built.

Evaluate one journey in both products

Use the same task for each candidate: find Ledger's owner, request a local annotation change, reach the resulting PR and see whether it reconciled. Do not compare one polished homepage with another product's default installation screen.

The detailed capstone uses Backstage so the request template can be reviewed in the repository. A Port implementation needs its own supported execution integration; it is not a YAML format conversion. Choose one for the first run rather than operating two portals on the same small host.

Before installation, make a decision record with your required journey, known constraints and unresolved questions. Leave product plan limits and maintenance effort as items to verify from current documentation, not assumptions about free or effortless operation.

Try it

Write a decision record with evidence for each criterion. Choose one for the first capstone. The detailed template exercise uses Backstage; a Port alternative follows the same request contract and acceptance checks, with its own supported action implementation.

Run the portal separately from heavy local telemetry when necessary. The host has 16 GB RAM, so measure memory pressure with the components you actually run. A local evaluation server is not a production portal deployment.

Checkpoint and revision

Explain why the selected interface fits this workflow and who will maintain its integrations. Describe the operator fallback when the portal is unavailable. Explain which parts of the software delivery lifecycle the portal supports and which remain manual or unimplemented.

Compare your reasoning

A portal unavailable during an incident should not erase the runbook or desired-state history. Keep a documented route to the underlying tools. The next bite builds a useful catalog model before any self-service form is introduced.

Sources

Backstage installation↗, Backstage templates↗, Port self-service↗.