former engineer @cisco, now building @firezonehq.
Mountain View, CA
Joined July 2009
- Tweets413
- Following360
- Followers199
- Likes11.7K
Wrote up a very large refactoring task for Fable to handle, then went to the gym for a couple hours.
Came back to find that it opened a giant stack of 43 PRs.
Aaaandd it already looks like we need to RMA some RAM. Always use ECC memory kids!
v2 of the @firezonehq bare metal testbed is nearing completion.
We already have both cloud and CI testbeds for performance, so why have another? Simple - bare metal exposes the hardware metrics necessary to optimize Firezone further.
The new testbed consists of:
- One Intel server and one AMD server with speedy Mellanox network cards
- Two Macs directly connected via Thunderbolt Ethernet
- Two Chromebooks
- Two laptops
- Various Apple and Android phones
The goal for this testbed is to set some new throughput records for VPNs on commodity hardware.
Stay tuned!
There's a new version of this post
Flaws were disclosed in refrigeration controllers by Team82 months ago in research noting that *thousands* of vulnerable web interfaces were publicly exposed.
These controllers are commonly used in places like - you guessed it - supermarkets.
claroty.com/team82/research/…
We avoided using SCIM for directory sync, and you can too! (I believe in you)
Employee terminated? Role changed? See how Firezone handles these events within seconds, not hours or days.
firezone.dev/blog/building-r…
I guess it's time to add Starlink to our QA testbed
Learn how Beaver Excavating uses Firezone to connect construction sites to central HQ... over Starlink!
youtube.com/watch?v=o7Z0dqtH…
Super sad @pulley is shutting down. Have been a happy customer for nearly 5 years now.
Welp officially on the search for alternatives now.
There seems to be some new autoscrolling logic when viewing GitHub PRs.
Wrestling with the page's scroll state is a battle I haven't fought since... 2004?
Other elixir devs:
What are you doing about dead code?
Private functions warn when nothing calls them, but public functions do not.
How are you finding (and removing) old code that's no longer reachable?
Device Trust prevents unauthorized devices from connecting to your org's resources with a stolen auth token.
Setup in a nutshell:
1. Add your CA cert(s) to your Firezone account.
2. Provision matching X.509 client certs to your devices.
3. Enable the "Require attestation" policy condition.
That's it.
The Firezone client then connects over mTLS using the client certificate you've provisioned, cryptographically tying the device's identity to its auth session.
When building Device Trust, we settled on the following three design decisions:
1. Don't reinvent the wheel - organizations already have PKI infrastructure they're using to provision certs. Integrate as tightly with existing PKI stacks instead.
2. Support *all* platforms from day one - yes, even Linux is supported!
3. Available on all plans - we consider strong device identity to be a core feature for a ZTNA product.
Enjoy!
Your network is only as secure as the devices connecting to it.
So let's raise the bar.
Today we're shipping Device Trust in Firezone: Lock down access to only the devices your organization trusts.
Available now on every plan!
See how to set it up: firezone.dev/device-trust
There's a new version of this post
Had a little debate at @firezonehq regarding how to enforce the shape and contents of the new REST API.
Turns out a custom Elixir Protocol is the perfect tool for this.
We build a custom JSON encoder that ensures certain Ecto schema fields never make it onto the wire and others are mapped / computed before going out.
Jamil Bou Kheir retweeted
How to get your first Saas users in 2026:
1. Expose your product as an MCP server
2. Implement OAuth so it connects in one click
3. Submit to the Claude connector directory
Did this Saturday. 109 visitors, 41 signups, 13 paid trials by Sunday. $0 spent.
This is an optimization we've wanted to pursue for some time now. Excited to see it come to life.
tl;dr - replace STUN probes with WireGuard handshake initiations so you are half-way towards a usable connection once NAT traversal succeeds.
I think we're the first to do this?
You may have noticed Firezone connections getting a lot faster lately.
That’s connlib v2: the latest version of our in-house NAT traversal and connectivity engine, now shipping in all Firezone clients.
To achieve this we ripped out all the STUN/TURN/ICE protocol overhead, leaving nothing on the wire but WireGuard packets.
Never regretted time spent in the sauna. A few minutes of discomfort for 2+ hours of focused productivity immediately after.
What causes that?
Had some memory + CPU alarms fire recently. Turns out more and more folks are using the @firezonehq REST API and Caddy was quite the hog.
Ripped it out so it's just Elixir/Phoenix/Bandit all the way through now. Problem solved.
Apple systems programmers:
DON’T use unconnected UDP sockets for sustained traffic. XNU disables flow feedback for these, so you can't backpressure.
DO use connected UDP. XNU then enables flow advisories, so EVFILT_WRITE can tell you when to resume.
github.com/apple-oss-distrib…
Every time I build something using X.509 certs, I’m reminded just how much complexity is hiding in there. It’s no wonder entire industries have sprung up just to manage them.