Skip to content
β—‡ AirawatOS Developer
🚧 Under development β€” this portal is being built track by track. Content will keep growing, and some sections are still placeholders.

Get Started

Quickstart β€” your first solution (Hello World)

Build, publish, and install a tiny working solution on AirawatOS in about ten minutes β€” first the fast, AI-assisted way, then the same thing by hand so you can see every moving part.

This quickstart uses Studio, the platform's own in-browser build workspace β€” no toolchain to install, and you never touch the servers; the platform certifies, delivers, and runs your work for you. Prefer to build in your own editor? The same lifecycle runs from the command line β€” see the aos CLI quickstart. Studio and the CLI are two front doors onto the same governed pipeline; use whichever fits you.

Before you start

That's the whole mental model. Now let's build it.

The fast path β€” with the AI copilot

Studio has a built-in AI assistant, the Solution Expert, that helps you go from a sentence to working, certified components.

"A simple app that greets the signed-in user and shows which tenant they're in."

The assistant proposes a small set of components for your goal and can scaffold them into your project β€” each with a valid meta.yaml and a runnable starting point.

You just used the full lifecycle: describe β†’ generate β†’ test β†’ publish β†’ compose β†’ install. Everything you built is signed, sandboxed, and traceable, without you wiring any of that up.

The same thing by hand

The AI path did a few things for you. Here's what actually happened underneath β€” do it yourself once and the platform stops feeling like magic.

1 Β· Add a component

In your project's explorer, right-click a layer β†’ οΌ‹ New and pick a kind (app for our greeter). Studio scaffolds it: a folder with a meta.yaml and a starting entrypoint.

2 Β· Fill in the description file (meta.yaml)

meta.yaml is your component's contract β€” its identity and everything it's allowed to touch. A minimal app:

component_id: ds:<your-developer-id>:app/hello-world   # its unique, resolvable name
kind: app
version: 0.1.0
entrypoint: index.html      # apps ship a web page; the bundle lives under dist/
reads:  []                  # this greeter needs no governed data
writes: []                  # …and writes none

For an app this is just identity β€” a greeter touches no governed data. A driver or engine touches more (data it reads / writes, outside sites it may call, secrets it needs), but you don't hand-write those lists: you write the code against ctx, and aos check (or Studio) derives them into meta.yaml for you. See What your code can touch and Anatomy of a component.

3 Β· Write the code

For our app, edit dist/index.html β€” a plain page. It reads the platform-provided config (which tells it the signed-in user's tenant) and says hello:

<!doctype html><meta charset=utf-8>
<h1 id=greeting>Hello…</h1>
<script>
  fetch('config.json').then(r=>r.json()).then(c=>{
    document.getElementById('greeting').textContent = 'Hello β€” you are in tenant ' + (c.tenant || 'unknown');
  });
</script>

An app holds no authority of its own β€” it acts as the signed-in user and reaches data only through the platform, never a side channel. A driver or engine instead has a run.py: a driver marks its entrypoint with @driver.main (it runs to completion); an engine marks each action with @engine.verb. Both do all their I/O through the one ctx surface β€” backed by the broker, the single guarded door described in Zero-Trust Architecture.

4 Β· Test, publish, compose, install

The rest is the same as the fast path, just done by clicking rather than chatting:

Open it, and you've hand-built your first solution.

What you just learned

Where to go next