Every team that needs to print from a backend has the same first thought: this is a solved problem, CUPS exists, and a small service in front of it is a weekend of work. That estimate is not wrong about the weekend. It is wrong about what the weekend produces.
The short answer: the code is genuinely small. What you are actually signing up for is reaching printers behind NAT, a queue that survives restarts, exactly-once delivery, and someone answering the phone when nothing prints on a Saturday night. Self-host when the printers are inside your own network and your team already runs infrastructure; buy when they are inside someone else's.
What the weekend produces, and what it does not
| Piece | Weekend? | Reality |
|---|---|---|
| POST an endpoint, spool to CUPS | Yes | Genuinely an afternoon |
| Reach a printer behind a client's router | No | VPN, port forwarding, or a device that dials out |
| Survive a restart mid-job | No | A durable queue, not an in-memory array |
| Never print the same ticket twice | No | Idempotency keys and a store to hold them |
| Know that a printer is down | No | Heartbeats, alerting, an on-call rota |
| Firmware, TLS renewals, OS patches | No | Continuous, and nobody's favourite ticket |
The first row is the one people estimate. The other five are the ones that show up in the calendar for years.
The question that actually decides it
Not "can we build it", but where are the printers?
If they are in your own warehouse, on your own network, administered by your own team, self-hosting is reasonable. You already have monitoring, you already have a maintenance window, and adding a print spooler to that is a marginal cost.
If they are in premises you do not control, a shop, a client site, a franchise, a partner kitchen, then every architectural problem above becomes someone else's router, someone else's power cut, someone else's "we changed internet provider". No amount of good code on your side fixes a printer you cannot reach, and the fix requires a device that establishes its own outbound connection.
That is the real dividing line, and it is not about scale. Ten printers in one building is easy. Three printers in three cities is the hard case.
Where the cost hides
NAT traversal. A printer on a shop LAN has no public address. Your options are a VPN per site, a port forward per site, or a device that connects outward. The first two are administrative work that recurs at every site opening and every router replacement.
Exactly-once delivery. A job accepted then lost during a restart is a missing ticket nobody knows about. A job retried after a partial print is a duplicate. Getting both right requires a durable queue and an idempotency key, which is the part teams most often discover in production rather than in design.
Observability. Printing fails silently by nature: paper runs out, the cable is knocked loose, the router reboots. Without heartbeats, the failure surfaces as a customer complaint hours later.
The pager. This is the one that decides it in practice. Printing fails at 20:00 on Saturday, not at 11:00 on Tuesday. A rota is a real, ongoing cost, and it is rarely in the original estimate.
When self-hosting is the right call
There are good reasons, and they are worth stating plainly:
- A compliance requirement that order data must not leave your infrastructure. This is a legitimate constraint and it settles the question.
- Printers on your own network, in your own buildings, with an ops team already on call for other reasons.
- A very unusual protocol or device that no vendor supports, where you would be writing the driver either way.
- Volume where per-job pricing genuinely dominates your unit economics, and you have the team to absorb the operational load.
If one of these describes you, host it. The exercise below is still worth doing, but the answer may well be "our endpoint is fine, we will keep it", and that is a legitimate outcome.
A cheap way to decide
Before committing either way, cost the following honestly:
- Days to first ticket printed from your backend.
- Days to first ticket printed at a site you do not administer.
- Who is paged on Saturday at 20:00, and what they can actually do remotely.
- What happens the day the person who built it leaves.
Question 2 is usually where the estimate doubles, and question 4 is where a small internal service becomes a liability. If the answers are comfortable, self-host with confidence. If question 3 has no answer, you have found the constraint.
A managed REST print API moves rows two through six of the table to someone else, and leaves you the part that is genuinely yours: which printer receives which document, and what the ticket says. The receipt layout reference covers the formatting side.
Print a test ticket on the free plan from the same backend you were going to build the spooler in. An afternoon of comparison is cheaper than either decision made blind.
Related: reliable order printing covers idempotency and retries in detail, and the cloud print API comparison puts the hosted options side by side.
FAQ
Is a self-hosted print server hard to build?
The first version is genuinely an afternoon: accept a POST and spool to CUPS. What is not an afternoon is NAT traversal, a durable queue, exactly-once delivery, heartbeats and an on-call rota, and those five are what you maintain for years.
When should I host printing myself?
When the printers are on your own network in your own buildings, when a compliance rule forbids order data leaving your infrastructure, when the hardware is so unusual that you would write the driver anyway, or when per-job pricing genuinely dominates your unit economics.
Why is a printer at a client site so much harder than one in my warehouse?
It sits behind a router you do not administer, with no public address. Reaching it means a VPN or a port forward per site, both of which recur at every opening and every router replacement, or a device that establishes its own outbound connection.
Can I use CUPS for cloud printing?
CUPS drives printers well on a network you control. It does not solve reaching a printer on someone else's LAN, and that is the part that makes cloud printing different from local printing.
What usually breaks a build-it-yourself estimate?
The second site. The first printer on your own desk works quickly; the first printer somewhere you cannot administer is where the estimate typically doubles, because it turns a code problem into a networking and support problem.