Tuft Mesh Vault is a self-hosted service-mesh platform that gives operators full access to the routing kernel, the policy engine, and the certificate store. No vendor lock-in, no black-box abstractions.
Full platform, self-hosted, Apache 2.0. Access to the public GitHub issue tracker and the community forum. No seat limits, no feature gates, no expiry. This is the same binary that Standard Support and Enterprise customers run.
Adds a private support queue with a two-business-day SLA, early access to patch releases before public announcement, and a quarterly architecture review call. Billed monthly, cancel any time.
Custom SLA, dedicated Slack channel, assisted migration from your current mesh vendor, and a signed data-processing agreement for regulated workloads. Pricing is based on node count and contract length. Contact us to get a number.
Martin Cottrell built the first version of Tuft Mesh Vault in the second half of 2019, working evenings after a day job that involved debugging a commercial service mesh whose control plane was, in his words, 'a YAML graveyard with a dashboard bolted on.' The specific problem was a certificate rotation bug that took four days to diagnose because the vendor's internal state was not observable. He wrote a 200-line routing kernel over a long weekend to prove the concept was tractable, and kept going.
Every packet decision is logged and queryable. You can inspect the full routing table at runtime without restarting any sidecar.
Certificates are issued by an embedded SPIFFE-compatible CA. Rotation happens on a configurable interval. Default 24 hours. With zero downtime.
Write access policies in a declarative YAML dialect, run them in dry-run against live traffic snapshots before committing. No surprises on deploy.
All internal counters expose a /metrics endpoint out of the box. No proprietary agent, no extra scrape config beyond what you already have.
The control plane, the data plane agent, and the CLI ship as one statically linked binary. Runs on Linux x86_64 and arm64. No container runtime required.
Most service-mesh documentation starts with a Kubernetes cluster. The install guide assumes kubectl, the architecture diagrams show pods, and the troubleshooting section references CRDs. If you are running workloads on bare metal or plain Linux VMs, you are left to reverse-engineer what the Kubernetes-specific parts actually do and figure out the equivalent yourself. This article covers the practical differences.
Read the full article →Certificate rotation sounds straightforward until you think about what happens to in-flight connections during the switchover. A connection established with the old certificate is still open. The peer has validated the old certificate. If you revoke the old certificate the moment the new one is issued, that connection breaks. Zero-downtime rotation requires a period where both certificates are simultaneously valid. An overlap window. And some mechanism to ensure the new certificate has reached all peers before the old one expires.
Read the full article →The most common way teams break production with a service mesh is by applying an access policy that is subtly wrong. A rule that denies traffic it should allow, or allows traffic it should deny. The error is usually obvious in retrospect, but by the time it is obvious, something is down. Dry-run mode exists to catch these errors before they reach production.
Read the full article →Answer three questions about your infrastructure and support needs. The result points you to the right starting point. No sales call required.
Martin Cottrell spent eight years building distributed systems at a mid-size payments processor before leaving to write Tuft Mesh Vault's first routing kernel in 2019. Before that he shipped a service-mesh observability layer for a logistics SaaS that handled roughly 40,000 daily API calls across three data centres. He started Tuft Mesh Vault because he kept running into the same wall: vendors who abstracted away the control plane and called it a feature. He runs the project from a home office, reviews every pull request personally, and reads network-engineering RFCs on Saturday mornings. He is not a morning person, but the RFCs help.