Self-hosting Notavia: Docker Compose, Helm, and what the signed licence means
Run Notavia on your own infrastructure with Docker Compose or Helm, connect your own providers, and own your data. Here is how the self-hosted deployment works.
Notavia is available as a fully managed cloud service, and that is the right choice for most teams. But some products operate in environments where cloud dependencies are not acceptable — regulated industries, air-gapped infrastructure, or teams with a firm policy of owning every component in the stack.
For those teams, Notavia supports self-hosted deployment via Docker Compose and Helm.
What you get with self-hosting
A self-hosted Notavia installation runs the same software as the managed service. The API is identical. The SDK points to your own endpoint instead of ours. The console runs on your infrastructure. Delivery records, templates, and audit logs live in your database.
You connect your own notification providers: your own SMTP relay for email, your own Twilio or Vonage credentials for SMS, your own Teams or Discord webhook for chat. Notavia handles the routing, rendering, deduplication, and retry logic. Your providers handle the last mile.
Docker Compose for development and small production workloads
The Docker Compose deployment is the fastest way to get a self-hosted Notavia instance running. Pull the Compose file, configure the environment variables for your database and provider credentials, and start the stack.
docker compose -f notify.compose.yml up -d
The Compose file includes the Notavia API server, the worker process that handles async dispatch, and a PostgreSQL database. If you already have a managed Postgres instance you prefer, point the DATABASE_URL at it and remove the database service from the Compose file.
The Compose deployment is well-suited to development environments and small production workloads. For higher availability requirements, the Helm chart is the right path.
Helm for Kubernetes deployments
The Helm chart deploys Notavia to a Kubernetes cluster with configurable replica counts, resource limits, horizontal pod autoscaling, and ingress configuration. The chart is designed for standard Kubernetes distributions and has been tested on the major managed Kubernetes providers.
helm install notify oci://registry.saas-infrastructure.com/charts/notify \
--values notify-values.yaml
The values file covers provider credentials, licence key, database connection, and scaling parameters. Detailed documentation for each parameter is in the chart's values.yaml with inline descriptions.
The signed licence
Self-hosted Notavia requires a signed licence key. The licence is validated offline — Notavia does not phone home on every request. The validation happens at startup, and the licence file is re-checked periodically to detect expiry.
The licence key is issued when you subscribe to a self-hosted plan. It encodes the deployment limits (number of workspaces, maximum monthly send volume) and the expiry date. When the licence expires, Notavia enters a grace period and continues operating while issuing warnings; after the grace period, new sends are rejected until a renewed licence is applied.
This design means you can run Notavia in an air-gapped environment with no outbound network access to our infrastructure. The licence validation is cryptographic and local.
Bring your own providers; no lock-in
Because you supply your own provider credentials, there is no Notavia-specific vendor lock-in at the delivery layer. If you want to switch your email provider, you update the SMTP configuration. Your templates, delivery history, and recipient preferences stay in your database.
The Notavia data model is documented and exportable. Delivery records, templates, and recipient preferences are standard relational data. You can export and migrate it at any time.
When to use self-hosted vs managed
Self-hosting adds operational responsibility: you manage the infrastructure, apply updates, handle backups, and respond to incidents in the Notavia layer. On the managed service those operational duties are ours; what we commit to in writing is set out in the Terms and, for Enterprise and OEM customers, in the order form or SLA.
For most teams, managed is the right choice. Self-hosted makes sense when you have a compliance requirement that prohibits third-party data processors, an existing Kubernetes infrastructure that makes running another service straightforward, or a business reason to own the full stack.
Both options use the same API and SDKs, so your integration code does not change. Moving your data between them is a real migration, and we have not yet rehearsed one end to end — talk to us before you plan on it.