Docs Build and deploy

Templates

A template adds one or more ready-made services to an environment, wired together with variable references, volumes and domains, and deploys them. For many apps, Dawnrose also finishes the app’s first-run setup, so you can sign in as soon as it is live.

Deploy a template

On the canvas, click Create, choose Template and pick one from the Template gallery. Databases are also under Create → Database.
On the Projects page, click a template under Popular templates to deploy it in a new project.
Agents call list_templates and deploy_template.
In the CLI, dawn add --template list lists templates and dawn add --template n8n deploys one.

If a service with the same name already exists in the environment, the new one gets a suffix such as Postgres-2, and the template’s references are updated to match. Template volumes share what is left of your plan’s volume storage, up to 5 GB each.

The catalog

Template ids are in parentheses. Services listed after “with” are deployed alongside the app.

Databases

PostgreSQL (postgres), MySQL (mysql), MariaDB (mariadb), Redis (redis) and MongoDB (mongo). See Databases.
Qdrant (qdrant): vector database for embeddings and semantic search, protected by an API key.

CMS

WordPress (wordpress), with MySQL.
Ghost (ghost), with MySQL.
Directus (directus): headless CMS and data API, with Postgres.

Automation

n8n (n8n): workflow automation, with Postgres.
Activepieces (activepieces): no-code automations, with Postgres and Redis.

Analytics

Umami (umami): web analytics, with Postgres.
Metabase (metabase): business intelligence dashboards, with Postgres as its app database.

AI

Open WebUI (open-webui): chat for any OpenAI-compatible model. Sign-up is turned off; add a model connection in its settings.
LiteLLM (litellm): one OpenAI-compatible API in front of many model providers, with Postgres.
Flowise (flowise): build LLM agents and chatflows visually, with Postgres.

Developer tools

Uptime Kuma (uptime-kuma): uptime monitoring and status pages.
Drizzle Studio (drizzle-studio): the self-hosted Drizzle Gateway with a Postgres database, to browse, query and edit tables in the browser. Sign in with the generated MASTERPASS. To browse another database, add its connection URL in the studio; use the private DATABASE_URL when the database is in the same environment.
Meilisearch (meilisearch): search engine with a master key in MEILI_MASTER_KEY.
PocketBase (pocketbase): database, auth, file storage and realtime in one service.
Sandbox (sandbox): a Linux machine for running commands. See Sandboxes.

Storage

Bucket (bucket): S3-compatible storage with a ready bucket. See Buckets.

Other

Listmonk (listmonk): newsletters and mailing lists, with Postgres. Bring your own SMTP server to send; mail submission ports are open on Pro.
Vaultwarden (vaultwarden): password manager server for the Bitwarden apps. Sign-up is turned off; people are invited from its admin panel.

Every template except Sandbox and the five databases gets a public domain. Postgres, MySQL, MariaDB, Redis and MongoDB stay private, with no domain and no TCP proxy, until you turn the proxy on. Some app secrets, such as encryption keys, are created as sealed variables.

First-run setup

Most self-hosted apps start with a setup wizard. For template apps, Dawnrose completes it over the private network after the first healthy deploy, then signs in with the new account to check that it works. The Deployments tab shows the progress, then Ready to sign in with the login, the password and an Open app link.

The credentials are ordinary variables of the app’s service, so you and your agent can read them in the Variables tab:

ADMIN_EMAIL: the email of the person who deployed the template.
ADMIN_USER: admin, for apps that sign in with a user name (WordPress, Umami, Uptime Kuma, LiteLLM, Listmonk).
ADMIN_PASSWORD: a generated password.

App	What setup does
WordPress	Runs the installer with the admin user.
Ghost	Creates the owner account.
Directus	Directus creates the admin from the variables on first start; Dawnrose checks the sign-in.
n8n	Creates the owner account and an API key, saved in `N8N_API_KEY`.
Activepieces	Creates the first account, which becomes the platform admin.
Umami	Replaces the default admin password with `ADMIN_PASSWORD`.
Metabase	Creates the admin and connects the other Postgres, MySQL and MariaDB databases in the environment as data sources.
Open WebUI	Checks the admin account the app creates on first start, or creates it.
LiteLLM	Checks the UI sign-in and that `LITELLM_MASTER_KEY` works as an API key.
Flowise	Creates the owner account.
Uptime Kuma	Creates the admin user.
PocketBase	Checks the superuser; the dashboard is at `/_/`.
Listmonk	Checks the admin sign-in and sets the root URL to the app’s public URL. Add your SMTP server under Settings → SMTP in Listmonk.
Vaultwarden	Signs in to the admin panel at `/admin` (the token is `ADMIN_PASSWORD`) and invites `ADMIN_EMAIL`. Open the app, create an account with that email and choose your master password.
Qdrant	No account; checks that the API key in `QDRANT__SERVICE__API_KEY` works. The dashboard is at `/dashboard`.
Bucket	No account; creates the bucket and checks the keys.

Setup retries for a while as the app boots. If it still fails, the Deployments tab says so and it is tried again on the next deploy. If the app already had an account, setup leaves it alone and reports that. Every outcome is recorded in the activity log.

Agents can use the n8n API key to build and activate workflows through n8n’s API. Connections that need your own accounts, such as Gmail or Slack, must be authorized by you inside n8n.

Deploy a docker-compose stack

If a repository has a compose file that builds its own code, Dawnrose can deploy every service in it as one stack, with the databases replaced by Dawnrose databases and the connections wired up. This needs GitHub connected.

The Projects page lists your recently pushed repositories that have a stack under Ready to deploy from your GitHub. Click Deploy stack to deploy one in a new project.
When you create your first project from a repository, the setup screen offers Deploy the whole stack.
Agents call detect_stack to see what would be deployed and deploy_stack to deploy it.

How the compose file is read

Dawnrose reads the first of compose.yaml, compose.yml, docker-compose.yaml and docker-compose.yml at the repository root. It counts as a stack only if at least one service builds code from the repository and there are at least two services in total.

Services with build: deploy from the repository, using the build context as the root directory and the given Dockerfile.
Postgres (and PostGIS, TimescaleDB), MySQL, MariaDB, Redis (and Valkey) and MongoDB images become Dawnrose databases from the templates. They are created first.
Other images deploy as image services. An image from ghcr.io/<owner>/<repo> for a repository you can access on GitHub deploys from that repository’s default branch instead.
The first port in ports or expose becomes the service’s port, and a named volume becomes the service’s volume.
Environment values that point at a database, such as a connection URL or a host name, become references like ${{ db.DATABASE_URL }}. Credentials shared with a database container become references to the database’s own variables.
${VAR:-default} becomes the default. ${VAR} without a default comes from your local .env, so Dawnrose lists it under variables to set after deploying.
SQL files mounted into a database’s /docker-entrypoint-initdb.d are applied after the app’s first deploy. See Automatic schema setup.

Left out, with the reason shown in the preview: services that only run with a profile, local development tools (such as Adminer, pgAdmin, phpMyAdmin, Mailpit and Mongo Express), services that build from outside the repository, and images that need files from the repository mounted in.

Deploying fails if a service with the same name already exists in the environment, so deploy a stack into a new project or environment.