Templates overview
What templates are, the three catalogue tabs, and how browse, deploy, create, and publish fit together in dFlow.
Templates are reusable blueprints for a whole stack. One template can include several Services together, for example a web app from Git, a database, and a container image. You choose a template, tell dFlow which Application and Environment should receive it, and the platform creates those Services for you. After that, everything behaves like services you added yourself: deployments, logs, domains, and backups.
Why templates matter
- Less repetition: Define a stack once, deploy it many times with consistent defaults.
- Shared standards: Teams can start from the same baseline for demos, staging, and new products.
- Discovery: Official and Community templates help you try stacks dFlow or other users have already shaped.
What you can do in the dashboard
| Goal | Where to go |
|---|---|
| See what is available | Templates (tabs below) |
| Deploy a stack | Deploy on a card, or Deploy from template in the navigation |
| Design your own blueprint | Create template |
| Share a blueprint more widely | Publish on a Personal template (see Publish a template) |
The public website may also highlight templates in a marketplace view; your organisation dashboard is where you manage and deploy your own copies.
The three tabs in Templates
| Tab | In practice |
|---|---|
| Official | Curated starting points from dFlow. |
| Community | Templates people chose to share. Read each description before you deploy. |
| Personal | Your organisation’s templates only (drafts, internal standards, or things you might publish). |
New templates you author start as Personal. Publish can list them under Community for others to find.
During deploy: what changes, what does not
On Deploy from template, the Configure step lets you adjust names and variables for that run only. It does not change the saved template in your library. To change the blueprint for everyone next time, edit the template in Create template (or unpublish, edit, and publish again if it is shared).
After deploy
A template is not a separate runtime. You manage the resulting Application, Environment, and Services like any other workload. dFlow starts dependent pieces in a sensible order (for example databases before apps when needed). If something fails, check service logs and Template troubleshooting.
If something looks wrong or actions fail
Templates permissions in Roles and permissions mainly cover Personal templates: listing that tab, Create template, editing, deleting, and Publish / unpublish. If the Personal tab shows an access message instead of your templates, you likely need Templates → Read (and Create / Update / Delete for the matching actions).
Official and Community catalogues do not use that same check for loading the list, so those tabs can still show templates even when Personal is restricted.
Deploy from a card or the deploy wizard is enforced with application, environment, service, and server permissions—for example applications.create when you create a new application, environments.create and services.create when the stack is provisioned, and servers.read to pick compute—not the Templates row alone. If deploy fails or a step is blocked, an admin should confirm those areas in Roles and permissions.
Template authors who need field names, limits, and edge cases can use Template configuration alongside Create template and Deploy a template.
Next steps
- Use your first template (guided first run)
- Browse templates
- Deploy a template
- Create a template
- Publish a template