Can I push a firmware update to every site from one screen?

You can publish a release and promote it, and nodes set to update automatically will pull it inside their maintenance windows. What you cannot do is reach into a site and force a specific node from outside its network — the node asks the cloud, the cloud never reaches the node.

What stops a bad release taking down every location at once?

A release is published at a rollout of zero and goes nowhere until it is promoted, so there is always an older build to fall back to. Yanking one stops it spreading automatically — though a node pinned to that version is still offered it, on purpose. And a node that takes an image it cannot boot is put back on the previous one by its own bootloader.

Do I need a point-of-sale connection between sites for this?

No, and there isn't one. Each site's print path is entirely local to that site. The only thing crossing the internet is a node asking whether there is a new firmware release, plus telemetry if you have configured a receiver.

What does the fleet view actually tell me?

What each node is, when it was last seen, and its address on its own network. It is presence, not remote control — and the address is a link your browser opens when you are on that network, because a public web page cannot read a private one.

If the cloud is down, what breaks?

Printing does not. The update check and the fleet view do. A node that cannot reach the cloud keeps driving its printer, keeps answering status queries, keeps buffering whatever telemetry it has, and carries on until somebody plugs the internet back in.

Can I run the telemetry side myself instead?

Yes. A node will point at your own receiver, and the batch format, the retry rules and the limits are all documented — that is a wire contract, not an integration. A node with no receiver configured stores nothing at all.

Many Sites: Updating Nodes Nobody Is Standing Next To

What one account sees across locations, how a node pulls a firmware release with nobody visiting, and the four things this cloud deliberately cannot do for you.

Published 2026-09-10 · For restaurants →

Ten counters in one building is a wiring problem. Ten counters in ten buildings is a different problem: nobody is standing next to the hardware, and the person who could fix it is three hours away. This page is about what an account can and cannot do across sites — what you can see, how a node takes a new firmware release with nobody pressing anything, and the four things this deliberately does not do, which are as much a part of the answer as the features are.

What one account sees

Claim a node with its claim code and it appears in your fleet. What that view holds is modest and worth stating exactly: what each node is, when it was last seen, and the address it has on its own network.

That last one is a link you can open, and the distinction matters. The website does not read your node — an https page cannot fetch a plain-http address on a private network, permanently and by design, and nothing here pretends otherwise. It hands your browser an address; your browser goes there when you are on that site's network. The site is never in the path.

A node keeps printing whether or not it is claimed, and whether or not our cloud is reachable. Claiming is how you find out about it, not how it works.

Updating a node nobody will visit

This is the part that actually changes with distance. A node asks the cloud what it should be running, and is handed a short-lived signed download URL plus the image's sha256 in the same authenticated answer. It verifies the digest against what it downloaded, writes the other boot slot, and restarts. The image never travels on the strength of a URL alone.

Per node, the controls are:

Automatic or pinned. Pinned means this node runs the version you named and nothing else.
A channel, for nodes you want on a different track from the rest.
A maintenance window, so a restart lands at four in the morning rather than during service.
Update now, for when you are watching and want it over with.

This has been proven unattended on real hardware, which is the only kind of proof worth quoting: a node pulled a release with nobody pressing anything, held its reboot through a quiet-bus wait, came back on the other slot and reported the update applied — while a second node stayed pinned on an older build throughout.

Publishing a build is not shipping it

This is the sentence that trips people, so it is here rather than in a footnote. A release exists before it goes anywhere. It is published at a rollout of zero and stays there until somebody promotes it, and that gap is not bureaucracy — it is what creates a rollback target. A fleet where every node is already on the newest thing has nothing to fall back to.

A yank stops the spread, not the access

Yanking a bad build stops its automatic spread, not access to it. A node explicitly pinned to a yanked version is still offered that version, deliberately — because the operator who pinned it may have pinned it for a reason, and silently overriding that is the behaviour you would least want from a fleet tool at two in the morning. It is a brake on distribution, and this site will not sell it as anything stronger.

We publish no rollout speed, no time-to-update, and no fleet size. Not as modesty — those figures do not exist in a form anyone could stand behind, and a number invented for a page is the thing this site exists not to do.

When an update goes wrong

Two different failures, two different recoveries, and they are worth telling apart before you need them:

A bad image that still boots. One call reverts the node to its factory image.
An image that cannot boot at all. It needs no call: the bootloader puts the node back on the image it was running. That was proven on a real node with a deliberately broken image, and it is the reason the slot arrangement exists. We quote no recovery time for it — one observation on one bench is not a measured spec.

A node also refuses an image built for a different hardware variant before it opens a socket for it, which is the one failure rollback genuinely cannot help with: an image for the wrong variant boots, serves its API and reports itself healthy while quietly declaring the wrong peripherals. Hardware variants has the full table of what each one declares.

Each site is still its own network

Nothing spans sites at the network layer, and you should design as though that is permanent, because it is:

Peer discovery is per-LAN. Ask any node on a site for its peers and it lists the rest on that network, with what is plugged into each — one known address reaches the whole floor. It does not reach the next town.
A node per station, not a server per site. A node velcros to the back of the hardware it drives, so one failure takes one station down rather than the floor.
The print path is local at every site, always. That is the property that makes a twelve-location group survive somebody else's outage, and it is the same property whether you have one site or twelve.

The four things this does not do

No remote access to a node, and no traversal into your networks. You cannot print to a site from head office, open a shell, or read a node's status from outside its LAN. Nothing on this page is a step toward that.
No cloud in the print path, ever — which is the flip side of the same design, and the reason it is a feature rather than a gap.
No uptime commitment for the cloud layer. Nodes do not need it to print; we are not going to publish a number for it.
Telemetry is switched on, not assumed. A node with no receiver configured retains nothing, and data from a device that has opted out is dropped rather than stored. If you want it somewhere you control, the wire contract is self-hosted node telemetry.

Before you standardise across sites

Buying the same thing thirty times is exactly when an unproven claim gets expensive, so here is the one to check first. If your point of sale prints to an address you type in, a node answers as a network printer on port 9100 with real status replies and your POS needs no changes. If your point of sale instead picks a printer from a certified list, that is the case we cannot show you working — the printer identities a node can advertise have never been accepted by a real point-of-sale system in our presence, and the compatibility page says so in the same words the firmware's own source does. Prove it on one site before you buy for thirty; the Proxy Node Kit is one purchase, and the free simulator costs nothing at all.

FAQ

Frequently asked questions

Can I push a firmware update to every site from one screen?: You can publish a release and promote it, and nodes set to update automatically will pull it inside their maintenance windows. What you cannot do is reach into a site and force a specific node from outside its network — the node asks the cloud, the cloud never reaches the node.
What stops a bad release taking down every location at once?: A release is published at a rollout of zero and goes nowhere until it is promoted, so there is always an older build to fall back to. Yanking one stops it spreading automatically — though a node pinned to that version is still offered it, on purpose. And a node that takes an image it cannot boot is put back on the previous one by its own bootloader.
Do I need a point-of-sale connection between sites for this?: No, and there isn't one. Each site's print path is entirely local to that site. The only thing crossing the internet is a node asking whether there is a new firmware release, plus telemetry if you have configured a receiver.
What does the fleet view actually tell me?: What each node is, when it was last seen, and its address on its own network. It is presence, not remote control — and the address is a link your browser opens when you are on that network, because a public web page cannot read a private one.
If the cloud is down, what breaks?: Printing does not. The update check and the fleet view do. A node that cannot reach the cloud keeps driving its printer, keeps answering status queries, keeps buffering whatever telemetry it has, and carries on until somebody plugs the internet back in.
Can I run the telemetry side myself instead?: Yes. A node will point at your own receiver, and the batch format, the retry rules and the limits are all documented — that is a wire contract, not an integration. A node with no receiver configured stores nothing at all.