Deployment & upgrade
Meshanics runs as a small set of services that fit on a single Linux host, alongside a Postgres database, and serve the device-facing and operator APIs and the console. The same composition runs on a developer's laptop, on a bench device, and in production — including fully on-premises or air-gapped, with no dependency on a specific cloud provider.
This page covers the control plane. To bring a device into a running fleet, see Enroll a device.
Single-node bring-up
The supported entry point is a one-shot bootstrap that takes the address your devices and browsers will use, then prepares everything the stack needs before starting it:
./bootstrap.sh 192.168.1.50 # the IP or DNS name the fleet will reach
The bootstrap, in order:
- generates the certificate authority and the server and device certificates, with the host you supplied included in the certificate's subject alternative names, so mutual TLS works on day one;
- prepares the update repository's trust metadata;
- writes an environment file with freshly generated credentials, at restrictive permissions, that is never committed;
- builds the service images and starts them.
When it finishes, the console, the device gRPC endpoint and the device update repository are listening. Device-facing ports are mutual-TLS only — there is no insecure variant, and exposing them is by design.
The bootstrap prepares trust metadata locally for convenience. For a production trust domain, the root ceremony belongs on a separate, offline machine; you then place only the resulting signed metadata on the host. See TUF for why the roots stay offline.
LAN versus domain mode
On a closed local network the console can be served over HTTP for evaluation. When you point a real domain at the host, it moves behind HTTPS automatically, with certificates provisioned for you. Use domain mode for anything reachable beyond a trusted local network.
Upgrading in place
Upgrades are pull-and-restart. With prebuilt images you point the stack at a new image tag and recreate the services; on hosts that build locally, you rebuild and recreate. The database volume is independent of the service containers, so it survives a recreate untouched. Take a database backup before any upgrade — see Backup & restore.
Roll back an upgrade by recreating the services at the previous image tag. If a release changes the database schema, restore the pre-upgrade backup as part of the rollback so the schema and the binaries match.