Ship a device
like you ship code.

The arda command line treats a fleet the way git treats a repository: a project you init, releases you push, targets you deploy to, and a history you can walk backwards when a Friday deploy goes wrong.

Preview — command surface not yet final
01 / The loop

Four commands
you'll actually use.

Most days are the same shape: change something, push it, put it in front of a few devices, watch what happens. The rest of the surface exists for the days that aren't.

  1. 01
    arda pushBuilds your project, bundles it, signs and encrypts the package, uploads it as an immutable release.
  2. 02
    arda deployPoints a target — a device, a group, a channel — at a release. Optionally in waves, with a pause between them.
  3. 03
    arda statusShows what each device is actually running, when it last checked in and what it's stuck on.
  4. 04
    arda rollbackSends the previous known-good release back down the same path, at the same speed.
~/order-kioskarda cli
$ arda status FLEET order-kiosk · channel stable · release r-240 DEVICE GROUP RELEASE STATE SEEN af-0c41d9 north r-240 online 4s af-118a72 north r-240 online 11s af-2b90fe south r-239 stale 2h 14m af-77c015 south r-240 offline 3d $ arda deploy r-241 --staged wave 1/3 · 4 devices ok wave 2/3 · 8 devices ok wave 3/3 · 1 offline, will take it on next check-in
fleet linkedARDA CLI · PREVIEW
02 / Surface

The
commands.

A small surface, deliberately — there is a portal for the things a terminal is bad at. Every command works against the fleet your workspace is linked to, or an explicit --fleet.

CommandPurposeTypical use
arda loginAuthenticate this machine against your accountOnce per workstation
arda initScaffold a project and its arda.json manifestNew application
arda pushBuild, sign, encrypt and upload a new releaseEvery change
arda deployRoll a release out to a target, optionally in wavesShipping
arda statusShow what each device is running and when it last checked inDaily
arda rollbackSend the previous release back down the same pathWhen it goes wrong
# .github/workflows/release.yml
steps:
  - uses: actions/checkout@v4

  - name: Build application
    run: npm ci && npm run build

  - name: Push release
    env:
      ARDA_TOKEN:    ${{ secrets.ARDA_TOKEN }}
      ARDA_PACK_KEY: ${{ secrets.ARDA_PACK_KEY }}
    run: arda push -m "$GITHUB_SHA"

  - name: Deploy to beta
    run: arda deploy --channel beta --staged
03 / Automation

Made for
a pipeline.

Every command is non-interactive by default, authenticates from an environment token, exits non-zero on failure and speaks --json when you'd rather parse than read. Signing keys stay yours: the control plane never holds a private key, so a compromised account can't sign a package on your behalf.

Token auth

ARDA_TOKEN in the environment. Scoped per fleet, revocable, never written to the repo.

Local signing

The pack key signs on your machine or your runner. It is never uploaded, and the server never needs it.

04 / The inner loop

ArdaLive,
for VS Code.

The CLI is the outer loop — build it, sign it, put it on two hundred machines. The inner loop is the twenty seconds between changing a colour and wanting to see it, and a full page reload there is worse than useless: it throws away the state you spent four clicks getting into.

ArdaLive is our live-preview extension for exactly that. It diffs the <head> and <body> and patches the live DOM in place, so scroll position, focus, video playback and the form you're halfway through typing all survive the edit. Linked stylesheets hot-swap without a flash. It serves your unsaved editor buffer, not the file on disk.

We wrote it to make designing device interfaces less painful — a kiosk screen is usually several steps deep into a flow, and reloading to check a change costs you all of it. Then it turned out nothing about that is device-specific, so it shipped as a standalone extension instead: free, MIT, and just as useful on an ordinary website. You don't need ArdaForm to get something out of it.

ArdaLivevs code
ArdaLive listening on http://localhost:8242 workspace ~/order-kiosk · 1 client connected 12:04:02 edit src/screens/order.html morphed <body> — scroll, focus and inputs kept 12:04:09 edit src/style.css swapped <link> via blob url — no flash 12:04:21 edit src/screens/order.html (unsaved) morphed <head> + <body>
idiomorph · localhost onlyv1.4.0 · MIT
!
Preview status The CLI is being finalised alongside the portal. Command names, flags and output shapes on this page describe the intended surface and may change before the first public release — design your pipelines against the shape, not the exact strings. The device-side half of this workflow (release download, verification, staging and reporting) is already implemented and running.
Early access

Want the CLI
when it lands?

The portal and CLI open together. Put your name down and tell us what you're building — it genuinely affects what we finish first.