Can my web app print to a node on the same LAN?

Only from the node's own served page, or through a backend on your application's own origin that forwards the request. A hosted page calling a node directly across origins is not qualified on shipping Nodeware: there is no device CORS policy, and being on the same LAN does not satisfy the browser, because the browser checks origin rather than location.

Will my existing POS work if I just change the printer address?

For printing, yes — the node answers on port 9100 like the network printer it replaces, DLE EOT status included. Not for the cash drawer: raw drawer-pulse bytes are dropped on that port, so a POS that opens the till inside its print job needs a separate POST /drawer/kick call, or the drawer has to be recorded as unavailable on that setup.

What network does a node need?

A trusted, restricted segment that you or your installer control. Raw ESC/POS on port 9100 has no authentication and cannot have any, and the optional API key gates HTTP routes only and travels over plain http — it is not transport confidentiality. Do not place a node on guest, public or shared Wi-Fi. The product does not supply the isolation; your network does.

What exactly has been tested?

A generic 80 mm USB ESC/POS printer driven for print, cut and DLE EOT status, and an unbranded RJ12 cash drawer kicked through that printer in 0.15 s, on node pn-d938 with Nodeware 1.2.55. A powered-hub arrangement with a second peripheral has not been qualified on Proxy Node Raw, and no point-of-sale system has accepted an emulated printer identity in our presence.

Do I need an account, a subscription or the internet?

Not for local printing: the print path stays on your network. An account is optional and is what fleet views and over-the-air firmware updates use, and those need internet access.

The Supported Integration Recipe

One demonstrated configuration: what arrives, what you supply, which network it needs, which client shapes work, and where the drawer stops migrating.

Published 2026-09-17 · All documentation →

This page describes one configuration: the one this project has actually driven end to end and is willing to stand behind. Everything else on this site is either a component of it, a comparison with something else, or a route that has not been demonstrated. If you are deciding whether to buy, read this page and nothing else first — it is written so you can say, before you spend anything, what arrives in the box, what you have to supply, and what will be unfinished when you are done.

Where a line says not demonstrated, that is a statement about our evidence, not a prediction that it will fail.

The recipe in one sentence

A Proxy Node Raw board on a trusted, restricted network segment, driving one USB ESC/POS receipt printer with the cash drawer wired to that printer's RJ12 port, spoken to either by raw ESC/POS on port 9100 or by the node's local HTTP/JSON API from a native client, an on-site backend or the node's own served page.

What arrives

The board. A Seeed Studio XIAO ESP32S3 with Nodeware 1.2.55 or later installed and print-tested before it ships. No enclosure, no case label, no mounting.
Nothing else, unless you add the accessories on the Raw page to the same order.

What you supply

You supply	Why it is yours and not ours
A USB ESC/POS receipt printer, on its own mains supply	We do not sell printers. ESC/POS is the only print language this firmware implements
A USB Y cable with a power leg, and a 5 V 2 A supply for that leg	The board has one USB-C port and does not source 5 V to a peripheral
The printer's own USB A–B data cable
A cash drawer wired to the printer's RJ12 port, if you want one	The node kicks the drawer through the printer; it has no drawer port of its own
A 2.4 GHz Wi-Fi network — and a named person who owns its segmentation	Proxy Node Raw's radio is 2.4 GHz only, and the network prerequisite below is not something a product can ship
The client software that calls the node	See "The three supported client shapes"

Each of the cable and power items is available as an accessory; if you already have equivalents, order the board on its own. The setup guide walks the physical build.

The network prerequisite, before the Wi-Fi password

This is a purchase decision, not a configuration detail.

Raw ESC/POS on port 9100 is unauthenticated and cannot be authenticated. It is a socket carrying printer bytes. Anything that can reach it can print and cut.
The optional API key is not transport confidentiality. It gates HTTP routes, travels over plain http on the LAN, and does nothing for port 9100. Treat it as protection against casual misuse on a segment you already control. Node API auth has the tiers.
So the supported installation is a trusted, restricted segment that you or your installer control — the segment point-of-sale equipment belongs on. Not guest Wi-Fi, not a shared building network, not anything reachable from the public internet.
The isolation is yours. The product does not supply it, and no setting inside the node creates it. Before you enter Wi-Fi credentials, write down who configures that segment. Port 9100 hygiene is the practical version.

A reference installation should be accompanied by a drawing of where that boundary actually runs.

The three supported client shapes

There is no fourth. "The node is on the LAN, so my page can call it" is not one of them.

The node's own served page. Same origin as the node, so nothing is in the way. This is what the setup portal and the status page are.
A native or on-site client. A desktop or mobile application, or a backend process running on the printer's network, calling POST /print, GET /status, POST /drawer/kick over plain HTTP. This is the shape the examples in these docs are written in.
A hosted browser application talking to its own backend, which talks to the node. Your page calls your origin; your on-site backend calls the node. The browser never addresses the node.

Not demonstrated: a hosted page calling a node across origins. Shipping Nodeware implements no device CORS policy, and the browser-permission handling that would be needed alongside it has not been qualified. Hosting the page on the same LAN does not change this — origin, not location, is what the browser checks. If your architecture requires that path, it is engineering work that has not been done, and you should not plan around it. Printing from a web app covers each route in full.

What migrates by changing an address, and what does not

If your software already prints raw ESC/POS to a network printer, changing its printer address to the node's port 9100 makes it print, with DLE EOT status queries answered on the same socket. No code change.

That is printing. It is not the drawer. Shipped firmware drops raw drawer-pulse bytes (ESC p, DLE DC4) arriving on port 9100 — the port cannot be authenticated, so forwarding them would let anything on the segment open the till with five bytes. A point-of-sale system that opens the drawer inside its print job will print correctly and leave the till shut.

There are exactly two acceptable outcomes:

The drawer is integrated. Your software makes a separate POST /drawer/kick call. That is an integration change, however small, and it needs the same testing as any other.
The drawer is recorded as unavailable on this setup, in writing, before anyone buys.

A printed receipt does not qualify a drawer, and neither does a DLE EOT response. Qualify print, cut, status and drawer separately, and name your point-of-sale product and its version when you do. The drawer-kick guide has the endpoint and the failure modes.

What has actually been driven, and by what evidence

Part of the recipe	Evidence
Print, cut and column wrapping on a generic 80 mm USB printer	Bench printer reporting `POS-X`, USB `0416:5011`; a 137-byte ESC/POS job accepted over port 9100 on 2026-09-05
Live paper, cover and drawer state over `DLE EOT`	Same bench unit; unreadable state is reported as unknown rather than guessed
Drawer kick through the printer's RJ12	Unbranded RJ12 drawer, 0.15 s from API call to pulse; hardware conformance on node `pn-d938`, 2026-08-23
The protocol itself	146 conformance specs run against the digital twin or a physical node
Firmware baseline	Nodeware 1.2.55 is the recorded bench baseline, not the newest release; a unit that has taken an update is running something newer

Compatibility carries every row with its artefact, including the ones that are identity strings and nothing more.

What this recipe does not cover

More than one peripheral. A scanner or a scale alongside the printer needs a powered USB hub, and that arrangement has not been qualified on Raw. Port count is not compatibility.
Any named point-of-sale product. No point-of-sale system has completed an add-a-printer flow against an emulated identity in our presence. The compatibility profiles advertise; they have not been accepted.
Star native, ZPL, TSPL, EPL2, CPCL. Refusal paths that name what they found, not drivers. Some Star models offer an ESC/POS emulation mode; that mode is a prerequisite for evaluation, not a result.
ePOS-XML. In development.
Ethernet, 5 GHz Wi-Fi, an enclosure. Not on this board.
Anything about a second installer, a measured installation time, or a site that has run a service on this. Those are field evidence, and this page will say so until they exist.

Before you buy, you should be able to say

What arrives in the box and what you are buying separately.
Who owns the network segment the node will sit on, and that it is not guest or shared Wi-Fi.
Which of the three client shapes your software is, and that it is not the unqualified one.
Whether your point-of-sale product opens the drawer inside its print job — and if it does, whether you are integrating POST /drawer/kick or accepting no drawer.

If you cannot answer all four, the honest next step is a conversation rather than an order. Ask, and say which of the four is open.

Frequently asked questions

Can my web app print to a node on the same LAN?: Only from the node's own served page, or through a backend on your application's own origin that forwards the request. A hosted page calling a node directly across origins is not qualified on shipping Nodeware: there is no device CORS policy, and being on the same LAN does not satisfy the browser, because the browser checks origin rather than location.
Will my existing POS work if I just change the printer address?: For printing, yes — the node answers on port 9100 like the network printer it replaces, DLE EOT status included. Not for the cash drawer: raw drawer-pulse bytes are dropped on that port, so a POS that opens the till inside its print job needs a separate POST /drawer/kick call, or the drawer has to be recorded as unavailable on that setup.
What network does a node need?: A trusted, restricted segment that you or your installer control. Raw ESC/POS on port 9100 has no authentication and cannot have any, and the optional API key gates HTTP routes only and travels over plain http — it is not transport confidentiality. Do not place a node on guest, public or shared Wi-Fi. The product does not supply the isolation; your network does.
What exactly has been tested?: A generic 80 mm USB ESC/POS printer driven for print, cut and DLE EOT status, and an unbranded RJ12 cash drawer kicked through that printer in 0.15 s, on node pn-d938 with Nodeware 1.2.55. A powered-hub arrangement with a second peripheral has not been qualified on Proxy Node Raw, and no point-of-sale system has accepted an emulated printer identity in our presence.
Do I need an account, a subscription or the internet?: Not for local printing: the print path stays on your network. An account is optional and is what fleet views and over-the-air firmware updates use, and those need internet access.