Single-node deployment
Meshanics runs as a small set of services that fit comfortably on a single Linux machine. The same control plane that serves a large fleet from a cluster also runs end-to-end on one box — a developer laptop, a rack server in your own data centre, or an edge gateway sitting next to the devices it manages. This is the deployment that lets you evaluate the platform, run a disconnected site, or keep the entire trust domain inside your own perimeter.
What runs on the node
A single-node install brings up the full platform on one host: the database, the device-facing and operator APIs, the signed-artifact and update-metadata services, and the console and this documentation — all behind a single reverse proxy.
The device agent can also run natively on the same box, which makes the node the first device in its own fleet — a convenient way to watch an update flow through verification, atomic swap, and rollback without any extra hardware.
Bring-up
A single bootstrap step generates the local certificate authority and the server and device certificates, prepares the update-metadata repository, writes randomised credentials, builds the images, and starts the stack. You point it at the address that browsers and devices will use:
./bootstrap.sh 192.168.1.50 # the IP or DNS name devices reach
When it finishes, the console, the landing page, and the device endpoints are all live on the one host.
Two operating modes
| Mode | When | Console transport | Device transport |
|---|---|---|---|
| LAN | Lab, bench, disconnected site | Plain HTTP on the local network | mTLS only |
| Domain | A reachable DNS name | TLS, certificates provisioned automatically | mTLS only |
The device-facing ports are mutually authenticated (mTLS) in both modes — there is no insecure variant, and exposing them is by design. In domain mode the reverse proxy terminates TLS for the console and obtains certificates for you; session cookies are then marked secure.
No cloud dependency
Nothing in the core update path requires a managed cloud service. Object storage sits behind an interface so it can be backed by a local store, and the database and metadata repository live on the node itself. That property is what makes a single-node install suitable for an on-prem or disconnected deployment — see Offline & air-gapped operation.
Day-2
Logs, upgrades, and restarts are ordinary container operations. State — including the database volume — survives a stop and start, so you can upgrade in place by rebuilding and bringing the stack back up.