Architecture

How your tools reach a BenchPod, which of those paths are encrypted, and what is inside the pod. Who may do what on each path is on Security & trusted repos.

How you reach the pod

The pod speaks one API (JSON commands and SCPI) on every path, so the CLI, the Python SDK and the MCP server work the same way over all of them.

How you reach a BenchPodYour computer reaches the pod three ways. Over the USB-C cable: the console and the USB network, plaintext but a direct cable. Over Ethernet or Wi-Fi: port 8080 plaintext with no login, or port 8443 with TLS and a pinned certificate; HTTPS-only turns 8080 off there. Through embeddedci.com when the pod is registered: the pod dials out over a TLS WebSocket and signs in with its device key, and the web app, CI jobs and embeddedci:<name> connections reach it over HTTPS.Your computerbenchpod CLIPython SDK, pytestMCP server (Claude)BenchPodJSON + SCPI API, the same commands on every pathUSB-CEthernetor Wi-Ficonsole + USB network:8080 plaintext:8443 TLS(HTTPS-only: no 8080)outbound to embeddedci.comUSB-C cable: physical accessplaintext, but never on a networkport 8080: not encrypted, no loginport 8443: TLS, certificate pinnedEthernet or Wi-Fi, through your networkembeddedci.comsign-in, roles, audit logleases, web app, CI runsWebSocket over TLS, pod dials outdevice key (Ed25519), only when registeredAnywhereweb app in a browserGitHub Actions (OIDC)CLI/SDK: embeddedci:<name>HTTPS: sign-in, API key or OIDCsame computer,through the cloudencrypted (TLS)not encrypted, on a networkdirect USB cable
  • USB-C cable. The pod's USB console, and from firmware 3.9.0 a USB network adapter with the full API on 10.237.x.y:8080 (--connection usb). Not encrypted, but it is a cable between the pod and one computer, never a network.
  • Ethernet or Wi-Fi, port 8080. The API in plaintext with no login, like most bench instruments. Anyone on the network path can read or change the traffic, so keep it on a trusted network, or turn on HTTPS-only.
  • Ethernet or Wi-Fi, port 8443 (firmware 3.9.3+). The same API over TLS. The pod makes its own certificate on first boot, or uses yours (benchpod lan-tls set-cert). The CLI, SDK and MCP server use it when the pod has it and pin the certificate on first use. HTTPS-only API in the pod's Settings tab (or benchpod lan-tls https-only on) turns 8080 off on Ethernet and Wi-Fi; the USB cable keeps it. TLS encrypts the traffic; it does not log anyone in.
  • embeddedci.com, once the pod is registered. The pod dials out to embeddedci.com over a TLS WebSocket and proves who it is with its device key, so it needs no open port and works behind NAT. The web app, GitHub Actions (OIDC) and --connection embeddedci:<name> reach it from anywhere over HTTPS, with sign-in, roles and an audit log. An unregistered pod never contacts embeddedci.com.

Inside the pod: digital board

The MCU runs the firmware, the API, the network and the cloud link. Next to it, an FPGA runs the instruments on the 14 logic-analyzer channels of the J1 header, so any function (capture, GPIO, SWD flashing, UART, SPI, I2C and GPS emulation) can go on any channel at the board's I/O voltage (1.8 V or 3.3 V). Deep captures land in the FPGA's memory. The pod switches your board's power through eFuses and measures its current.

Inside the BenchPod: digital boardAn MCU runs the firmware and the API. It reaches the network over USB-C, Ethernet and optional Wi-Fi, drives CAN, and switches target power through eFuses with current monitors. An FPGA next to it runs the instruments on the 14 logic-analyzer channels of J1 (capture, GPIO, SWD, UART, SPI, I2C and GPS emulation), with memory for deep captures and flash for its images. The digital board has no analog section; its expansion connector can take one later.BenchPod v3, digital boardUSB-Cconsole + USB networkEthernetRJ45, the primary networkWi-FioptionalCANclassic CAN busMCUfirmware, JSON + SCPI APInetwork, TLScloud link, updatesdevice keyTarget powereFuses: internal 5 V or externalcurrent monitors, DUT resetFPGAinstrument engines:capture, triggers, GPIOSWD flashing, UARTSPI, I2C + GPS emulationSPIMemorydeep capturesFlashFPGA imagesshared busJ1: 14 LA channels1.8 V or 3.3 V I/O, to your boardevery function on any channelCN1 expansion connector: no analog section on this board

Inside the pod: digital + analog board

The analog board is the digital board plus an analog front end, driven by the same FPGA: a 16-bit DAC with 0 to 3.3 V, 0 to 5 V and ±12 V outputs, a 16-bit ADC on a ±30 V input, and a 4-20 mA output and input. The pod tells the two boards apart at boot; benchpod status and the web app show which one you have. Connectors and pin-out: Pin-out & connectors.

Inside the BenchPod: digital + analog boardAn MCU runs the firmware and the API. It reaches the network over USB-C, Ethernet and optional Wi-Fi, drives CAN, and switches target power through eFuses with current monitors. An FPGA next to it runs the instruments on the 14 logic-analyzer channels of J1 (capture, GPIO, SWD, UART, SPI, I2C and GPS emulation), with memory for deep captures and flash for its images. The analog board adds a 16-bit DAC with 0 to 3.3 V, 0 to 5 V and plus or minus 12 V outputs, a 16-bit ADC with a plus or minus 30 V input, and a 4-20 mA output and input.BenchPod v3, digital + analog boardUSB-Cconsole + USB networkEthernetRJ45, the primary networkWi-FioptionalCANclassic CAN busMCUfirmware, JSON + SCPI APInetwork, TLScloud link, updatesdevice keyTarget powereFuses: internal 5 V or externalcurrent monitors, DUT resetFPGAinstrument engines:capture, triggers, GPIOSWD flashing, UARTSPI, I2C + GPS emulationSPIMemorydeep capturesFlashFPGA imagesshared busJ1: 14 LA channels1.8 V or 3.3 V I/O, to your boardevery function on any channelAnalog front end (analog board)DAC, 16-bit0 to 3.3 V, 0 to 5 V, ±12 VSMA outputswaveforms, replay, DCADC, 16-bit±30 V input (SMA)captures, readings4-20 mAoutput (J9)input (J8)set and read in mAdriven by the FPGA