<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[Tuft Mesh Vault]]></title>
  <link>https://tuftmeshvault.com/</link>
  <description><![CDATA[Tuft Mesh Vault is a self-hosted service-mesh platform with a transparent routing kernel, mTLS by default, and a declarative policy engine. No vendor lock-in.]]></description>
  <language>en</language>
  <atom:link href="https://tuftmeshvault.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[Running a service mesh without Kubernetes]]></title>
    <link>https://tuftmeshvault.com/notes/service-mesh-without-kubernetes.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/service-mesh-without-kubernetes.html</guid>
    <description><![CDATA[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.]]></description>
    <pubDate>Sun, 02 Aug 2026 19:43:18 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[How zero-downtime certificate rotation actually works]]></title>
    <link>https://tuftmeshvault.com/notes/mtls-certificate-rotation-zero-downtime.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/mtls-certificate-rotation-zero-downtime.html</guid>
    <description><![CDATA[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.]]></description>
    <pubDate>Thu, 16 Jul 2026 14:13:54 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Using the policy engine dry-run mode before you commit]]></title>
    <link>https://tuftmeshvault.com/notes/policy-engine-dry-run-mode-explained.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/policy-engine-dry-run-mode-explained.html</guid>
    <description><![CDATA[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.]]></description>
    <pubDate>Sun, 28 Jun 2026 15:32:31 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[What Prometheus metrics a service mesh should expose]]></title>
    <link>https://tuftmeshvault.com/notes/prometheus-metrics-service-mesh.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/prometheus-metrics-service-mesh.html</guid>
    <description><![CDATA[A service mesh sits in the path of every service-to-service call in your system. That position makes it a natural place to collect observability data. But 'expose Prometheus metrics' covers a wide range. A mesh can expose dozens of counters that tell you very little, or a small set of metrics that answer the questions you actually have at 2 a.m. This article covers the metrics that matter and why.]]></description>
    <pubDate>Fri, 29 May 2026 15:51:59 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[SPIFFE workload identity: what it is and why it matters]]></title>
    <link>https://tuftmeshvault.com/notes/spiffe-workload-identity-explained.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/spiffe-workload-identity-explained.html</guid>
    <description><![CDATA[SPIFFE stands for Secure Production Identity Framework for Everyone. The name is a mouthful, but the core idea is simple: instead of authenticating a service by its IP address or hostname, you authenticate it by a cryptographically verifiable identity document that is tied to the workload itself. This article explains what that means in practice.]]></description>
    <pubDate>Fri, 24 Apr 2026 07:33:40 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Migrating off Istio: what to plan for]]></title>
    <link>https://tuftmeshvault.com/notes/migrating-from-istio-to-self-hosted-mesh.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/migrating-from-istio-to-self-hosted-mesh.html</guid>
    <description><![CDATA[Istio is the most widely deployed service mesh, and it is also the one teams most often want to leave. The reasons vary: control plane complexity, resource overhead, upgrade friction, or simply the desire to understand what is actually running in their infrastructure. Whatever the reason, the migration is tractable if you plan the steps in the right order.]]></description>
    <pubDate>Sun, 08 Mar 2026 14:21:24 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Getting Tuft Mesh Vault audit logs into your SIEM]]></title>
    <link>https://tuftmeshvault.com/notes/audit-log-siem-integration.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/audit-log-siem-integration.html</guid>
    <description><![CDATA[The audit log is one of the more useful outputs of a service mesh, and also one of the more commonly ignored ones until a security team asks for it. Tuft Mesh Vault writes a structured JSON event for every policy change, certificate rotation, and routing update. Getting those events into a SIEM is straightforward, but the right approach depends on what your SIEM ingestion pipeline looks like.]]></description>
    <pubDate>Thu, 19 Feb 2026 09:44:21 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Why Tuft Mesh Vault is written in Go]]></title>
    <link>https://tuftmeshvault.com/notes/go-service-mesh-design-decisions.html</link>
    <guid isPermaLink="true">https://tuftmeshvault.com/notes/go-service-mesh-design-decisions.html</guid>
    <description><![CDATA[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.]]></description>
    <pubDate>Wed, 28 Jan 2026 11:24:23 GMT</pubDate>
  </item>
</channel>
</rss>
