A secure service template should ask just for what it cannot know, such as the service name, the owning team and where to publish, and decide everything with a safe default for the developer. Every extra question is a chance to pick a weaker option or abandon the road.
What template tools actually ask
Backstage Software Templates are a good example of the pattern. Per the Backstage documentation, a template can load skeletons of code, fill in variables, and publish the result to locations such as GitHub or GitLab. Each template can ask for different input variables, which are passed to the templater, and a template is generally a set of steps, each with its own required or optional inputs. Before running, a review page lets the user check the values.
In the example template in the docs, the form asks for a name, an owner chosen from a picker of groups, and a repository location with an allowed host list. Three questions, and the owner is selected from known groups rather than typed freely.
Ask or decide
Use this table as a starting point. The right split depends on your stack.
| Item | Ask or decide? | Reason |
|---|---|---|
| Service name | Ask | The template cannot guess it |
| Owning team | Ask, from a list | Ownership must be real and valid |
| Repository location | Ask, from allowed hosts | Prevents publishing to the wrong place |
| Language and framework | Ask, from supported choices | Selects the right variant |
| Pipeline with security checks | Decide | Not optional on the road |
| Base image | Decide, from an approved list | Keeps patching centralised |
| Branch protection and review rules | Decide | Safe defaults, applied at creation |
| Logging settings | Decide | Consistent and not leaking secrets |
| Visibility (public or private) | Ask, default private | A deliberate choice with a safe default |
| Data classification | Ask | Drives which policy tier applies |
Rules of thumb
- Prefer pickers to free text. Backstage's owner picker is a model: fewer typos and valid values.
- Default to the safest option. If a field is optional, the default should be the secure one.
- Keep the form short. Long forms tempt people to skip the template.
- Explain the question. A one line description saves a support message.
- Make unsafe choices explicit. If a developer picks public visibility, show a warning and record it.
Validate in the template
Do not rely on the developer to read a policy. Validate input values in the template itself, for example by restricting the allowed repository hosts, as the example does. Then back the template with checks in the pipeline, so a service that has drifted from the defaults is caught later.
Review what the template can do
A template runs actions on your behalf, such as creating repositories. Review it like code, restrict who can edit templates, and keep their steps minimal.
Where Safeguard fits
Safeguard's policies, gates and guardrails apply to the services a template creates, so the defaults you set are checked after creation too. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How many questions should a template ask?
As few as possible. Three to five is a reasonable target for a first version.
Should developers be able to turn off security checks in the form?
No. Offer a documented exception process instead, so the choice is visible and reviewed.
Sources
Last reviewed: 19 October 2026.
