One API.
Any restaurant hardware.
A node sits beside each receipt printer, cash drawer, and barcode scanner and serves one HTTP/JSON API on your LAN. For POS software you can't change, it answers raw ESC/POS on :9100 — DLE EOT status replies included. Receipts keep printing when the internet doesn't.
{ "lines": [ { type: "text", value: "Table 4", bold: true }, { type: "cut" } ] }
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.
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.
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.
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.
- 1
Local API
Proxy Nodes on your LAN
Your POS calls one JSON API at proxynodes-<id>.local — or streams raw ESC/POS to :9100 like any network printer, DLE EOT status replies included. The node turns those commands into raw hardware bytes.
- 2
Peripherals
The hardware you already own
Receipt printers, cash drawers, barcode scanners — over USB today; serial and Ethernet transports are in development.
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.
75
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.
26
Firmware test suites
Host-built C suites under AddressSanitizer and UBSan on every push — plus the real firmware binary booted in an emulator.
~493
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 variants
One core board. Populated for the station it lives at.
The ESP32-S3 compute module stays constant; connectors change per SKU. Same firmware, same API — different ports. The Station Hub is the flagship, in checkout today.
Station Hub
One node, one counter: printer, cash drawer, and barcode scanner behind one API.
- USB printer
- Cash drawer (via printer)
- Barcode scanner
- Scale (in development)
Buy the Station Hub →
Wi-Fi Node
Drives a standard USB receipt printer over Wi-Fi — the everyday workhorse, available as a configuration.
- USB receipt printer
- Cash drawer (via printer)
Legacy Serial Node
Speaks RS-232 to the older scales and pole displays nobody wants to replace. In development.
- RS-232 scale
- Pole display
PoE Ethernet Node
Data and power over one Cat6 run, for deep kitchens where Wi-Fi gives up. In development.
- USB kitchen printer
- PoE — no wall wart
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
ShippedRaw 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 developmentVendor 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 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
- · 75 conformance specs that run identically against the twin or real hardware
The business
- · Assembled, supported hardware — the Station Hub, in checkout now
- · A fleet console — monitoring, remote config, OTA across sites (in development)
- · ISV licensing, white-label builds, and conformance certification — in development
Publishing the source is on the engineering docket. 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.0.10 on ESP32-S3 — print, cut, live paper/cover/drawer state over DLE EOT
- 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 Station Hub
In development
- OTA updates
- Ethernet / PoE transport
- RS-232 transport
- Scale support
- Fleet console (account fleet view shows presence today, not control)
- ePOS-XML / CloudPRNT emulation
- Custom board
The full picture, including what's deliberately deferred: what's next.
Get product updates
Want launch and firmware updates? Leave an email.