Template configuration
What goes into a template at a field level: services, Git apps, databases, Docker, variables, and deploy behaviour.
Use this page when you author templates, work with support, or need exact rules (name lengths, variable keys, which Git hosts count). Everyday deploy steps are in Deploy a template.
Template record (what the catalogue stores)
| Item | Purpose |
|---|---|
| Name | Required. At least 3 characters when creating or renaming. |
| Description | Short text on cards and in listings. |
| Icon image | Optional picture on the card. |
| Deployed preview image | Optional screenshot, often for marketplace listings. |
| Services | The list of apps, databases, and Docker services (see below). |
| Long description | Rich text for published listings (labeled Template Overview in the publish form); must meet the minimum length when you Publish. |
| Category | Optional group for the marketplace. |
| Kind | Personal (yours), Community (shared listing), or Official (dFlow catalogue). |
Every service (common parts)
| Item | Notes |
|---|---|
| Type | App (Git), Database, or Docker. |
| Name | Required. Used in URLs, app naming on the server, and placeholders like {{ name.KEY }}. If that name is already taken elsewhere on the platform, deploy may add a short suffix. |
| Description | Optional note in the designer. |
| Info link | Optional URL to docs for people deploying the template. |
| Variables | Environment variables. Keys: start with a letter or underscore; then letters, numbers, or underscores only. Sensitive values are stored protected in the product. |
| Volumes | Host folder and container folder pairs for persistent data. Special storage paths may be rewritten if the service name changes on deploy. |
| Builder | For App and Docker: how the image is built. Options in the product include Build packs (default), Railpack, Nixpacks, Dockerfile, Heroku build packs, and Static build. |
App services (Git)
Pick one Git host per app: GitHub, GitLab, Bitbucket, Azure DevOps, or Gitea. Typical fields include repository, owner (where needed), branch, build path (often the repo root), port, and optional access token. Linking your organisation’s Git integration is safer than pasting tokens when you can.
Deploy rule: If the Git host is missing or not one of the five above, that app line is dropped when someone deploys, and they see a skip warning. Database and Docker lines are not dropped for this reason.
Database services
Engines you can pick: PostgreSQL, MongoDB, MySQL, MariaDB, Redis, ClickHouse. You can list exposed ports when the template expects public database ports.
Docker services
Image URL, optional registry account from your integrations, and optional port mappings (host port, container port, http or https).
Variables that point at other services
You can use placeholders so one service picks up another’s values:
- Single reference:
{{ database_service_name.DATABASE_URL }}(use your actual service name and variable key). Service names in references may include letters, numbers, underscores, or hyphens (for example{{ my-api.DATABASE_URL }}); variable keys use letters, numbers, and underscores only. - Several references in one value: combine text and multiple
{{ ... }}blocks; deploy updates names inside them if services get renamed.
Some advanced templates use generated secret patterns; the product recognises those where supported.
Order in the designer vs order when things go live
Reordering in the designer helps people read the template. When deploy runs, databases are still started before apps and Docker services so dependencies behave as expected.
Default sizing on deploy
Deploy from template asks the platform to apply sensible minimum CPU and memory for new apps when it can. That step might log a problem without stopping the whole deploy.