Architecture

Five diagrams of how gkm works. Each is a Figma frame exported at full width — click any of them to zoom.

The source is one Figma file, gkm Architecture, where every shape is a component: a database is a cylinder, a container has window chrome, a bucket is a vessel, a site is a browser window. Changing a shape once changes it in all five.

What a construct becomes

A declaration on the left. The manifest — ids, kinds, and the edges between them — in the middle. On the right, what a target builds from it.

The boxes are labelled with the hostnames you would actually visit. The physical names underneath them are derived from the construct id and the stage, and that rule has its own page.

A surface is a server

Api and Auth are both rest-api declarations. What separates them is the endpoint knowing which surface it belongs to — which is what an endpoint created from its surface gives you.

Where does this construct live?

A target-aware default, a per-concern override, and — not built yet — a per-construct one. A construct falls through until something answers, and the answer is always one of the same three backend names.

Same client, different address

Locally Caddy is the edge because nothing else is. On Dokploy, Traefik already is one. The client is identical; the scheme in the injected URL picks the driver.

One kind, three answers

Where a kind resolves to nothing on a target, that is marked rather than hidden.