ArdaForm
Portal Early access

From bare metal
to a managed
appliance.

Building the application is the easy half. The hard half is the four hundred hours a year spent installing Linux on machines, chasing a device that won't come back after a power cut, and driving to a site because nobody can see what the screen is showing.

USB installer imageStable device identityActivation codesGroup configurationStaged rolloutsHash-verified updatesRollback
01 / Provisioning

One boot,
one appliance.

The installer image is designed so that turning hardware into a device is a task you can hand to somebody who has never opened a terminal.

  1. 01 Boot

    Start from USB

    Write the image once, use it on every unit. Boot the target machine and choose a device profile — kiosk, till, signage or headless controller. The profile decides which display, input and peripheral components get installed.

    Planned
  2. 02 Prepare

    Install the system

    A minimal Debian base goes down with only what the profile needs: no desktop environment, no display manager, no package set nobody asked for. ArdaPlayer is installed and wired to start on boot, with the machine configured to come back on its own after a power cut.

    Planned
  3. 03 Claim

    Register the device

    On first boot the installation derives a device ID from the machine — stable across reboots, unique per unit — and shows an activation code on screen. Claim it against your account from the portal or with arda claim, and it inherits its group's configuration immediately.

    Working
  4. 04 Run

    Pull the application

    The device downloads the release assigned to its group, checks the SHA-256, verifies the signature, decrypts the bundle and restarts into your interface. From here on it is a managed appliance: it dials home, reports its hardware and waits for instructions.

    Working
i
Already have machines running Linux? You don't need the installer image. ArdaPlayer can be installed onto an existing Debian-family system and registered the same way — the image exists to remove the manual work, not to gate the platform.
02 / Updates

The device owns
the update.

The control plane never pushes bytes into a device. It names a URL and a hash; the device decides whether to trust what comes back.

A / Instruct

Named, not pushed

One small message on the control channel: kind, URL, version, SHA-256.

B / Fetch
GET●

Device downloads

Over HTTPS, outbound, on the device's own schedule and its own connection.

C / Verify
✓

Hash & signature

Mismatch on either and the update is discarded. The running app is untouched.

D / Apply

Stage & report

Staged, swapped at a safe moment, and the outcome reported back with a status.

SHA-256 enforced Signature verified Previous release retained

Application releases

A new .arda package. Verified by fully decrypting it before it is allowed near the live slot.

Runtime updates

A new ArdaPlayer binary, Ed25519-signed by the release pipeline, applied atomically with the old one kept for rollback.

Configuration

Per-device and per-group settings delivered separately from code, so a site tweak doesn't need a release.

Offline devices

A device that was unplugged during a rollout picks the update up the moment it reconnects. Nothing is lost.

03 / Control

Not everything,
not all at once.

Shipping to every device simultaneously is how a small bug becomes a company-wide outage. ArdaForm rollouts are targeted, staged and reversible by default.

  1. 01
    ChannelsDevices subscribe to dev, beta or stable. Promote a release between them instead of rebuilding it.
  2. 02
    GroupsSlice the fleet by region, customer, site or hardware type, and deploy to a slice.
  3. 03
    WavesShip to a fraction, wait, check the error rate, continue — or stop.
  4. 04
    PinningHold a device on a known release when a site can't take a change this week.
  5. 05
    RollbackThe previous release is retained on the device. Going back is a message, not a reinstall.
rolloutstaged
$ arda deploy r-241 --group north --wave 25% --pause 10m target 24 devices · 3 offline · 1 pinned release r-241 sha256 4f9c…a10e · 1.84 MB wave 1 ■■■■■■░░░░░░░░░░░░░░░░░░ 6/24 ok holding 10m — 0 errors reported wave 2 ■■■■■■■■■■■■░░░░░░░░░░░░ 12/24 ok wave 3 ■■■■■■■■■■■■■■■■■■░░░░░░ 18/24 ok wave 4 ■■■■■■■■■■■■■■■■■■■■■░░░ 21/24 ok ✓ 21 applied · 3 queued for reconnect · 0 failed
rollout r-241COMPLETE
04 / Support

Answering
"it's broken again".

Every one of these exists to replace a site visit. Together they are the difference between a device business that scales and one that turns into a driving job.

See the screen

Capture the current frame, or watch a low-rate stream that updates when the display changes. No more "can you photograph it and send it to me?"

Read the console

Stream the application's own log lines with levels and timestamps, live, while the customer is still on the phone.

Inspect the state

Evaluate JavaScript inside the running page and read the DOM — find out what the app actually thinks is happening.

Check the hardware

Distribution, kernel, CPU, memory, disk, network interfaces and the full USB inventory, refreshed on every connect and every plug event.

Get a shell

An operator-initiated reverse tunnel gives real SSH to a device behind NAT, multiplexed over the connection it already holds open.

Restart cleanly

Restart just the application when that's enough, and reboot the machine when it isn't — without asking someone to find the plug.

Next

How it's
kept safe.

Devices sit in places you don't control, run code you care about and hold data that matters. Here's what the platform actually does about that.

Read the security model Device protocol