Overview

web.guardyn.dev sits in front of your origin and does the work a CDN does — authoritative DNS, TLS termination, caching, a firewall, load balancing — with one difference that shapes everything else: it can tell you why it did what it did, for any individual request.

Two planes, and why they never share a database call

The control plane is where you make changes. It owns Postgres, validates what you ask for, and turns the current state of the world into a configuration snapshot. The data plane is what serves traffic. It holds exactly one snapshot in memory and answers every request from it.

The snapshot is immutable, zstd-compressed, content-addressed with blake3, and signed with Ed25519. A node verifies the signature over the bytes it received — never over a re-serialisation of them — so a snapshot that survives the check is byte-identical to the one the control plane signed.

There is no partial apply

Every change you make is a draft until you publish it. gdn plan shows a real diff against what is live; gdn apply activates exactly one new version; gdn rollback activates the previous one. A node is either serving version 41 or version 42. No request is ever served by a mixture of two configurations, and there is no window in which half your rules are the new ones.

$ gdn plan
  ~ amthalgroup.com
     ! rules      3 → 4 rules in the custom phase
       settings   trace sampling 1.00% → 100.00%

1 change. Lines marked ! can interrupt traffic.

$ gdn apply -m "block wordpress scanners"
✓ applied v4 — 1 zone(s)
  edge nodes pick it up on their next poll

One account, shared with guardyn.dev

This is not single sign-on between two products. It is one account: the same public.users row, the same workspace, the same role, the same bill. guardyn.dev owns the public schema; this product owns edge, and there are deliberately no foreign keys between them so the two can migrate independently.

Where to start

Everything