Why Tuft Mesh Vault is written in Go
The choice of Go for Tuft Mesh Vault was not a default. Martin Cottrell had written production systems in Python, Java, and Rust before starting this project. Go won on a specific set of criteria that matter for a piece of infrastructure software that operators need to deploy, debug, and trust on their own hardware.
Static linking and the single-binary model
Go's default build output is a statically linked binary. No shared libraries, no runtime dependencies, no 'works on my machine' problems caused by a mismatched glibc version. You copy the binary to a host, mark it executable, and run it. This is the property that makes the single-binary install model work.
The alternative. Shipping a container image. Would have worked, but it adds a container runtime as a dependency and obscures what is actually running. A binary you can inspect with ldd (which returns nothing, because there are no dynamic dependencies) is easier to audit than a container image with a base layer you did not write.
The standard library's TLS stack
Go's crypto/tls package is well-maintained, has a reasonable API, and is audited regularly as part of the Go security release process. For a project where TLS is not a peripheral concern but the central mechanism, using a well-understood standard library implementation reduces the surface area for bugs.
The alternative was to use a C TLS library via cgo. That would have introduced a C dependency, complicated the static linking model, and added a build-time dependency on a C toolchain. The tradeoff was not worth it for the capabilities we needed.
Goroutines for the sidecar concurrency model
Each registered workload in the mesh has a corresponding goroutine in the control plane that manages its certificate lifecycle, health tracking, and policy evaluation. Goroutines are cheap enough that this one-goroutine-per-workload model scales to several thousand registered workloads on modest hardware without tuning. The alternative concurrency models. Thread pools, async event loops. Would have required more explicit state management for the same result.
The current control plane handles up to roughly 2,000 registered workloads on a single instance with 2 vCPUs and 2 GB of RAM, based on load testing. That covers most of the deployments we have seen in practice.
The codebase is on GitHub under the Apache 2.0 licence. If you are curious about a specific design decision that is not covered here, the commit history is annotated and the community forum has a 'design' tag for these discussions.