<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Case Studies on BareProxy.com</title>
    <link>https://bareproxy.com/tags/case-studies/</link>
    <description>Recent content in Case Studies on BareProxy.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 31 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://bareproxy.com/tags/case-studies/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BareProxy Drift Watcher Catches a DNS Move That Went Wrong</title>
      <link>https://bareproxy.com/bareproxy-drift-watcher-catches-a-dns-move-that-went-wrong/</link>
      <pubDate>Sat, 31 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bareproxy.com/bareproxy-drift-watcher-catches-a-dns-move-that-went-wrong/</guid>
      <description>&lt;p&gt;Moving a domain to a new DNS host is one of those jobs that looks done when the website loads. The nameservers changed, the A record is right, the page comes up. A week later someone notices that half the mail is bouncing because one MX record didn&amp;rsquo;t make it across, or that certificate renewals fail because the new zone has a CAA record naming the wrong CA.&lt;/p&gt;&#xA;&lt;p&gt;This case walks a small set of domains through exactly that kind of move and runs the &lt;a href=&#34;https://bareproxy.com/bareproxy-adds-a-drift-watcher-for-dns-records-and-tls-certificates/&#34;&gt;drift watcher&lt;/a&gt; before, during and after. It used the released 0.16.0 binary for Linux.&lt;/p&gt;</description>
    </item>
    <item>
      <title>BareProxy Killed in the Middle of Webhook Deliveries and No Event Was Lost</title>
      <link>https://bareproxy.com/bareproxy-killed-in-the-middle-of-webhook-deliveries-and-no-event-was-lost/</link>
      <pubDate>Sat, 31 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bareproxy.com/bareproxy-killed-in-the-middle-of-webhook-deliveries-and-no-event-was-lost/</guid>
      <description>&lt;p&gt;The worst moment for a webhook relay to die is after it has sent an event to the app and before the app has answered. The app may have charged the card or shipped the order. The relay can&amp;rsquo;t know. If it sends the event again, the app might do the work twice. If it doesn&amp;rsquo;t, the event might be lost.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://bareproxy.com/bareproxy-adds-a-webhook-inbox-that-keeps-every-event-until-the-app-takes-it/&#34;&gt;inbox&lt;/a&gt; handles this by marking every attempt on disk before it starts. This case kills BareProxy with SIGKILL in exactly that window and looks at what happens next. It ran on the released 0.16.0 binary for Linux, on 127.0.0.1, with Stripe-format webhooks signed by a test secret made for the run.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Duplicate Webhooks and a Bad Deploy Replayed With the BareProxy Inbox</title>
      <link>https://bareproxy.com/duplicate-webhooks-and-a-bad-deploy-replayed-with-the-bareproxy-inbox/</link>
      <pubDate>Sat, 31 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bareproxy.com/duplicate-webhooks-and-a-bad-deploy-replayed-with-the-bareproxy-inbox/</guid>
      <description>&lt;p&gt;Two things go wrong with webhooks that have nothing to do with the app being down. Senders send the same event more than once, on purpose, because they can&amp;rsquo;t tell whether you got it. And sometimes the app is up and answering, but answering wrong, because the last deploy broke the handler.&lt;/p&gt;&#xA;&lt;p&gt;This case runs both through the &lt;a href=&#34;https://bareproxy.com/bareproxy-adds-a-webhook-inbox-that-keeps-every-event-until-the-app-takes-it/&#34;&gt;inbox&lt;/a&gt;, after a quick check of what it does with forged signatures. It used the released 0.16.0 binary for Linux, on 127.0.0.1. The webhooks follow the real GitHub, Shopify and Stripe formats, each signed with a test secret made for the run.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How the BareProxy Inbox Kept Webhooks Through a One Minute App Deploy</title>
      <link>https://bareproxy.com/how-the-bareproxy-inbox-kept-webhooks-through-a-one-minute-app-deploy/</link>
      <pubDate>Sat, 31 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bareproxy.com/how-the-bareproxy-inbox-kept-webhooks-through-a-one-minute-app-deploy/</guid>
      <description>&lt;p&gt;Most webhook losses happen during deploys. The old process stops, the new one takes a minute to come up, and whatever Stripe or GitHub sent in that minute gets an error. The sender retries a few times on its own schedule and then gives up.&lt;/p&gt;&#xA;&lt;p&gt;This case puts the &lt;a href=&#34;https://bareproxy.com/bareproxy-adds-a-webhook-inbox-that-keeps-every-event-until-the-app-takes-it/&#34;&gt;webhook inbox&lt;/a&gt; between three senders and an app, stops the app for about a minute and keeps sending. It ran on the released BareProxy 0.16.0 binary for Linux. The app and the senders are small Python scripts on 127.0.0.1. The webhooks use the real formats and signatures of GitHub, Stripe and Shopify, signed with secrets made fresh for the run, and none of those services was contacted.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
