Use templates

Start from something that already deploys — what the bundled templates give you, and what to check before you build on one.

A template is a working project that already deploys: a Dockerfile that builds, a handbook, and enough structure that your first deploy is about your idea rather than about packaging.

$dibbla template list
$dibbla template list -v
 
# installs into ./my-app (refuses if it exists; --force reuses)
$dibbla template install getting-started my-app

Before you build on one

Templates are starting points, not audited foundations. Two minutes now:

• Deal with .env, in two places. The install writes a live DIBBLA_API_TOKEN there. .dockerignore keeps it out of the image — worth adding, because no template lists it and a Dockerfile that does COPY . . would bake the credential into a distributable layer. But .dockerignore does not control what is uploaded: the deploy filter is a fixed list in the CLI and never reads it, so .env is sent with your project regardless. The file that governs the upload, and the managed repository, is .dibblaignore. Put .env in both.
• Write the handbook — it is not there. No template ships docs/index.md, and only expense-reporter ships a handbook at all (as APP.md). Either filename satisfies the platform, and docs/index.md wins if you have both. The subtitle: in its frontmatter is what colleagues read in the catalogue, and the deploy is refused without it.

Under the hood

dibbla template install is sugar over dibbla run against the template’s bootstrap file: it makes a directory and executes a dibbla-task.yaml from a published URL. Which is worth knowing for one reason —

Writing your own

A template is a repository with a dibbla-task.yaml that scaffolds it. If your team starts the same kind of service repeatedly — same base image, same handbook shape, same guardrails review — that is the thing worth templating, because it is the part everyone skips when starting from an empty directory.