Our cloud, your cloud, or your own hardware.
Where the system runs is a deployment setting, not a sales negotiation. The same build ships to all three, so nothing is held back for the version you cannot have.
Three targets·Same build everywhere·Documented exit
Three targets, one build.
The property that matters is the last one: there is no self-hosted edition missing features, and no cloud-only capability used to make on-premises uncomfortable.
Where it runs
Chosen by you, changeable later.
Managed cloud
We run it, patch it, back it up, and monitor it, in a region you choose.
Your cloud tenancy
Deployed into your own AWS, Azure, or GCP account, so the data and the bill sit with you.
Your own hardware
On-premises, including air-gapped, for the environments where that is the requirement rather than the preference.
Movable
The target is not a one-way door. Moving between them is a migration we have a documented procedure for.
Residency and isolation
Where the data physically is, and who else is on it.
Region pinning
Data and backups stay in the region you choose, including for inference where a model is involved.
Single tenant available
A dedicated database and application instance where shared infrastructure is not acceptable.
Sub-processors published
A current list of who else touches your data, with notice before it changes.
No cross-region failover surprise
Where high availability spans regions, that is stated and agreed rather than discovered in a diagram.
Running it
The operational properties, whoever is operating it.
Backups with tested restore
Point-in-time recovery, and a restore that has actually been exercised rather than merely configured.
Staged upgrades
Sandbox first, then production, on your schedule. An upgrade is not applied to you on a Tuesday without warning.
Environments
Sandbox, staging, and production from the same build, so what you test is what ships.
Monitoring and logs
Health, performance, and error telemetry available to you, not only to us.
Documented runbooks
For the customers running it themselves, the same procedures we use, rather than a support contract standing in for documentation.
Leaving
Written down at the start rather than negotiated at the end.
Full export at any time
Every record and every attachment, in an open, documented format — not a proprietary archive readable only by us.
The schema is documented
An export is useful because you can read it. A dump you cannot interpret is not an exit.
Open source underneath
The platform is GPL-licensed upstream, so continuing without us is a real option rather than a rhetorical one.
Your custom apps are yours
In your repository from the first commit, under a licence that does not depend on the relationship continuing.
From a decision to a running environment.
The same four steps regardless of target, which is what makes the choice reversible rather than a commitment made at the worst possible moment.
- 01
Choose
Target, region, and whether the instance is shared or dedicated. All three are recorded rather than assumed.
- 02
Provision
The environment is built from the same infrastructure definition we use everywhere, not hand-assembled.
- 03
Verify
Restore is tested, monitoring is connected, and access is checked against your identity provider before anything real lands.
- 04
Operate
Upgrades staged through sandbox on your schedule, with the rollback path tested rather than described.
The specification.
The rows an infrastructure review will want filled in.
- Targets
- Managed cloud, your cloud tenancy, or your hardware
- Air-gapped
- Supported for on-premises deployments
- Tenancy
- Shared or fully dedicated instance
- Residency
- Region-pinned data, backups, and inference
- Backups
- Point-in-time recovery with exercised restores
- Environments
- Sandbox, staging, production from one build
- Upgrades
- Staged, scheduled by you, with a tested rollback
- Exit
- Full open-format export, documented schema, any time
The trade-offs we will not hide.
Self-hosting is a real option here, and it has real costs. Both halves of that sentence matter.
- Self-hosting is work
- Patching, backups, restore testing, and monitoring become yours. We will document all of it and we will not pretend it is free.
- Air-gapped means manual updates
- No outbound connection means no automatic patching, and a media-based update procedure. That is the deal, and it is the right deal for some environments.
- Some integrations need egress
- Bank feeds and e-invoicing need to reach the internet. In a genuinely air-gapped deployment those become file-based, and that is slower.
- Region choice affects latency
- Pinning to a distant region for residency reasons has a performance cost. We would rather quantify it than let you discover it.
Next step