Proxy Node Kit · local-first by design

Your printer. Your network.
One local API.

Connect supported USB receipt printers and peripherals to your software over your local network. Start with an ESP32-S3 preloaded with Proxy Nodes firmware. Use the HTTP/JSON API, or raw ESC/POS over port 9100 with compatible POS software. Local printing keeps working without an internet connection.

I build POS software

Stop writing printer drivers →

Integrate one JSON API. Test in CI against a free digital twin — no hardware.

I run a restaurant

Escape the hardware tax →

Pair the generic $40–160 printer of your choice with the POS you already have — and keep printing offline.

$39 for the programmed board. Add the recommended USB Y cable for $10.

Prices in USD. Shipping and applicable tax are additional.

Buy Proxy Node Kit — $39Explore the firmware

Check compatibility · See how setup works

Product photography outstanding

Photographs of the exact stocked board and its accessories are still to be taken. The Station Hub concept render is on its own page, labelled as a concept — it is not this kit.

POST http://proxynodes-7f3a.local/print
{
  "lines": [
    { type: "text", value: "Table 4", bold: true },
    { type: "cut" }
  ]
}
node online · paper OK · scanner bound in 1,012 ms — status read live over DLE EOT
  • 1,012 ms printer bind
  • 0.15 s drawer kick
  • 146 conformance specs
  • 2338 JS tests
  • 59 firmware suites · ASan/UBSan
  • 48 columns, measured on paper

The problem

Restaurant hardware is a fragmented mess — and your software pays for it.

Decades of incompatible peripherals sit between POS software and a working front counter. Today, someone writes glue code for all of it. Proxy Nodes replaces that glue with one API.

01

Driver hell

Every printer, scale, and scanner speaks its own dialect. Supporting them means shipping and maintaining dozens of brittle, platform-specific drivers — and answering the "printer offline" tickets they generate.

02

Vendor lock-in

Legacy POS contracts only talk to the hardware on a certified whitelist — typically $275–571 per intelligent printer. Swap in a $40–160 generic and the system quietly stops working.

03

Hardware churn

A restaurant replaces a Star printer with an Epson and suddenly your software needs a code change. Multiply that across every location you support.

How it works

Two layers. Your software only ever touches the top one.

Commands flow down; status flows back up. The POS talks to a single API on your own network and stays completely insulated from the hardware underneath. No broker, no round trip to a data center.

Your software

POS · KDS · kiosk

Calls one JSON API at proxynodes-7f3a.local — or streams raw ESC/POS to :9100 like any network printer.

POST /print · JSON →

← GET /status · SSE /events

PN-PROTO-1 concept render — a palm-size two-tone node with ethernet, printer and scanner USB ports, USB-C power, and a status LEDconcept

The node

Speaks JSON up, raw hardware bytes down. Firmware 1.2.33, tunable over PUT /config — no reflash.

raw ESC/POS · USB →

← DLE EOT paper · cover · drawer

Peripherals

The hardware you already own

  • · Receipt printer
  • · Cash drawer (via printer RJ12)
  • · Barcode scanner
  • · USB scale
  • · RS-232 devices — in development

Legacy POS? Point it at the node’s :9100 port and change nothing — the node answers like the network printer it replaced, DLE EOT status queries included.

There is a cloud layer — Stripe checkout, AI support chat, accounts and node claiming, telemetry with per-device opt-out — and it is never in the print path. A node prints, reports status, and kicks the drawer with zero internet.

Why believe it

Numbers with units, or it didn't happen.

Every figure below comes from the repository or the bench — measured on real hardware, enforced in CI.

1,012 ms

Printer bind

From USB plug-in to printing, through a powered hub, with a barcode scanner bound simultaneously on the same node — zero port cycles.

0.15 s

Drawer kick

The drawer-kick pulse, measured. It was 9–24 s before firmware 1.0.9 turned off Wi-Fi power save. We publish the before because the after is the point.

146

Conformance specs

One suite runs identically against the digital twin and a real node. "Works against the simulator" is a checkable claim, not a slogan.

59

Firmware test suites

Host-built C suites under AddressSanitizer and UBSan on every push, across the drivers, the HTTP surface and the config store.

2338

JS tests

Across the protocol schema, the twin, the tools, and this site. One zod contract is shared by all of them, so the docs can't drift from the wire.

48

Columns, measured on paper

The default print width for 80 mm Font A — measured, not copied from a datasheet. Per-printer overrides are a PUT /config away, no reflash.

Hardware

A kit you can buy, and hardware we're building.

The Proxy Node Kit is an off-the-shelf ESP32-S3 with our firmware on it. Station Hub is our own board and enclosure, still in development — they are not the same product and this page will never imply they are.

Proxy Node Kit

Not yet available

An ESP32-S3 with Proxy Nodes firmware installed and tested. Connect over 2.4 GHz Wi-Fi and add the cables you need for your supported setup.

From $39.

Configure your kit →

Station Hub

Coming soon

Our upcoming custom hardware brings the Proxy Nodes platform into an integrated station device. We're designing for Ethernet, 2.4/5 GHz Wi-Fi, and multiple powered USB ports.

In development. Final specifications and availability have not been announced.

Explore Station Hub →

For developers

Integrate supported peripherals through a local API. Explore the protocol and simulator, then test your application with a real node.

Developer resources →

For restaurants and installers

Put supported hardware on your local network with a small, preprogrammed adapter. Check your printer and POS compatibility before ordering.

Check compatibility →

Protocol emulation

Look like the printer your POS expects. Use the one you chose.

A node runs entirely on the local network and presents itself as the network printer a legacy system already knows how to talk to — then drives generic gear behind it.

TCP :9100 · mDNS

Shipped

Raw ESC/POS + compatibility profiles

Every node listens on the standard raw-print port, accepts the bytes a legacy POS sends to a network printer, and forwards them to the connected hardware — answering DLE EOT status queries with real paper, cover, and drawer state, not a guess. Compatibility profiles (epson-tm-m30, epson-tm-t88, star-tsp100, custom) publish the model identity your POS looks for and re-advertise live, without a reboot.

HTTP · vendor protocols

In development

Vendor endpoint emulation

ePOS-Print XML and CloudPRNT endpoints on the node: parse the incoming job, translate it to raw ESC/POS for whatever hardware is actually connected. In development, built on the same driver seam the shipped :9100 path uses.

Built the right way

Emulation is written from scratch against publicly documented specs — no proprietary code or firmware is copied. Nodes ship with a generic identity; a compatibility profile is something the operator explicitly turns on per node. You configure the tool for compatibility with the system you run.

The cloud, kept in its place

Nodes report up. Nothing depends on it.

A heartbeat, not a control channel. The node buffers telemetry in a ring, sends on a schedule, and clears only what a 2xx acknowledged — everything else keeps. Pull the uplink and it keeps printing.

Node · pn-7f3a

heartbeat ring · clears on 2xx only

zero NVS writes on this path

POST /v1/ingest · on a schedule →

← 202 accepted · anything else keeps the ring

Cloud · beside the path

  • · Fleet visibility at /account — last seen, firmware
  • · Claim a node with the code on its printed slip
  • · Per-device opt-out: opted-out data is dropped, stored nowhere

Point the heartbeat at your own server instead — GET/PUT /cloud configures the endpoint, and the wire contract is documented.

The Open Protocol

The protocol is documented. Conformance is checkable.

The wire contract is a published spec, the digital twin is free to run, and the conformance suite makes 'implements the protocol' a test result — not a marketing line.

Open and runnable today

  • · The wire contract — every endpoint, every field, documented as one shared schema
  • · The digital twin (pnpm sim) — the byte-compatible simulator with fault injection, free
  • · 146 conformance specs that run identically against the twin or real hardware

The business

  • · Preprogrammed, supported hardware — the Proxy Node Kit, in checkout now
  • · The fleet console — per-node update policy, channels, maintenance windows and Update now, live on /account
  • · ISV licensing, white-label builds, and conformance certification — in development

We have not announced an open-source release of the firmware. The pattern stands either way: open local data plane, paid management on top — a print job never needs our servers. Read the Open Protocol stance →

Where we are

Shipped means measured. In development means in development.

Everything in the left column runs on real hardware or in production today. Everything on the right gets exactly one label and no promised date.

Shipped

  • Firmware 1.2.33 on ESP32-S3 — print, cut, live paper/cover/drawer state over DLE EOT
  • Firmware updates over the air on the LAN — key-gated, bad images refused, one-call revert to factory, and an unbootable image rolled back by the bootloader
  • Printer and barcode scanner proven simultaneously behind a powered USB hub — bind in 1,012 ms
  • Cash-drawer kick measured at 0.15 s
  • LAN peer discovery — one known IP reaches the whole fleet via GET /peers
  • Accounts with claim codes — claim a node from its printed slip, see your fleet at /account
  • Stripe checkout for the Proxy Node Kit, with optional accessories priced per kit
  • Ethernet on the wire — a cabled node takes a DHCP lease and serves over it, with the radio on standby and failover measured in both directions
  • USB scale readings — GET /scale serves weight, unit and stability, and a scale that has gone to sleep says so instead of reading a confident zero
  • The fleet console on /account — per-node update policy, channel, maintenance window, pinned version, and Update now

In development

  • Power over Ethernet — the Ethernet link is proven on real hardware, but nothing here has yet been powered over the cable
  • RS-232 serial — the endpoint table and a conformance assertion exist; no build of that variant ever has
  • ePOS-XML / CloudPRNT emulation
  • Station Hub — our own board and enclosure

The full picture, including what's deliberately deferred: what's next.

Get product updates

Want launch and firmware updates? Leave an email.