ArdaQuickstart
Project layout, manifest, your first package, and getting it running on a device.
Read →Preview
Documentation.
Everything needed to build an ArdaForm application, package it, get it onto a device and manage it once it's out there. Written for developers who have shipped software before and don't need the browser explained to them.
Preview — APIs and CLI may still change before 1.0
Start here
ArdaForm has four moving parts. If you read nothing else, read the platform overview to understand how they fit together, then the quickstart to build something.
Package format
What a .arda file contains, how it's signed and encrypted, and how binding works.
Read →Working
JavaScript API
The full arda.* surface — storage, sync, network, printers, camera, GPIO, USB, system.
Read →Preview
arda CLI
Every command, flag and exit code for building, pushing, deploying and supporting.
Read →Preview
Device protocol
The wire format between a device and the control plane: messages, updates, tunnels and sync.
Read →Working
Security model
Threat model, key handling, capability scoping and what we explicitly don't claim.
Read →Working
Core concepts
Five terms appear throughout the documentation. They're worth getting straight before anything else.
| Term | Meaning |
|---|---|
| Application | Your HTML, CSS and JavaScript, plus the arda.json manifest that declares its name, entry point and capabilities. |
| Package | The built artefact — one signed, encrypted .arda file. Immutable once produced. |
| Release | A package uploaded to the control plane and given an ID. Releases are never rewritten; you push a new one. |
| Device | One installation, identified by a stable ID derived from the machine. It belongs to a fleet and optionally a group. |
| Fleet | The set of devices running one application, sliced into groups and subscribed to channels such as beta or stable. |
Reading the status labels
Documentation on this site describes a platform under active development. Every API group and command carries one of three labels so you always know what you're looking at.
- Working — implemented and running on deployed hardware. Behaviour described here is behaviour you get.
- In progress — partially implemented and actively moving. The shape is right; details may shift.
- Planned — designed and documented so you can architect around it. Not implemented. Do not ship against it.
!
Access
The portal and CLI that these pages describe are not open for public sign-up yet. The documentation is published so you can evaluate the platform properly before committing to it — request early access to get an account.
Conventions
Code samples assume top-level await, which ArdaPlayer supports in the application entry module. Anywhere arda appears, it is the global namespace the runtime injects — you never import it. Shell samples use $ for a workstation prompt and # for a device shell.
Error handling is omitted from most samples for brevity. In real applications, every hardware call can fail — a printer runs out of paper, a camera is unplugged, a pin is already claimed — and every rejection carries a stable code you should branch on.