Skip to content

Running Tavrik on your own VM

Tavrik runs on one virtual machine inside your data centre. This page is the shape of that deployment, for the engineer deciding whether it fits. The step-by-step build is a separate operational document your team receives during onboarding.

Where Tavrik runs Tavrik runs in one of three shapes: a dedicated single-tenant instance in your region, an on-premises virtual machine in your data centre, or your own Kubernetes cluster. It is the same product with the same policy and the same audit trail in each. Where Tavrik runs Tavrik Pty Ltd, trading as Tavrik AI © 2026 Tavrik Pty Ltd, trading as Tavrik AI. All rights reserved. Dedicated cloud Single-tenant instance in your region Operated by Tavrik, owned by you Fastest start for a pilot 01 On-premises VM One virtual machine in your data centre Your team operates it from the runbook Nothing leaves your network 02 Your Kubernetes Helm chart into your existing cluster Fits your platform team's tooling Same chart used in our CI every day 03 Same product. Same policy. Same audit trail. Inside your network in every shape, with no inbound path from the internet.

Three shapes, one product

Section titled “Three shapes, one product”

The same software runs three ways. There is no feature difference between them; the difference is who operates the host.

  • Dedicated cloud, single-tenant, in your region. We operate it.
  • On-premises VM, in your data centre. You operate it. This page.
  • Kubernetes, using the published Helm chart, if you already run a cluster.

What runs on the VM

Section titled “What runs on the VM”
The on-premises VM One virtual machine in the hospital's data centre runs the whole product: a reverse proxy that terminates TLS, the console, the admin API, the gateway, and a local Postgres database. Secrets and the release-signing public key live on the host. A daily timer takes backups (02:30 UTC). The VM makes outbound connections to the models you allow and to your audit systems; nothing initiates a connection in from the internet. The on-premises VM Tavrik Pty Ltd, trading as Tavrik AI © 2026 Tavrik Pty Ltd, trading as Tavrik AI. All rights reserved. YOUR DATA CENTRE · ONE VIRTUAL MACHINE Reverse proxy 443 and 80 from your LAN TLS ends here Console What operators use Talks only to the admin API Admin API Tenants, policy, keys, audit views Role-checked, all actions logged Gateway The data plane: every AI request Tokenise, policy, route, restore Postgres Local to the VM. Three app roles Audit chain, config, key ciphertext Secrets and keys Root-owned, service user reads Release key: public half published Backups Daily timer, all tables Fails loudly if the DB is down Outbound only Models you allow, local or cloud Your integration engine Your FHIR store and SIEM No inbound connection is ever initiated from outside
Component What it does Reachable from
TLS edge Terminates TLS, proxies to the services behind it Your LAN, on 443 and 80
Gateway The data plane: every AI request, tokenised, policy-checked, routed The TLS edge, on /v1/*
Admin API Tenants, keys, policy, audit reads The console, in-host only
Console The operator web interface The TLS edge
Postgres Audit chain, configuration, key ciphertext The three services, in-host only

Only 443 and 80 are meant to be reachable from outside the host, plus SSH for administration. Everything else binds to loopback.

The gateway makes outbound connections to the model providers you allow and to your own audit systems. Nothing initiates a connection inward.

What you need to provide

Section titled “What you need to provide”
  • A Linux VM. Four cores and 8 GB of memory is comfortable for a pilot.
  • A DNS name and a certificate, or outbound access for the edge to obtain one.
  • An identity provider speaking OIDC or SAML, if you want operators to sign in with your own accounts rather than API keys.
  • Outbound HTTPS to whichever model providers you allow, or none at all, if you run a local model, in which case nothing leaves the building.

Data, backups and upgrades

Section titled “Data, backups and upgrades”

The database holds the audit chain, your configuration, and provider key ciphertext. A daily timer backs up every table and fails loudly if the database is unreachable, so a silent backup failure is not one of the ways this goes wrong.

Upgrades replace the binaries and the console from one build, keeping the previous copies in place so a rollback is a restart rather than a rebuild. The database migration runs as a separate, explicit step; the services refuse to start against a schema they do not recognise.

Assurance roadmap

Section titled “Assurance roadmap”

Customer-held keys. On this shape the key-encryption key that wraps your provider API keys is managed by Tavrik today. Holding that key in your own key-management service is available now on the dedicated cloud shape, and on-premises support is next. The security posture page dates the rest.