Recipes
Recipes are end-to-end walkthroughs for deploying common applications on Kovra Cloud. Each recipe gives you a working sample Dockerfile and kovra.yaml, a step-by-step deploy walkthrough, and a list of gotchas the customers before you hit.
Recipes assume you already have:
- A Kovra Cloud organization in
readystatus - A GitHub or GitLab integration connected at Settings → Integrations
- Enough storage and database quota on your plan for the recipe’s footprint (each recipe lists its prerequisites up front)
Available recipes
| Recipe | What you get | Plan requirements |
|---|---|---|
| WordPress on Kovra Cloud | A self-hosted WordPress site backed by managed MariaDB and a 10 GiB persistent volume | Any plan that allows 1 stateful app + 1 MariaDB + 10 GiB storage (Developer plan and above) |
More recipes (Ghost, Mattermost, n8n, Plausible, Metabase) are on the roadmap. If you want one prioritized, reach out at hello@kovra.dev.
How recipes work
Kovra Cloud has two primitives that recipes lean on:
- Stateful Kovra Cloud Apps — declare
volumes:in yourkovra.yamland the platform provisions aStatefulSetwith onegp3(RWO, single-AZ EBS) PersistentVolume per declared volume. See the recipe’skovra.yamlfor the exact shape. - Managed databases — provision PostgreSQL, MariaDB, MongoDB, or Redis from the Databases page; copy the discrete connection-detail fields from the database’s detail page and paste them into your app’s variables.
Apps and databases have independent lifecycles: deleting an app does not delete its database, and deleting a database does not strip env vars from any app that referenced it. The coupling is by the env vars you paste — that is intentional, mirrors Heroku/Render/Railway, and lets you bind one database to multiple apps without magic.
Bringing your own setup
Every recipe is a customer-owned Git repository. Kovra does not publish template repos, fork-on-create scaffolds, or maintain a Docker base image for you. The Dockerfile and kovra.yaml in each recipe are starting points — you commit them to your own repository, push, and own the upgrade path.
Why? Hosting a starter image creates a long-tail support burden (security CVEs, PHP version EOLs, plugin conflicts) and locks your stack to whatever defaults we picked at the time. Owning the Dockerfile means you own the upgrade — FROM php:8.4-apache is a one-line change you control.