Architecture

One file in, a running site out

What Infraspawn decides on your behalf, what it puts on your machines, and what you can check before any of it happens.

How Infraspawn worksOne manifest file describes a site. The control plane decides placement, allocates subnets, addresses and ports, issues a key and certificates per machine, and produces the recipes each machine runs. Underneath it all is an encrypted mesh network. The machines themselves sit in two different buildings, each running the same bridge and message broker, and in a cloud account that collects from both. The telemetry service in the cloud names the broker in each building without ever naming its address. Documentation is written from the same model as the setup.WHAT YOU DESCRIBEWHAT INFRASPAWN WORKS OUTWHAT COMES WITH ITsite-114.yamlnetwork: site-114nodes:building-01, building-02, cloudservices:broker→ both buildingsbridge→ both buildingstelemetry→ cloudno addresses, no certificatesThe control planePlacementwhat runs where, and in what orderAllocationsubnets, addresses, ports, namesIdentity and TLSa key per machine, certificatesRecipeswhat each machine has to doDocumentationWritten from the same model asthe setup itself, not a seconddocument kept in step by hand.Export it as a PDF for ahandover, an audit, or a customer.a key per machine, and its recipesEncrypted mesh networkmachines reach each other behind NAT and firewalls · direct when it works, relayed when it does not · you choose where traffic meetsYOUR MACHINES, WHERE THEY ALREADY AREBuilding 114your property, behind a routerbuilding-01100.67.4.11bacnet-bridgemosquitto · brokerReads the building system andpublishes the meters on the broker.Building 220another property, another routerbuilding-02100.67.4.12bacnet-bridgemosquitto · brokerThe same two services, from the samefile. A second site is not a project.Cloud accountyour own VPCcloud100.67.4.13mqtt2influx · telemetryinfluxdbcaddy · ingresstelemetry in the cloud names the broker in each building, never an address

The middle box

What the control plane settles

The file names a network, some machines, and the services across them. It contains no address, no certificate, and no firewall rule, because those are the parts that differ at every site and are therefore the parts worth working out rather than writing down.

Placement

Which machine each service runs on, and in what order they start. A service that depends on another does not come up before the thing it needs is there.

Allocation

The subnet, the addresses, the ports, and the names. These are worked out from the topology rather than typed into a file, so two sites cannot collide and a third does not need a spreadsheet of what was used where.

Identity and TLS

A key for each machine and no other, and certificates for the names it answers to. The key belongs to the machine you created in Infraspawn, not to whoever has the installer.

Recipes

What each machine actually has to do, fetched by the agent on that machine. Nothing needs to reach into the site to push a change in.

The band underneath

The network is part of it, not a prerequisite

Most deployment tools begin once the network already exists. You bring the VPN, the addresses and the firewall rules, and they run containers on top. That is the half of the job that turns each new site into a project.

Machines reach each other wherever they are: behind a router in a basement, on a mobile connection, inside a cloud account. Infraspawn makes the connection itself and relays the traffic when a direct one is not possible. Nobody forwards a port, buys a static address, or keeps a list of what lives where.

Every machine on a network is one you created there first, and the key you get back belongs to that machine and no other. A network is never left open for machines to ask their way in, so it holds what you put in it and nothing else. Machines on different networks cannot reach each other at all, which is why keeping one customer apart from another is a question of which network you created the machine on rather than a firewall rule somebody has to write, review and keep correct.

Traffic meets at a point you pick: one for your account, and a different one for a network that needs it. You can look up which one later. Running that meeting point on your own servers is on the roadmap for enterprise customers.

Who issues the certificates underneath all of this, where the private keys are held, and what each credential is worth to somebody who takes one is on the security page.

At the site

What actually lands on a machine

The figure shows one customer's site: two buildings running the same pair of services, and a cloud account collecting from both. The second building is there because it is the case that decides whether any of this is worth having.

A machine in a building has no fixed address and sits behind equipment you do not control. A machine in a cloud account has neither problem and a different set of expectations about how it is managed. The same file covers both, and the second building is the first one again with a different node name, because nothing in it was worked out by hand the first time round. One site is an afternoon either way. Ten sites is where the difference lives.

A service says what it needs, and Infraspawn finds it: the actual instance, on the actual machine, with the address, the credentials and the tokens it generated. In the figure, the telemetry service in the cloud names the broker in each building and never an address. Move a broker to another machine and everything pointing at it follows. No service needs a public address or an open port to be reached by the services that depend on it.

Nothing in the figure is specific to buildings. The same shape covers work that has to stay on the customer’s own hardware for a different reason: a model server on the machine with the hardware for it, next to the data it reads, with the data never leaving the site. Whether that machine can give a container access to its GPU is detected on the machine itself, and when it cannot, the deployment says so and runs on CPU rather than failing with something unreadable.

Before you trust it

What you can check yourself

Everything here is either in the figure above or one command away.

A dry run before anything changes

Applying with --dry-run returns the plan and changes nothing: what would be created, what would be updated, and on which machine. A pipeline can stop on it, and a person can read it first.

Structured output from every command

Every command takes --format=json. Ids, addresses, ports and deployment state come back ready for a program to read, so nothing has to be scraped out of printed text.

Applying twice is safe

A second apply changes only what is missing or out of date. The file is the desired state, not a script of steps that must not be run again.

Networks can have a deadline

Create a network with a time limit and it has one. At expiry the services are removed from the machines, and the network itself goes a while later, which leaves a machine that was offline time to come back and clean up after itself.

A whole environment, then nothing left behind

A temporary network for a test run, a review environment, or a customer demo, with the cleanup already scheduled the moment it is created.

$ isc net create ci-7f3c acme.inc --ttl=90m --format=json$ isc node create $NETWORK_ID runner-1 --format=json$ isc manifest apply stack.yaml --dry-run --format=json$ isc manifest apply stack.yaml --format=json# no teardown step: the network expires on its own

Bring us a site that is giving you trouble

Tell us what you deploy, where it has to run, and how many machines you look after, and we will get a network standing on them.

Request AccessRead the FAQ