Deploy your software wherever it has to run, without rebuilding the infrastructure around it every time.
Infraspawn connects your machines, deploys what you already run, wires those services to each other, secures the traffic between them, and writes the documentation. It is built for machines you cannot walk over to: inside buildings, on factory floors, on remote installations, and in the cloud accounts behind them.
Private pilots in PropTech and industryEncrypted networking includedBring your own services
The problem
Every new site turns into a new project
Your software barely changes from one site to the next. The work around it does: switches and firewalls to configure, a VPN to commission, address space to allocate and then remember, certificates, credentials moved by hand between configurations, and the details that only ever existed in the head of whoever was on site that week. Do that once and it is a project. Do it thirty times and it is a department.
Today
Configure switches and firewalls, then commission a VPN
With Infraspawn
Machines join one encrypted mesh that comes with the product
Today
Allocate address space, and keep an inventory of what runs where
With Infraspawn
Services find each other by name, wherever they are running
Today
Issue certificates, and distribute credentials by hand
With Infraspawn
Both are generated and delivered between services
Today
Produce as-built documentation, then watch it drift
With Infraspawn
Documentation is written from what is actually deployed
Today
Send an engineer, because this site is not like the last one
With Infraspawn
The file is the only thing that differs between two sites
How it works
Describe it once, apply it at every site
Three steps, and only the first one changes between one site and the next.
Step one
Describe the site
One file names the network, the machines on it, and every service across all of them. No address, no certificate, no firewall rule. This is the file you review, and it is the only thing that differs between two sites.
Step two
Install the agent on the hardware
Applying the file creates each machine in Infraspawn first and hands back a key for that machine and no other. Install the agent with that key, and it comes up as the machine you created, wherever the hardware happens to be.
Step three
Apply it, and again at the next site
Infraspawn works out the rest: the mesh, the addresses, the certificates, the firewall rules, and which service points at which other one. Running it again changes only what is out of date. Drive it from a terminal, a pipeline, or the dashboard.
apiVersion: infraspawn/v1
kind: Manifest
network:
name: site-114
domain: acme.inc
nodes: [building-01, building-02, cloud]
services:
- name: broker
definition: mosquitto
node: building-01
- name: telemetry
definition: mqtt2influx
node: cloud
depends_on:
- service: broker
logical_name: broker
kind: network_endpoint
- name: gateway
definition: caddy
node: cloudSite example: the network, the machines, and the services across them. The service in the cloud names the broker in the building, and never its address.
The difference
The network comes with it
Most deployment tools start 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. Infraspawn brings the network with it, and the same file that creates the network also places the services, so the two cannot drift apart.
One encrypted mesh, included
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 when a direct one is not possible. Nobody forwards a port or keeps a list of what lives where.
One network per purpose
One for a customer, one for a site, one for a product line, one for a test run. Machines on different networks cannot reach each other at all, so keeping one customer apart from another is decided by which network you created the machine on, not by a firewall rule somebody has to keep correct.
What Infraspawn decides on your behalf, what lands on a machine, and what you can check before any of it happens is on the architecture page.
The case
What it is worth
For teams that install their own software over and over on machines in places they do not control, and for anyone whose hardest environments are the ones furthest away. It also fits when the choice is made for you: data that should not leave the building, or a customer who requires the install on their own hardware.
The expensive part is getting someone there
Every environment that needs a person on it is a senior engineer not building your product, plus whatever it costs to reach the machine: a site visit, a shutdown window, a trip out to the installation. Infraspawn turns the part that repeats into something a script runs, so the size of your installed base stops deciding the size of your infrastructure team.
Site fifty should not need another week of engineering
The work that does not scale is the work you repeat: addresses, certificates, firewall rules, credentials, and the details nobody wrote down. Infraspawn works those out each time instead, so the next one is an edit to one reviewed file. There is no separate networking vendor to sign up for and pay per device.
Or put it underneath your own product
Infraspawn can be the infrastructure layer behind something you sell. Your users choose what they want running, your product decides the experience, and Infraspawn handles the deployment, the connectivity, and the documentation. Your product drives all of it directly, so signing up a customer does not put anyone from your team in the loop.
No lock-in
Yours to keep
Your software runs on machines you own, in accounts you control. Nothing has to move into our hosting for us to manage it, and what you deploy is the software you already run rather than a version rewritten to suit us.
The documentation is written from what is actually deployed rather than from a second document somebody keeps up to date, so there is no gap between the two to find six months later. Read it in the dashboard, or export it: every parameter that was set, and how the services depend on each other, as a PDF for a handover, an audit, or a customer.
Tell us what you deploy
Infraspawn is running in private pilots in PropTech and industry today, and those deployments decide what gets built next. 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.
Pilot customer
Backed by
