Plenty of platforms describe features that exist only in a slide deck. This page is the corrective: three lists, plainly labelled, so you can tell what you'd actually be building on today. To use anything in the first list, your app needs nothing but HTML, CSS and JavaScript.
These aren't demos. A bakery chain's branch tablets run them in production, alongside the test devices on the bench, which is why the rest of the platform is being built the way it is.
The same player as an Android app for tablets, displays and TV boxes: activation, data, Wi-Fi printers, the battery and the portal’s device page as on Linux, and kiosk mode from the portal on a box set up as device owner. Installing it.
One pure-Go binary for x86-64 and ARM64, WPE WebKit straight on the display, no desktop, logo from the initramfs, restarting cleanly after a power cut.
The GitHub App, a connection per branch, server-side packing into a sealed .arda, a signed instruction per device, staged apply with the app choosing the moment, per-branch policies.
A Raspberry Pi image that serves HDMI and DSI panels, a PC image, and an installer stick that is the player running a touch install app.
An activation code on screen, a same-network Adopt list, Bluetooth with Wi-Fi hand-over for headless boards, install codes with optional approval, Wi-Fi profiles.
Data kept on the device and encrypted there, each device getting only its own share (partition-scoped, gzip on the wire); an outbox that survives power cuts and delivers at least once; synced files checked by hash; settings declared in the manifest and set in the portal.
A setting saved in the portal reaches a running device in about three seconds. A setting can be a list of rows — a set of cameras, say — and a device's settings can be saved as a preset and applied to the next one. On paid plans an app can bring its own settings page, which the portal shows in place of the standard form.
Device, Peripherals, Setup, Alerts & log, Device view with lossless screenshots, SSH, Bluetooth. Brightness, contrast and volume sliders that move the real hardware, and a scale per screen.
RTSP and IP cameras shown on a device's screen: the camera's own video, hardware-decoded where the board can — six at once on a Pi 4 — with a motion-JPEG fallback. Always live; a camera that reboots comes back by itself.
An app calls your own server with one line. ArdaForm makes the request from its servers — signed when the webhook has a key, and optionally verifiable through the API — with every delivery logged; the key never reaches a device.
Every device answers nothing it did not ask for. SSH opens only from the portal, for a set time, and closes itself; keys are installed from the same tab and can expire.
Raw ESC/POS, ZPL, Star, TSPL and ESC/P (dot-matrix) printers over USB, network and Bluetooth; USB-serial; keyboard-wedge barcode, QR and NFC readers; screens by EDID; ALSA audio.
Pushed as a signed instruction, tried once before it is armed, negotiated with the app when it is important, three-start rollback guard, live and test channels.
api.ardaform.net/v1: API keys per project; datasets and records, files, webhooks and their delivery log; a keyless OpenAPI document.
Anyone can create an account on the order page. The free plan needs no card; Basic and Pro are paid by card on the same page. Sign in with a password, or with Google or GitHub.
Live HTML preview for the authoring loop — DOM-patched in place, so scroll position, focus and JS state survive every edit. A separate free extension, not part of the platform, and useful whether or not you ever ship a device.
Designed, partly implemented, and moving. These are where feedback helps most.
| Item | State | What's left |
|---|---|---|
| Android: updates and USB | In progress | The Android player does not update itself yet — a newer app is installed over it, keeping its activation and data — and USB printers, serial adapters and joining Wi-Fi from the activation screen are Linux-only for now. |
| Public Bluetooth setup page | In progress | A device with no network shows ble.ardaform.net (ArdaPlayer v1.2.3), where a phone or laptop gives it a Wi-Fi network over Bluetooth; since v1.2.3 it can also join from its own screen. The always-on version, for a device that is online, gated on the device password, is not built. |
| Marketplace | In progress | Listing an app from a project's Marketplace tab and installing it from the shop front work in the portal. Paid apps are built — priced per device or per install, monthly, yearly or one-off; the seller connects its own Stripe account, the buyer pays it through Stripe's checkout; per-device licences are bought up front, more at any time (charged for the rest of the period) and fewer from the next renewal; an unpaid install is paused on its devices with its data kept — and tested in Stripe's test mode; taking real payments for apps is not switched on yet. A signed licence on each device is in progress. |
| Universal print layer | In progress | A device-independent page model — tables, pagination, media size — on top of the raw printer call. Hardware-proved; one design question open. |
| Per-project boot logo | In progress | The device draws its logo from the initramfs today; delivering a project's own picture there safely is the remaining piece. |
| Second screens on devices | In progress | Since ArdaPlayer v1.1.12 a device with two monitors can show a camera full-screen on the second while the app runs on the first, and the portal chooses which monitor the app is on. It needs a PC-type (x86) device installed from the v1.1.12 images or later (v1.1.14: drawn entirely by the graphics chip there, smooth at 30 fps on a large monitor) — a device that only receives the newer player keeps one screen — and the Raspberry Pi image does not have it yet. A page of the app's own on the second monitor works in developer mode (a second window is a second screen); on a device it is not yet wired. |
On the list, thought through, not yet written. Ordering here is genuinely influenced by what the people using it ask for.
Digital I/O on boards that have it — buttons, relays, interlocks — from the same object that draws the screen. Today a relay hangs off a USB-serial adapter.
Capture and code scanning through a camera attached to the device. Showing a network camera on a screen already works; today a QR flow uses a USB scanner as a keyboard wedge.
On-device detection, enrolment and matching for attendance, with templates that never leave the hardware.
Run the control plane inside your own infrastructure for customers whose procurement rules require it.
Alerts exist per device today. Rules across a fleet — offline, disk filling, printer down — routed to email, webhook or chat.
Drop-in support for scales, payment terminals and NFC readers beyond the keyboard-wedge kind.
Pairing needs an agent to answer a PIN and a till has no keyboard; the narrower case of printers and scanners with a fixed PIN is open.
The next shape after per-frame gzip: diff → compress → one transfer → apply, so a big catalogue resyncs in seconds.
A stick that sets up an unregistered device offline, and one that delivers a data and file update to a device with no network.
An install code that carries device preferences — the serial port a customer display sits on — so a batch of identical devices comes up configured.
The ordering of the planned list is not fixed. If your product is blocked on one specific thing, say so — it moves.
Arda