Skip to main content

Using the edge bridge

The edge bridge is a small service you run at your location for the cases where Cobblr can't reach a machine directly: a firewall in between, machines at a different site, or software pinned to a specific PC like LightBurn. See Digital fabrication for when you need it. This page is about setting it up and running it.

Where to run it​

Run the bridge where the machines are, on the same network as them:

  • In Docker, alongside a self-hosted Cobblr or on its own.
  • As a standalone binary on a small always-on box, like a Raspberry Pi or a NAS.
  • On a specific PC, when that's where the software lives, like the computer running LightBurn.

One bridge can run more than one machine at once, each on its own path.

Connecting it to Cobblr​

The bridge always dials outward to Cobblr, so you don't open any ports or expose anything on your network. You point it at your Cobblr instance, and Cobblr then sees the machines it manages.

Configuring machines​

The bridge runs a driver per machine. Built-in drivers cover common hardware; for anything else you write one (see Edge-bridge drivers). Each machine is an instance with its own config, and you map it to a machine in Cobblr.

Installing one​

You install a bridge from inside Cobblr, on the Edge bridges page: give it a name, mint its token (least-privilege, it can only do bridge things), and copy the generated command, as docker run or a compose block. Run that where the machines are, and the page shows the moment the bridge dials in. Nothing to configure by hand; the command carries everything.

The command needs no Docker registry and no private image. It runs a stock public node:22-alpine image that fetches the bridge code straight from your own Cobblr, verified by hash, so the install finishes on any network.

Seeing your bridges​

Bridges live on the Devices page, under Configuration → Devices, which gathers everything physical the workspace reaches: bridges, machine managers, and printers, one tab each. The Bridges tab lists every bridge in the workspace: both the ones that dial in to Cobblr and the ones Cobblr reaches directly at an address, such as a bridge on your own computer or a small box on your network. A directly reached bridge never dials in, so it used to be invisible here and its address had to be retyped inside every printer that used it. Now it shows in the same list, tagged direct, with its address, how many machines are configured on it, and whether a token is set. Several machines on one bridge collapse into a single row, so a bridge running two label printers reads as one bridge with two machines rather than two unrelated entries.

Two things about reading a row. First, "reached" means Cobblr's server reached it, not the browser tab you have open. Some jobs, printing labels chief among them, go straight from the page to the bridge, and the two paths can disagree: a bridge on your own network is reachable by a Cobblr you run there but not by a laptop somewhere else. The row says which hop it is reporting, so you look at the right one. Second, if a row warns that some machines on a bridge have no token while others do, act on it: the untokened ones are the ones likely to start failing, and when they do the failure looks like a bridge problem rather than a missing token.

The desktop app on the same page​

If the Cobblr desktop app is running on your computer, it appears on the same Devices page beside your bridges. The app serves a small surface on the computer it runs on, the Devices page looks for it, and when it answers a card shows the app's version, whether its Bluetooth helper is present, and the printers this computer is already configured for, each with a connection test. The app's own settings, which Cobblr it loads and its updates, open from the same card, so they are reachable without going back to the launch screen. Nothing appears when the app is not running, and the page does not report that as a problem.

Two things about that connection test. It opens the Bluetooth link once and hangs up, so macOS asks permission every time you press it; a bridge holds the link open and asks once when it starts, which is why the test is a diagnostic rather than the way to print. And a printer that answers nothing after connecting is usually held by something else: a bridge running on the same computer keeps its printers open on purpose, and two programs cannot own the same Bluetooth serial link.

Staying current​

A connected bridge keeps itself up to date from your own Cobblr instance: it fetches its code from the release your instance serves, so upgrading Cobblr upgrades the bridges that talk to it. No separate update chore per box.