Sep 2026 · 5 min read

Security, Architecture

Local-first security pipelines that do not phone home

The most underrated property in security tooling is that it should work when the network is off. This post is about building that way, on purpose.

Why local-first

  • Air-gapped environments cannot call the cloud. A tool that needs permission is a tool that does not run.
  • Breach response happens at 2 AM. A pipeline that depends on an API being up during an incident is a bad pipeline.
  • Data sovereignty is not a checkbox. Some vulnerability data should not leave the building.

Design rules I use

  1. Sync at most once a day, store the full dataset locally.
  2. Never require an account to run the core query path.
  3. Make the default config work with zero network access after first sync.
  4. Export in open formats (JSON, SARIF) so the tool fits into any pipeline.

The tradeoff

Local-first means the user owns staleness. You must surface "data last synced" loudly and make re-sync one command. When you do that, local-first stops feeling like a limitation and starts feeling like control.

VulnScanner is my reference implementation for these rules.

The soul becomes dyed with the color of its thoughts.

Marcus Aurelius

Made with <3 and lots of coffee.