How it works

Follow one address through the system.

Most architecture pages describe a platform. This one follows a single DHCP lease from the moment a device picks up an address to the moment the name resolves, and names every part it passes through on the way. No acronyms without a translation.

Everything on this page is a path that runs in production today.

One lease, end to end.

Seven steps, about a second of real time. Step through them, or let it run.

1 Device gets an address 2 Lease intake signed message 3 Queue and workers 4 Math core subnet, reverse name 5 Both stores intent and reality 6 Your DNS zone updated 7 Reconciler checks it later same address, same answer, every time

  1. A device gets an address

    A laptop, a camera, a handset joins the network. Your DHCP server gives it an address, exactly as it does today.

  2. Your server tells OmniTwin

    The lease is posted to OmniTwin, signed with a key you control. No agent on the device, no polling loop waiting to notice.

  3. It queues instead of dropping

    The message lands in a queue drained by a pool of workers. A burst of leases is absorbed rather than lost.

  4. The math is computed once

    The compiled math core works out the subnet and the reverse name for that address. Deterministic: the same address always gives the same answer.

  5. Both stores are updated

    The DNS records are written to the intent store, and the address appears in the reality store, connected to the things around it and tagged to your tenant.

  6. Your DNS is updated

    The zone change is pushed out to the DNS providers you already use, so the name resolves where it always did.

  7. It is checked again later

    A reconciler sweeps reverse DNS in the background and repairs what drifted. If it could not finish the sweep, it says so rather than claiming a clean pass.

The parts, and how they connect.

Three columns: what you already run, what OmniTwin runs, and where the answers are kept. Moving lines are live data paths. Select any part to read what it does in one paragraph.

Your network OmniTwin control plane Where the answers live lease asks writes zone change request reads checks Your DHCP servers hand out addresses Your DNS providers wherever DNS lives today Your engineers and tools API and automation Lease intake signed, keys refreshed Queue and workers absorbs bursts Math core address arithmetic API and sign-in token checked first DNS manager lease becomes records Outbound sync pushes zone changes Reconciler sweeps reverse DNS Tenant scoping your rows only Intent store what should be true Reality store what is true, and how it connects

live data path where answers are kept drag sideways on a narrow screen

Your DHCP servers
These keep handing out addresses exactly as they do now. Each time one is handed out or given up, your server sends OmniTwin a short message saying so. Nothing is replaced and nothing is put in front of your DHCP.
Lease intake
The front door for those messages. Every message carries a key, and OmniTwin re-reads the list of valid keys every ten seconds, so a key you withdraw stops working in seconds rather than at the next restart.
Queue and workers
Messages go into a queue that a small pool of workers drains. This is the part that makes a busy morning boring: when a thousand devices come back at once, the work queues up and is worked through, instead of being dropped because something downstream was slow.
Math core
The address arithmetic runs in one compiled library: which subnet an address belongs to, whether two ranges overlap, and the reverse name an address maps to. It is deterministic, which is a long word for a simple promise. The same address gives the same answer every time, on every machine, whoever asks.
DNS manager
Turns a lease into the DNS records that should exist for it, and writes them down. This is where a fact about an address becomes a record you can look up.
Intent store
What the network is supposed to be: allocations, records, who owns what, which policy applies. It is a normal SQL database, so it backs up, restores, and audits the way your other databases do. Nothing exotic to operate.
Reality store
What is actually out there and how it is connected. Held as a graph because the useful questions are about relationships: what sits behind this address, what else is on this path, what else is affected if this goes away. Those questions are slow to answer with table joins and fast to answer with a graph.
Outbound sync
Pushes zone changes out to the DNS providers you already use. OmniTwin does not ask you to move your DNS to it, and it does not need a way in through your firewall to do this. It reaches out.
API and sign-in
Everything your engineers and scripts do arrives here. The token is checked before the request reaches any data, and the API streams results as they happen rather than making you wait for one big response at the end.
Tenant scoping
Every table that holds customer data is scoped to a tenant, and the scope is applied by the database itself rather than by whoever wrote the query. A query that forgets to filter still cannot see another tenant, because the rule does not depend on the query being careful.
Reconciler
Sweeps reverse DNS in the background and fixes what has fallen out of step. It reports a clean pass only when it actually finished one. A partial sweep is reported as partial, which sounds obvious until you have been misled by a tool that rounds up.
Your DNS providers
Wherever your DNS lives today. OmniTwin writes to it, so your resolvers, your registrars, and everything pointed at them carry on unchanged.

Why there are two stores.

One database would be simpler to draw and worse to live with. The two questions engineers actually ask have different shapes, so they are kept in the shape that answers them.

Intent store

What should be true

Allocations, records, ownership, policy. Rows and columns, ordinary SQL, ordinary backups. It answers counting and ownership questions.

"Which addresses in this subnet are still free, and who owns this range?"

Reality store

What is true, and how it connects

The live picture, held as a graph. It answers relationship questions, the ones that turn into slow joins in a table and into a short walk in a graph.

"What sits behind this address, and what else goes dark if this link does?"

The gap between the two is the signal worth acting on. When what should be true and what is true stop matching, that difference is drift, and it is the thing OmniTwin is built to surface. The architecture page goes into the engines underneath.

What keeps it honest.

Scoping the database enforces

Every table holding customer data is scoped to a tenant by the database itself. A query that forgets to filter still returns nothing from another tenant, because the rule does not rely on the query being careful.

Keys that can be withdrawn

The keys your DHCP servers sign with are re-read every ten seconds. Withdraw one and it stops working in seconds, without a restart or a deploy.

Arithmetic that cannot disagree

Address maths runs in one compiled library, never in the browser. Two engineers looking at the same subnet see the same numbers, because only one thing computed them.

A sweep that admits a partial pass

The reconciler reports a clean pass only when it finished one. Half a sweep is reported as half a sweep. Quiet rounding up is how teams end up trusting a stale picture.

Outbound only

Updates are pushed out to your DNS. Nothing needs a hole through your firewall to reach in, which is usually the first question a security review asks.

Your DNS and DHCP stay yours

OmniTwin sits alongside what you run rather than in front of it. If it stops, addresses are still handed out and names still resolve.

Want to see it on your own network?

The beta runs against your DHCP and your DNS, read-only until you say otherwise.

Join the beta Talk to an engineer