LAN print workstation

One machine holds the printers and computers on the same subnet share the output: configuration, browser limits and rollback.

In warehouses, stores and production lines a common setup is one machine holding the printers and running PrintLink, with other computers on the same subnet sending jobs to it over the network address.

This is an advanced deployment

A LAN listener makes the print service reachable at the network layer from any device on the subnet. The source allow-list, site authorisation and interface permissions are three independent gates; do not go live missing any one of them. Test every step on your own real network before deploying.

When it applies

Applies	Does not apply
Several terminals sharing one or two label / receipt printers	The printer is on the operator's own computer (use the default local path)
The workstation has a stable private address (static IP or DHCP reservation)	The terminals and the workstation are on different networks (see controlled remote access)
The page loads over HTTP, or you can provide a WSS proxy	A public HTTPS page connecting directly to `ws://192.168.x.x` (the browser blocks it)

Configuration steps

Install PrintLink and the printers on the workstation

Follow install, then install every target printer in the operating system. The scope is still local connections only; first verify printing from the workstation's own browser with the quick start before widening anything.

Give the workstation a stable private address

Prefer a static IP or a DHCP reservation: if the address changes, every terminal's endpoint has to change with it.

An address change does not take the workstation down — the loopback address that local printing depends on is always bound, and a dead LAN address affects only itself:

Situation	Behaviour
Some addresses are still alive	Your list is kept; the dead one is skipped for this run
All dead, a suitable local address exists	One is chosen automatically (physical NICs first, IPv4 preferred), saved, and a system notification tells you which
All dead and nothing suitable	The original list is kept rather than emptied; this run is loopback-only

For two minutes after the service comes up it rebinds on a 3 / 7 / 15 / 30 / 60 second schedule (start-at-login often races the DHCP lease) and stops once everything is in place.

Configure the allow-list before switching scope

In console → Security & sites → Network access:

Allowed sources: an exact subnet such as 192.168.10.0/24. Never 0.0.0.0/0.
Denied sources: denial beats allowance, useful for excluding guest subnets.

These are saved but inactive while the scope is still "local only" (the UI says so), so you can fill them in ahead of time.

Switch the listen scope

In Settings → Service listen scope choose LAN and tick the workstation's private address (the loopback address stays bound). The confirmation dialog lists the scope, port, bound addresses, the number of active rules and trusted sites, and states that TLS is not provided.

The switch is one transaction: an occupied port, a missing address or a failed save rolls the whole thing back and the old service keeps running.

Point terminal pages at the workstation

const client = new PrintLink.PrintLinkClient({
  appName: 'Warehouse pick list',
  endpoint: 'ws://192.168.10.20:17888/ws',
});

The SDK script itself can also be loaded from the workstation (http://192.168.10.20:17888/sdk/printlink.js) or shipped with your page — both speak the same protocol.

Authorise the sites on the workstation

The confirmation appears on the workstation's PrintLink, not on the terminal. You can:

Confirm once on site as an administrator;
Set the new-site policy to allow-list only and add your intranet ERP's origin ahead of time;
Use machine policy to lock the listen scope and site policy so the site cannot be changed by accident.

Why an HTTPS page cannot reach `ws://192.168.x.x`

Browsers treat the loopback address as a potentially trustworthy origin, so an HTTPS page may connect to ws://127.0.0.1:17888/ws. A plaintext connection to a non-loopback address is blocked as mixed content. So:

An intranet ERP loaded over HTTP can connect directly to the workstation's ws:// address.
A public HTTPS page cannot. Either put a certificate-bearing reverse proxy in front of the workstation (see controlled remote access), or have the operator open the page on the workstation itself.

PrintLink has no built-in TLS; this limit comes from the browser, not from a configuration option.

Non-browser programs on other computers

The workstation's own PrintLink UI and same-machine automation carry no Origin and are treated as a trusted local client when they come from the loopback. But a no-Origin connection from another computer is refused before the handshake (REMOTE_NATIVE_CLIENT_DENIED), even when the allow-list permits its IP.

Until a dedicated service/device token system exists, LAN terminals should use browser pages — see controlled remote access.

Troubleshooting and rollback

Symptom	Check	Rollback
A terminal cannot connect	The workstation firewall; whether the terminal's IP is in the allowed range; whether the browser reports mixed content	Switch the scope back to local only; all remote sessions drop immediately
Asked to authorise / waiting	Handle the pending request in the workstation console under Security & sites	Removing the site revokes its token
Permission denied	The token lacks the print permission	Adjust that site's permissions in Security & sites
"Listen addresses were adjusted automatically"	A saved address no longer exists on the NIC; it was re-chosen or skipped and the service is still running	Point terminals at the new address from the notice; use a DHCP reservation to pin it
Saving the listen config fails to bind	Saving is all-or-nothing: a ticked address cannot be bound right now (NIC down, port taken) and the old listener is untouched	Refresh the NIC list and tick addresses that really exist
Need to tighten urgently	Security & sites → Restore secure defaults	Tightening takes effect immediately