A point-of-sale system you run on your own hardware.
Apron is for small operations that want to own their data and keep selling when the network goes down — cafés, retail counters, and badge-based charge accounts like school and workplace cafeterias.
A lunch rush, then the books behind it.
Two screen recordings from a real v0.14.0 install. The register rings two sales; the admin then shows those same two sales. Nothing is staged — the totals on the dashboard are the ones rung a minute earlier.
- A cashier signs in with a PIN on the touch pad.
- Three items rung; subtotal, tax, and total follow every tap.
- $10.00 in cash, and the change due before the drawer opens.
- A second sale charged to a staff account — the day's meal credit covers $3.00 of it, the account carries the rest.
- Today's takings on the dashboard — the two sales from the register clip.
- The catalog behind the register's grid.
- The charged account: its ledger with the new charge, and the daily credit it spent.
- A credit type defined, then issued to an account.
- Reports: the day's sales, then account charges ready for payroll.
- A second register created, with its one-time pairing code.
- The audit log, carrying every action from the minute before.
Silent, unedited, and served from this page — no video host, no embed, nothing loaded until you press play.
A complete register and the admin behind it.
Everything a small venue needs to ring a sale, manage who owes what, and keep its own records — with nothing phoning home.
Rings sales
Cash, card-present, and charge-account tenders. Multi-line carts, taxes, discounts, and change due — plus held tickets, refunds, item modifiers, combos, and menus that change with the daypart.
Runs charge accounts and credits
Per-person ledgers with overdraft policy, badge lookup, and statements. A daily allowance or an issued credit is spent automatically at the register, and the period's charges export for payroll deduction.
Prints receipts, kicks drawers
ESC/POS over USB, network, or serial. Most receipt printers and integrated cash drawers work out of the box — or skip the paper and email the receipt instead.
Works offline
Registers keep selling when the server, network, or upstream is down. Events queue locally and sync when connectivity returns.
Backs itself up
Local filesystem today, with S3, WebDAV, and SFTP staged behind the same pluggable interface. Scheduled or on-demand snapshots in a documented format, covering every table in the schema — a test fails the build if a new one escapes.
Has an admin web UI
Products, accounts, credits, employees, roles, reports, registers, audit log, and settings — role-based access throughout, and a setup checklist that walks a new venue from empty install to first sale.
If a cashier can do it, it works with the network unplugged.
Apron treats offline operation as a rule, not a feature. Every action at the register — ringing items, taking cash, charging an account, printing a receipt — is designed to complete on a machine with no connection.
Each sale is written to a local event log the moment it happens. When the link to the server returns, those events sync upward with documented conflict resolution. No spinner in the hot path of a sale, ever.
Bring your own printer, terminal, and reader.
Payment processors, receipt hardware, and backup destinations are pluggable interfaces — not bundled dependencies you can't swap.
Receipt printers & drawers
ESC/POS over USB, network, or serial. Cash drawers kick through the printer. Tested against the byte-level protocol most thermal printers speak.
Card payments, no card data
Card-present runs through Stripe Terminal (or any P2PE provider). The terminal captures and encrypts in hardware; apron only ever sees a token — so it stays outside PCI scope.
Badge readers
Keyboard-wedge and PC/SC contactless readers look up a charge account in a beat — an account can even carry badges from both during a reader migration. Pair either with the account ledgers in the admin.
One counter or a dozen — same code paths.
The deployment shape is a config-time choice. The binaries don't change, so what you test on one register is what runs across the venue.
All-in-one
The register host is the server. A desktop app launches the backend alongside it, stored in SQLite. One machine, no network required to make a sale. Best for a single coffee bar or counter.
Server + N registers
A central service runs against SQLite or PostgreSQL; registers connect over the LAN, keep a local event log, and keep operating through network or server outages. Best for a multi-register cafeteria or store.
Same binaries, same code paths — the choice is config-time.
A checkout system that knows what it isn't.
Apron does the front-of-house register and the admin that supports it — and deliberately stops there. The boundaries are a design choice, written down.
- The front-of-house register: sales, tenders, tax, change due
- Badge-based charge accounts, overdraft policy, and credits
- Offline sales with sync and documented conflict resolution
- Admin with role-based access, reports, and an audit log
- Backups to a destination you choose and control
- Kitchen display, table management, course timing
- E-commerce and online ordering
- Inventory receiving, purchase orders, supplier management
- Payroll and time clock
- Running in someone else's cloud by default
No telemetry, ever. No upsells, no nag screens, no paid feature gates. You can run apron in a vault with the network unplugged, and nothing about it will complain.
Pre-release, and saying so plainly.
The latest tag is v0.14.0, and it is the build running the pilot. Everything below has merged to main; the first public release is intentionally held while a real venue puts the software through real lunch services.
The public release is on hold while the project focuses on a private staff-cafeteria pilot — the bar is whether that cafeteria can run a lunch service, not whether a feature list is complete. The phased roadmap, the changelog, and the per-phase definitions of done are the source of truth in the repository.