Templates

A template is a ready-made app KamalCloud can install: an image, the environment it wants, and the secrets to generate. Installing one makes an ordinary app – it deploys, rolls back, backs up and is managed exactly like one you wrote.

Templates ship with KamalCloud rather than with your account, so there is nothing to create or edit. There is a catalogue, and installing from it.

Installing one

Templates → pick one → Install. You are asked for a name, a runner, an environment name and branch, a server, a domain, and whatever that template declares it needs – sometimes an admin address.

KamalCloud then:

1. Creates the app and an environment. With no domain given and a server with an IP, the environment gets a generated sslip.io hostname
2. Sets the template’s fixed variables and generates the secrets it declares – session keys, admin passwords
3. Registers its volumes for backup, marking the ones whose container has to stand down to be archived
4. Seeds any raw ports the image publishes
5. Creates the accessories and scheduled tasks the template declares

Installing does not deploy. The app page says “installed. Deploy it to bring it up” – press Set up and deploy on the environment when you are ready.

There is no repository. In place of a checkout, KamalCloud renders a config/deploy.yml and a Dockerfile into the working directory on the runner, then writes the usual destination config and secrets file on top, as it does for any app.

The catalogue

Each template has a guide covering install, first sign-in, backups and upgrades:

Template	What it is	Guide
Directus	headless CMS and data API on SQLite	Directus
Vaultwarden	password manager for Bitwarden clients	Vaultwarden
Stalwart	mail, calendar and contacts server	Stalwart
WordPress	site builder and blog, on MySQL	WordPress
Runwell	agency project management, client portal	Runwell

Addresses

Many images bake their own public URL into their data on first boot: discovery documents, OAuth metadata, absolute links in mail. A template that does this declares it, and the environment is blocked until an address is set – deploying without one and fixing it later means fixing it in the data, not in the config.

In practice the block rarely shows: install gives the environment a generated sslip.io domain whenever its server has an IP. That hostname is what the image will bake in, so if you want a domain of your own, set it before the first deploy rather than after.

Notes

Each template carries notes, and they are worth reading before the first boot rather than after. They cover the things the image’s own documentation assumes you know: where a bootstrap password is printed, which listener needs a certificate of its own, which ports the provider blocks by default, how to recover a locked-out administrator.

Singletons

Some templates are marked as singletons, because two containers would fight over the same data or the same ports. For those, KamalCloud sets Kamal’s drain_timeout to 0, so the old container goes before the new one boots rather than overlapping with it.

The trade is deliberate: a few seconds of downtime on every deploy, instead of two processes writing to one SQLite file during a rollover.

Every template here is a singleton except WordPress, and the exception shows the rule – WordPress keeps its data in a MySQL accessory rather than in a file in its own volume, so a second container has nothing to fight over and the rollover can overlap as usual.

After installing

It is an ordinary app. Add domains, set variables, schedule backups, redeploy when you change something. Upgrading means changing the image tag and deploying again.

Editing a template-installed app does not fork anything – there is nothing tracking the template afterwards. What you deploy is the app as it stands.