Why Backstage software templates need golden path design before the first form
Platform teams that build a paved road for new services usually start with the form, and that is the wrong order. Backstage software templates, run by the scaffolder, create repositories, pipelines and infrastructure from a form a developer fills in. The technology is the easy part. The hard part is agreeing what a golden path includes, who owns it, and how it changes after the first team uses it. Settle those three questions before any template YAML is written, or the portal will reproduce whatever ambiguity existed in the platform team's own process.
A template that works once is not the same as a template that teams keep using. The first run usually succeeds because a platform engineer knows which secret names, cluster names and repository settings to supply by hand. The second and third teams hit every assumption that was never written down. Common failure modes follow a predictable pattern. Templates go stale when the base repository, Helm chart or CI workflow they reference changes and nobody updates the template. Pipelines become unowned when the scaffolder creates a repository with a workflow file that no team maintains after the first deployment. Forms ask for data nobody can verify, such as a cost center or a data classification that the developer types from memory, and the value then flows into tags, catalog entries and audit records.
Before designing the first form, write a short ownership record for each template. It should name the owning team, the escalation path, the supported stack, the review cadence and the criteria for retiring a template. Ask who approves a change to the golden path, whether that change needs a version bump visible to consuming teams, and how existing services adopt a new version or stay on the old one. Confirm these answers with the teams that will run the pipelines in production, not only with the people building the portal.
Then decide which inputs the form should collect at all. Every field should either drive a value the scaffolder writes or be something the platform can check. Where a value comes from a system of record, such as an owner group from the identity provider or a catalog entity that already exists, prefer a lookup over free text. Where a value cannot be checked, consider whether it belongs in the form at all. Review steps and custom scaffolder actions can enforce some of these rules, but only if the template owner has decided what they must enforce. Plan the review of each template against the actual repositories and pipelines it produces, and record the decisions so the next template author can follow the same rules.
Which Backstage parts a software template depends on
A software template is not a single file. It runs through several Backstage parts, each of which can fail or drift independently, so the platform team needs to know what each one contributes and what it relies on before publishing a golden path.
Software Templates feature
Software Templates is one of the core built-in features in the Backstage architecture overview, alongside the Software Catalog and TechDocs. It is the feature that presents a template to developers as a form and runs it. Because it is built in, it moves with the rest of the Backstage release line, so template changes should be tested against each upgrade. Confirm which Backstage version your portal runs before you design templates for it.
Template YAML parameters and steps
Each template is a YAML definition that declares the form parameters a developer fills in and the ordered steps the run executes. Parameters determine what the form validates, and steps determine what gets created. Every parameter a step consumes must exist in the form, or the run fails late. Review the YAML in version control with the same rigor as application code, and confirm the schema your Backstage version expects before writing new templates.
Scaffolder backend and actions
The scaffolder backend executes template steps by calling actions, which are the units that fetch skeleton code, write files, create repositories and call external systems. Actions run with the permissions and tokens the backend holds, so each action's scope is a security decision. Inventory the built-in actions your version provides, and plan any custom action as a separately tested component with its own owner and limits.
Catalog registration of new components
A template creates a repository and project, but the new component is not useful until it is registered in the Software Catalog. Registration usually adds a catalog descriptor file to the new repository and records the owner, system and lifecycle that the platform relies on. Without it, the component is invisible to search, ownership views and any template that references it. Check that every template ends with a registration step and that the owner value maps to a real group.
TechDocs references in templates
Templates often generate a documentation skeleton so new components ship with TechDocs pages from day one. The template must place that skeleton where TechDocs expects it, and the documentation build must succeed for the new repository. Decide who owns the docs site configuration and whether the template sets default documentation metadata. Confirm the TechDocs publishing setup in your environment before relying on it in a golden path.
Kubernetes references in templates
A template may add deployment manifests or annotations that let the Kubernetes plugin link a new component to its running workloads. These references depend on consistent labels and on the cluster being reachable from the portal. A mismatched label means the component shows no workloads, which looks like a portal defect but is a template defect. Agree on one label convention across all templates and verify it on a test deployment.
Decisions to make before writing the first template
This table compares the main design choices for a Backstage software template and what each one costs your platform team to run. Read each row as a decision: the middle column says when the option fits, and the right column names the ongoing work it creates. Settle the first three rows before writing any template, because they determine how many templates you maintain and how far each one reaches into your repositories and pipelines.
| Decision | When it fits | What it costs you operationally |
|---|---|---|
| One template per golden path | A small number of distinct paths, such as a web service and a batch job, with different stacks or ownership | Many near-identical templates to keep in sync, so every fix to shared steps must be repeated in each one |
| Parameterized shared template | Many variants of one path that differ only in language, region or options, with one owning team | Conditional logic in the template grows over time and becomes harder to test and review for each combination |
| Built-in scaffolder actions only | Templates that fetch a skeleton, publish to a Git host and register the component in the catalog | Limited to the actions your Backstage version ships, so anything else needs a workaround in the template itself |
| Custom scaffolder actions | Steps the built-in set cannot perform, such as calling your ticketing, secrets or cloud account APIs | You own the action code, its tests and its dependency upgrades, and its permissions must be reviewed like any other plugin |
| New repository per template run | Each service needs its own repository, access controls and release history from day one | Every new repository inherits branch protection, secrets and pipeline setup that must be applied and checked by the template |
| Template writes into an existing repository | Adding a component, job or module to a monorepo or an established codebase | Merge conflicts and ownership questions arise, and the template must handle reruns without overwriting developer edits |
| Pipeline copied into each new repository | Teams need to change their pipeline independently after creation, or the pipeline depends on repo-specific steps | Pipeline fixes do not reach existing repositories unless you run a migration, so drift grows over time |
| Pipeline referenced from a shared definition | Many services should share build, scan and deploy standards that the platform team updates centrally | Changes to the shared pipeline affect every consumer at once, so versioning and a staged rollout need to be planned |
| Template provisions infrastructure | The golden path must deliver a running environment, and your cloud and IaC access model allows the template to apply changes | The template holds credentials with broad reach, and failed partial runs leave resources to clean up, so approval and audit steps are required |
| Template only requests infrastructure | Provisioning belongs to a separate ticketing or IaC workflow that your platform or security team already controls | The template must hand off a request reliably and track its status, and developers wait on a second system to finish |
How to build a software template from form to registered component
This sequence takes a golden path from a written scope to a Backstage software template that creates a repository, pipeline, catalog entry and approved infrastructure request. Each step ends with a check the reviewing team can run. The order matters because review and testing depend on the validation and outputs built in the earlier steps.
Define the golden path scope in writing
Before anyone edits a template, write down what the golden path covers. Name the owning team, the service types it creates, the languages and runtimes allowed, the repository layout, the pipeline stages and every infrastructure resource the template may request. List the items that are out of scope too. The platform team and a sponsoring engineering lead sign the document. Done when the signed scope lists every output the template will create, and each output has a named owner who will maintain it after handover.
Design the parameter form with validated fields
Turn the scope into the template parameter form. Give each field a type, a default only where a default is safe, and validation rules such as allowed values, name patterns and required ownership fields. Use enumerations for fixed choices and free text only where it is unavoidable. Pull the owning group from the catalog so the new component has an owner from the start. Done when a tester submits invalid values and the form rejects each one with a clear message before any action runs.
Write the fetch and publish steps
Use the fetch actions to pull a skeleton from a versioned template repository and render the parameters into it. Publish the result to a new repository in your source host with the publish action. Set branch protection and required reviewers through the publish action or a follow-up step, and confirm the credential used has only the scopes it needs. Done when the generated repository exists, contains the rendered files, and builds cleanly from a fresh clone.
Add the pipeline and catalog registration
Add the CI pipeline definition to the skeleton and a catalog-info.yaml file that declares the component, its system, owner and lifecycle. Use the register action so the catalog ingests the new entity, or confirm that a catalog provider will pick it up from the repository. Done when the first pipeline run succeeds and the component appears in the catalog with the owner set in the form and a link to its repository.
Wire infrastructure requests to provisioning
Connect infrastructure requests to a provisioning path you already run, such as your infrastructure-as-code pipeline or a ticketing workflow. Use a custom scaffolder action or a call to an existing API. Keep credentials on the server side, pass only the parameters the action needs, and record the requester and a request identifier. Done when a test run creates the expected request in the provisioning system and fails cleanly when given an input that the provisioning path rejects.
Add a review step before resources exist
Insert a review step that pauses the run before any repository, pipeline or cloud resource is created. Show the reviewer the rendered parameters and the planned outputs, and require approval from a named group. Confirm in your Backstage version's scaffolder documentation which review mechanism is available and how it behaves. Done when a run waits at the review, a rejection stops the run with no resources created, and an approval lets the run continue.
Run the template end to end
Run the template end to end in a non-production target: a sandbox source organization, a separate cloud account or project, and a test catalog. Check each output against the signed scope. Then delete the test resources and run the template again to confirm it is repeatable. Record every failed action and fix the template before release. Done when two consecutive runs produce identical outputs with no manual edits, and the cleanup removes all test resources.
When custom scaffolder actions are worth writing
Write a custom scaffolder action only when a template must cause a side effect that the built-in steps cannot perform safely or repeatably. The built-in actions cover common work such as fetching a skeleton, templating files, publishing to a source repository and registering a component in the catalog. A custom action earns its place when the template has to call an internal provisioning API, create a cloud account through your own landing zone process, or register a reference to a secret in your vault. Before writing one, check whether a pipeline step that runs after scaffolding, or a manual approval step in the template, would meet the need. Each custom action becomes code your platform team owns, tests and upgrades, so the decision should be deliberate.
Treat each action as a versioned interface that ships with the template that calls it. Keep the action's input schema, its output names and its behavior in the same repository or release stream as the template that depends on it, so a template and the action it needs can be reviewed and rolled back together. When you change an input, add a new optional field before removing an old one, and give breaking changes a new action name rather than silently altering the old one. Existing templates in the catalog keep running against the version they were built for, which makes the change set easier to reason about during a platform review. Confirm with your own engineers how your repository layout will handle this before the first action is published.
Validate inputs before any side effect happens. Scaffolder actions receive values from a form, and those values can be incomplete, malformed or outside the naming rules your cloud accounts enforce. Put schema constraints on every input in the template definition, then repeat the critical checks inside the action itself, because the action can be invoked from other paths. Run all validation and lookups first, such as confirming that a requested account name is free or that a cost center exists, and only then call the provisioning API. A failure at the validation stage costs little, while a failure after a partial provisioning call can leave resources that someone must find and remove by hand.
Design every side-effecting action to be idempotent. Scaffolder tasks can be retried after a timeout, a network error or a worker restart, and a retry that creates a second cloud account or a second repository is a serious operational problem. Derive a stable key from the task and the requested resource, pass it to the provisioning API where that API supports idempotency keys, and check for an existing resource with that key before creating a new one. Record the outputs so a retry can resume rather than repeat work. Ask the owners of each internal API whether they support idempotency keys, and if they do not, plan an explicit lookup step and document the failure cases your team has tested.
Plan for Backstage upgrades as a separate workstream. Custom actions import scaffolder packages, and the scaffolder API can change between Backstage releases, so a monthly upgrade may require changes to action code even when your templates are unchanged. Keep actions in a plugin-style module with tests that run the action against a stub of each external API, and include them in the upgrade checklist every time you move @backstage packages forward. Revisit the decision to write an action each time a built-in action gains the capability you needed. The code structure for these modules is covered in the plugin development topic, so this section sets the criteria rather than the implementation.
Who owns templates, reviews changes and retires old golden paths
The platform team owns the template catalog as a whole. It decides what counts as a golden path, sets the naming and pipeline standards every template must follow, and is the group that changes the shared conventions other roles depend on. Its work is less about writing individual templates and more about keeping the full set coherent, supported and understandable to developers.
- Catalog ownership: Keep one registry of template entities, and record a named owner for each one so no template is left without someone accountable.
- Standards: Publish naming rules for repositories, services and pipelines, plus the files every generated project must contain.
- Change review: Review proposed changes to shared skeletons, parameters and custom actions before they reach the default branch.
- Versioning and deprecation: Decide when a path is retired, name its replacement, and set how long the old version stays usable. Confirm these periods with your own governance process.
- Notification: Announce changes through the catalog, release notes and your internal channels, so teams do not depend on noticing a diff.
Check whether your team can name the person who approves a change to a shared skeleton, and whether that person has the time to review it.
Each template owner is accountable for one golden path, from its parameters and skeleton to the pipeline and infrastructure it generates. Owners respond when a generated project breaks, and they publish changes through the process the platform team sets. Their knowledge of the path's users is what lets them judge whether a fix belongs in the template or in the consuming project.
- Scope: Own a single path, such as a service with its CI pipeline, and document exactly what it creates.
- Breakage response: Triage reports from teams that used the template, reproduce them against the current version, and decide whether the template or the consumer needs the change.
- Publishing: Make changes on a branch, test by scaffolding into a throwaway repository, then open the change for review.
- Versioning: Tag template releases and flag breaking parameter changes in release notes so consumers can plan their own updates.
- Deprecation: Announce retirement early, point users to the replacement path, and keep the old template working until the agreed end date.
Confirm that every template in your catalog has a named owner who still holds the role and knows where the path is used.
Reviewers and security staff approve what a template is allowed to do. Templates can create repositories, write pipeline files, request cloud resources and call external systems, so these approvals carry the highest risk in the process. The review centers on the actions, data handling and infrastructure scopes a template uses, which matter more than the wording of the skeleton files.
- New actions: Approve any new custom scaffolder action, and any change to an action's inputs, before it becomes available to template users.
- Data handling: Check which parameters are stored, logged or sent to external services, and confirm that secrets are supplied through approved mechanisms rather than typed into a form.
- Infrastructure scopes: Confirm which cloud accounts, namespaces or identity roles a template can provision into, and that the scope matches the owning team's responsibilities.
- Evidence: Link each review record to a specific template version so auditors can trace what was approved and when.
- Change feed: Subscribe to changes for templates in regulated areas, so approval does not depend on someone happening to notice an update.
Ask whether reviewers can see a diff of permissions and scopes between versions, not only a diff of the template text.
Limiting what a template can do on a developer's behalf
A software template runs with credentials that can create repositories, pipelines and cloud resources for someone who only filled in a form. The controls below decide who can start a template, what it is allowed to touch, and where it must stop for a human decision.
Who can run each template
Decide which users and groups can see and execute each template, and bind that to permissions in the Backstage permission framework rather than relying on portal visibility alone. Map template access to the same team ownership used in the catalog, so a platform team can run a restricted template that application teams cannot. Check that a user who cannot run a template in the portal also cannot trigger its scaffolder task through the API.
Scoping scaffolder tokens
The scaffolder calls source control and provisioning APIs using tokens held by the Backstage backend, not by the person running the template. Ask which token creates repositories, which creates pipelines or cloud resources, and whether each token has only the scopes for its own action. Confirm the token's owner, rotation schedule and what happens to templates when it is revoked.
Referencing secrets instead of embedding them
Template parameters are stored in task records and shown back in the portal, so a password or API key entered into a form value can leak into logs and history. Templates should reference secrets by name from the backend secret store or the target CI system, and template files should contain placeholders only. Review every template for literal credentials and confirm that custom actions read secrets at runtime without echoing them.
Approval steps before resources exist
Place review or approval steps before any action that creates a repository, cloud account or paid resource, so a rejected request leaves nothing behind. Confirm that the approval gate itself is enforced by the backend and cannot be skipped by editing the form or calling the scaffolder API directly. Define who may approve each template and how their decisions are recorded.
One identity per user for template permissions
Template permissions depend on knowing which person is acting. The Backstage authentication documentation advises configuring sign-in resolvers so every sign-in provider resolves to the same user identity, and not offering guest access in production. If a user can sign in through two providers that map to two identities, their group memberships and template rights can differ from what the approver expects. Test each provider and confirm guest access is disabled before go-live.
Full model in security hardening
The controls above are one part of template governance. The complete model, covering permission policies, service-to-service authentication, proxy and integration token scope, scaffolder action limits and timely security upgrades, is covered in the Backstage security hardening topic. Use this section as a checklist for templates and that topic for the wider platform design.
How to test a golden path template and confirm it fails safely
Testing a golden path template means proving two things before developers use it: a successful run produces exactly what the form promised, and a failed run leaves nothing behind. Start by running the template against a sandbox organization and a throwaway cloud account, never against the accounts that hold production workloads. Use a test name for every parameter combination you plan to support, then check each output against the input. The repository should exist with the expected name, visibility, default branch and branch protection. The pipeline run should start and pass on the first commit. The catalog entry should carry the owner, lifecycle, system and tags you entered, and it should appear in the catalog after the ingestion cycle completes. Record what you checked so the same list can be rerun after every change.
Next, test the paths where things go wrong. Submit invalid input for each field that has validation rules, including empty values, names that break naming conventions, and owners that do not exist in your identity provider. Confirm the form rejects them before any action runs. Then force a failure partway through: for example, make the cloud provisioning step fail after the repository has been created. Inspect the sandbox organization and the throwaway account afterward for orphaned repositories, stray infrastructure, leftover secrets, or catalog entries pointing at nothing. Whether a failed step cleans up depends on how your custom scaffolder actions were written, so confirm the behavior in your own environment rather than assuming the framework handles it. Any resource a failed run leaves behind is a defect to fix before promotion.
Test authorization as a separate exercise. Sign in as a user who is not in the group allowed to run the template and confirm the template is hidden or refused, and that a direct request to start the task is also refused. Repeat with a user from the owning team and a user from an unrelated team. Because sign-in resolvers and group ingestion decide who holds which identity, verify that the group membership you test with matches what your identity provider reports. If your portal still allows guest access in a test instance, note that the authorization results may not reflect a production setup. Keep these results with the template's change record, since reviewers will ask how access was verified.
Check that a template change does not break components created from the previous version. Generate a component from the current template, apply the edited template to a second sandbox run, and compare what each version produces for the pipeline, the catalog file and the dependency manifests. Pay attention to renamed files, changed pipeline steps and new required parameters, because existing repositories often depend on them. Where a change is breaking, decide whether to version the template or to ship a migration path for existing components, and document the decision before merging.
Finally, run the upgrade check. After any Backstage version bump, rerun every template in a non-production instance before promoting the upgrade. Backstage moves its @backstage packages together with yarn backstage-cli versions:bump, and the Upgrade Helper shows what changed in the templates and configuration between versions. Rerun the full test list, not only the templates you changed, because scaffolder and plugin changes can affect templates you did not touch. Confirm the Node.js version your instance runs is one the Backstage versioning policy supports before you start. Treat any template that fails to create its outputs, or any component that no longer matches the catalog, as a blocker for promotion, and keep the test results with the release record.
What drives the effort of a template program
This table compares the main drivers of effort in a Backstage template program, how each one raises the work, and how to keep it contained. Read each row as a scope question to settle before a fixed-scope quote is written. The main takeaway is that the number of golden paths matters less than how many systems each path touches and how many teams must adopt it.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Number of golden paths | Each template needs its own skeleton, form schema, parameter validation, tests and owner review. Paths that look similar often diverge in small ways that multiply maintenance. | Start with the one or two paths that cover most new services. Build shared skeleton fragments and parameter definitions that several templates reuse. |
| Source control targets | Each host (GitHub, GitLab, Bitbucket or Azure DevOps) needs its own publish action, token scope, branch protection defaults and repository settings. Multiple hosts multiply this work. | Standardize on one source control host for templates at launch. Add others only when a team with a real need is committed to using them. |
| CI and pipeline targets | Each pipeline system needs generated configuration, secrets wiring and a tested first run. Changes to pipeline standards must be reflected in every template that generates them. | Generate pipeline files from a single shared template module. Limit the first release to one CI system and document how others are added later. |
| Cloud accounts and provisioning APIs | Infrastructure actions call cloud or provisioning APIs with credentials, quotas, naming rules and error handling that differ per account. Each account adds permission testing and failure paths. | Confirm which accounts and API versions are in scope. Use least-privilege service identities per target and a single account for the first template. |
| Custom scaffolder actions | Actions not shipped with Backstage must be written, typed, tested and kept compatible across Backstage upgrades. Each custom action also needs input validation and error reporting. | Reuse built-in actions wherever they fit. Count custom actions during scoping and ask the vendor to list each one with its inputs and outputs. |
| Compliance requirements on created resources | Created repositories and infrastructure may need mandatory branch rules, tagging, encryption settings, logging, approvals or evidence capture. Each control must be built into the template and verified in generated output. | Agree the control list with the compliance owner before design. Map each control to one template step, and reuse the same control modules across templates. |
| Number of environments | Each environment (for example development, staging and production) may need separate parameters, accounts, approval steps and test runs. The matrix of combinations grows with each one. | Limit templates to the environments that users must select. Keep environment differences in configuration files, not in duplicated template logic. |
| Teams that must adopt the templates | Each team brings different naming conventions, ownership rules and exceptions. Training, documentation, catalog ownership and feedback cycles grow with every team onboarded. | Pilot with one friendly team, collect defects, then expand in waves. Assign a named template owner and a review process for change requests. |
| Review steps and governance | Approval steps, template ownership, versioning and deprecation rules need design and ongoing operation. Without them, template changes reach users unreviewed. | Define the review path and template versioning rules in the first phase. Ask whether the Backstage catalog will track template owners and deprecation status. |
Questions teams ask before building templates or hiring help
How much effort does a first Backstage golden path take?
The effort depends mostly on the decisions around the template, not on the scaffolder syntax itself. The main drivers are: the number of components the template creates (repository, pipeline, deployment target, cloud resources, catalog registration), how many internal standards must be encoded as checks or defaults, how many approval or review steps the workflow needs, and how many systems expose APIs the template can call. A template for one service type with a single target environment is far smaller than one that covers several languages and runtimes. Agreeing on one service pattern before any build starts usually shortens the work more than any technical choice. Ask any provider to break the estimate down by component so you can see which items you could remove or defer.
Can our internal team build Backstage templates without outside help?
Yes, if the team already has engineers who are comfortable with TypeScript, Node.js and the Backstage plugin model, and who can run the portal in their own environment. Backstage is released under the Apache License 2.0, so there is no license fee, but the cost is staff time and the skills to maintain what they build. The harder part is often not the first template but the second and third: keeping actions consistent, testing them against real provisioning APIs, and upgrading them with each release line. Before deciding, check whether two or more engineers can own the templates long term, whether someone can review workflow changes, and whether your platform team has time reserved for this work alongside everyday operations.
What does our team need to provide before a templates engagement starts?
Most of the client input is access and decisions, not code. You should expect to name owners for the portal, for each template and for the provisioning APIs the templates call. The work also needs sandbox accounts in each cloud or platform that the templates will provision into, plus read and write access to the source control and CI systems involved. Provisioning APIs need documentation and credentials scoped for testing. The most important item is a governance decision: who approves new templates, who can change shared actions, how exceptions are granted and how templates are retired. Without these decisions, the build often stops at review, because nobody has the authority to accept the output.
Do custom scaffolder actions make Backstage upgrades harder?
They can, because custom actions depend on the Backstage packages and on the scaffolder API, and both can change between releases. Backstage ships a main release line monthly and a next line weekly, and it moves all @backstage packages together with the yarn backstage-cli versions:bump command. The Backstage Upgrade Helper shows template changes between versions, which helps you see what your code must follow. To keep upgrades manageable, keep actions thin and focused, put business logic in tested modules outside the action, pin the client libraries for each provisioning API, and add tests that run the templates end to end in a sandbox after each upgrade. Ask whether the scope includes that test suite.
Should we set up the Backstage software catalog before software templates?
In most cases, yes. Templates create new components, and those components only become useful when they are registered in the Software Catalog with an owner, a system and links to documentation and pipelines. A template that creates a repository without a catalog entry leaves ownership unclear and makes later reporting harder. The catalog is a core built-in feature, so a minimal model (components, systems, owners and a few annotations) can be set up quickly and then extended. Some teams build one narrow template alongside the catalog model, but both need agreed naming and ownership rules first. Ask your provider how the template will register new components and who maintains the catalog data after handover.
What should a fixed-scope quote for Backstage templates include?
A fixed-scope quote should list what will be delivered, in enough detail that you can check it against your requirements. Look for the number and type of templates, the custom actions each one needs, the external systems it touches, the environments it targets, the review and approval steps, and the governance process to be documented. It should also state the testing approach, the documentation handed over, the client responsibilities such as named owners and sandbox access, the acceptance criteria and the items excluded from scope. Change control matters: the quote should explain how new requests are priced and approved during the work. Finally, separate one-time build work from any ongoing support or upgrade retainer. DeployOpen does not publish prices, so the written scope is the basis for any quote.
What recurring work follows a Backstage golden path after handover?
The recurring work is mostly upkeep, not new features. Expect hosting for the portal and any runners that execute templates, the time to review and approve new template versions, and updates to custom actions when Backstage release lines or provisioning APIs change. Security fixes need to be applied promptly, and the Backstage versioning policy says high and critical severity vulnerabilities are backported to releases from the last six months where feasible, so your upgrade plan should follow that window. Someone also needs to keep the catalog data and template owners accurate as teams change. Ask any provider whether an upgrade or support retainer is included or optional, and what it covers beyond the build.
How DeployOpen works on this
DeployOpen plans, builds and documents Backstage software templates and golden paths inside your own infrastructure, using the open-source Backstage framework under its Apache-2.0 license. Each engagement starts from a written, fixed scope so your platform team knows exactly which templates, actions and approval steps will be delivered.
How we scope
- We agree in writing which golden paths, templates and scaffolder actions are in scope before any build work starts.
- We list the target repositories, pipelines, cloud accounts and infrastructure modules each template will create or configure.
- We confirm which review steps, approvals and template ownership rules your governance model requires, and record them in the scope.
How we build
- We build templates against your catalog model so every generated component is registered with an owner and the correct metadata.
- We implement custom scaffolder actions where built-in actions fall short, and test each one in a non-production Backstage instance.
- We run each template end to end against sandbox accounts and document the failure modes we find, including partial creation and rollback.
How we hand over
- We deliver the template source, action code, configuration and a runbook your platform team can operate without us.
- We walk your engineers through creating, modifying and retiring templates, and through the governance process for changes.
- We document the upgrade implications of each custom action so future Backstage version bumps stay manageable for your team.
How we support
- Ongoing support, upgrades and continuous testing of templates are available as a retainer, scoped separately from the build.
- Retainer scope should be confirmed in writing, including how template changes are tested after each monthly Backstage release.
- Ask for a quote built from the written scope, which will list each deliverable and the support hours or services it includes.
