push.tt / Enterprise
Partly shipping

Run the whole thing on your own hardware

Some organisations cannot put voice on somebody else's servers, whatever the encryption. push.tt is built to be deployed as ordinary software on an ordinary Linux box — which is most of the way to a self-hosted product, and honestly short of all of it.

Partly shipping. The software already installs and runs entirely on your own machine with no cloud services involved — that part is real and in use. What does not exist yet is the product around it: no licence for self-hosting, no support agreement, no update channel and no installer aimed at your staff rather than ours. Talk to us before planning around it.

Why this is even possible

It was not designed for on-premise as a feature. It is possible because of decisions taken for other reasons, and those decisions happen to leave nothing cloud-shaped in the stack at all.

  • Plain Ubuntu, systemd and nginx. No cloud provider API, no metadata service, no managed database
  • SQLite on local disk and media on the local filesystem — the entire state is one directory
  • Fonts are self-hosted, so a running instance makes no third-party request. Not even a font CDN sees your users
  • The whole production deployment is provisioning script plus rsync, which is why moving it is a copy rather than a migration

What that gets you

For an organisation with a data-residency rule or an air-gapped network, the meaningful property is that there is nothing to phone home to.

  • Voice never leaves your network; the relay is your machine
  • The org escrow key for the Message Vault is generated in your admin's browser and stored on your server
  • You keep the audit trail, the retention archive and the database — there is no copy anywhere else

What is missing, and it is not small

The gap between "the software runs on your box" and "you can buy this" is real, and it is the part we have not built.

  • No self-host licence. There is no agreement that permits it and no pricing for it
  • No support model. Nobody is on the hook if your instance goes down at 3am
  • No update channel. Upgrades today are our deploy process, not something you can run
  • No hardening guide or installer written for somebody who is not us
  • Push notifications and the eSIM store need outbound internet, so a genuinely air-gapped instance loses both

If you need this, say so — it moves up the list based on who is actually asking. What we will not do is take an order for it today and work out the rest afterwards.

The honest alternative

For most organisations asking about on-premise, the actual requirement is "our provider must not be able to read this". That one is already met, today, without any of the above.

  • Private and org channels are encrypted on member devices; our servers relay ciphertext they cannot read
  • White label puts your name and colours on it while we run the infrastructure
  • If the requirement is genuinely residency or air-gap rather than confidentiality, that is when this page matters

Tell us what the requirement actually is

Residency, air-gap, procurement policy or a security review — the answer differs for each, and for some of them we already have one.