Treat the template like a product. In CI, generate a sample service from it, build and test that service, scan it, and check the result against your own policy. If any step fails, the template does not release.
Why templates need tests
A template's mistakes copy themselves. A broken lockfile, an out of date base image or a CI step that never actually runs will appear in every new repository. The Backstage documentation notes that templates are sets of steps with inputs, and that each step can fail with its own logs. That makes templates executable things, which means they can be tested like code.
What to check
| Check | What it proves |
|---|---|
| Generate with default inputs | The template runs end to end |
| Generate with edge inputs | Names, optional features and odd values do not break it |
| Build the sample service | Dependencies resolve and the project compiles |
| Run the sample's tests | The starter tests pass |
| Scan the sample | The template does not ship known vulnerable dependencies |
| Policy check | Required files exist: lockfile, update config, CI workflow |
| Image scan | The base image is current and clean enough for your policy |
Steps
- Add a CI job to the template repository that runs the generator with fixed inputs.
- Commit nothing from the output. Build it in a temporary directory.
- Run the same scan and gate that real services will run.
- Write a small script that asserts required files and settings are present in the output.
- Run the job on a schedule too, not only on changes. Dependencies age, and a template that passed last month can fail today.
- Fail loudly and notify the platform team channel.
Step 5 is the one people skip. A template untouched for three months is the most likely to ship stale defaults.
Test the guardrails, not only the happy path
Create a negative sample on purpose. Add a known bad dependency or remove the lockfile, then confirm the gate blocks it. A control you never saw fail may not be wired up.
Release like software
Version the template, write a short changelog, and say which existing services are affected. Be clear that a template change does not alter repositories that already exist; see whether a repository template update reaches existing repos.
Who owns it
The platform team owns the template and its tests. Security reviews the policy checks. App teams may contribute through pull requests; see how other teams can contribute safely.
Where Safeguard fits
Safeguard's dependency scanning, SBOM generation and policy gates can run against the generated sample in your template CI, using the same rules your real services use. The CLI is on the download page, and a free scan is at gold.safeguard.sh/scan.
Try it yourself
Open the demo and watch a gate fail a change, then ask whether your template CI would show the same failure on a deliberately bad sample.
Click through it at your own pace, or open it full screen.
Quick check
Should the sample service be committed?
No. Generate it fresh in CI each run so you test the template, not an old copy.
Why run template tests on a schedule?
Dependencies and base images age. A scheduled run catches stale defaults before a team inherits them.
Sources
Last reviewed: 19 October 2026.
