ArdaPlayer is the program that turns a Linux box into your product. It boots, shows your logo before the system has finished starting, opens your sealed application in memory, paints it straight on the display with no desktop underneath, and hands the page a controlled door into the hardware. You write the page; ArdaPlayer looks after the machine.
There is no desktop, no window manager to fight and no browser chrome for a customer to poke at. The machine powers on and the application is simply there — with your logo on the panel from about a second in.
Ardacog, on the DRM card. No desktop, no window manager, nothing else running..arda is opened into memory — never onto the disk — and window.Arda is in the page before your first line runs.Electron is an excellent way to ship a desktop application to people who own their computers. An appliance in a shop is a different problem, and the trade-offs go the other way.
| Concern | Typical Electron app | ArdaPlayer |
|---|---|---|
| Rendering engine | Private Chromium bundled per application | WPE WebKit through cog on the fleet; the system WebKitGTK on a Linux desk |
| Display stack | A desktop session underneath | The bare DRM card. No X, no compositor, no desktop to escape to |
| Application code | ASAR archive — readable and extractable | A sealed .arda packed by ArdaForm, opened in memory only |
| Native access | Full Node.js API surface in the main process | window.Arda — a narrow bridge over loopback, a fixed list of things a device does |
| Target hardware | Developer and consumer machines | Raspberry Pi, low-power x86 terminals and panel PCs |
| Updates | Per-application updater the user consents to | Pushed as a signed instruction; the app picks the moment; the player updates itself the same way |
| Fleet management | Not in scope | Registry, snapshot, log capture, screen view, console and SSH built in |
// window.Arda is there before this line runs — no import
const d = await Arda.device()
console.log(d.hostname, d.model, d.can)
// 'arda-tablet' 'Raspberry Pi 4 Model B'
// {screen: true, touch: true, keyboard: false, …}
// Settings the operator set in the portal — a plain object
const currency = Arda.config.currency ?? 'GBP'
// Lay the screen out for the machine it is on
if (d.can.touch && !d.can.keyboard) {
const pin = await Arda.keyboard({ layout: 'pin', title: 'Staff PIN' })
if (pin !== null) unlock(pin)
}
// The hardware, through the same object
const [printer] = await Arda.printers.list()
await Arda.printers.print(printer.id, escpos(receipt)){
"window": "1280x800",
"scale": "75%",
"console": true,
"watch": true,
"can": { "touch": true, "keyboard": false, "mouse": false },
"screens": [
{ "name": "main", "primary": true },
{ "name": "customer", "size": "800x480" }
],
"device": false
}Your page gets one extra object, window.Arda, and through it a fixed list of things a device does: its data, its settings, its printers and serial ports, its screens and speakers, its cameras, its readers, its Wi-Fi, its power — and webhooks to your own servers, which ArdaForm calls on its behalf. It does not get free access to the disk, a shell, or raw network sockets: on the page's behalf the player connects only to ArdaForm and to the cameras the app names. A third-party script bundled into your app cannot quietly do something to the hardware the app itself cannot.
Under the hood there is exactly one definition of window.Arda, injected before the page's own scripts. It rides a loopback server rather than engine bindings, which is why the API is identical in developer mode, in the kiosk, and with no screen at all — ardaplayer -headless evaluates the same source with no DOM. arda.dev.json sits beside app/: plain JSON, read only in developer mode, never packed.
Both arrive the same way — a signed instruction addressed to that one device, naming the fingerprint (SHA-256) of what to fetch — and both are checked on the device before anything changes. There is nothing for you to schedule.
A new app is fetched, hash-checked, opened to prove the key agrees, and staged. The page is told. Five seconds of silence and it reloads; an app mid-sale can pause it for a minute, five times, and the update waits for the next restart if it never agrees.
A new player binary is fetched, checked against the signed hash, run once to prove it starts, and armed for the next restart. Three starts that die in a row put the previous binary back.
A branch can be set to apply at once, inside a time window in the device's local time, or only when the app asks. The device decides the moment; the operator can override it from the portal.
One pure-Go binary per architecture, cross-compiled in seconds. If Linux boots on it and the kernel can drive its display, ArdaPlayer draws on it. On Android it is an app: the same player inside a small shell, one download for every box.
Mini PCs, box PCs and repurposed point-of-sale terminals — a Bay Trail till is the reference machine. Installed from the USB stick or the PC image.
amd64WorkingPi 3 and Pi 4, HDMI or DSI. One image serves both: it probes for the panel at boot. The DSI tablets are in production.
arm64WorkingCapacitive panels, customer-facing displays, cash drawers and thermal printers on an AURES till and the Pi tablets.
peripheralsWorkingA Linux desktop build with the inspector, and Windows and macOS builds that open the app in your browser — the same API, for building the page.
-devWorkingThe same player as an Android app, Android 7 or newer: a tablet beside the till, activated with the same code, its Wi-Fi printers and battery in the portal — and kiosk mode when the player is the box’s device owner.
apkWorkingMany commercial screens and most TV boxes run Android: the player runs on the screen you already have, with no Raspberry Pi behind it — 64-bit and 32-bit ARM and x86-64 in one app. Installing it.
arm64 · armv7 · x86-64WorkingDatasets, the outbox, settings, the on-screen keyboard, screens and audio, cameras, printers, serial, readers, Wi-Fi, power and webhooks — all from ordinary JavaScript.