Orgo templates and triggers: reproducible cloud computers for AI agents

An Orgo template is a declarative spec for an Orgo cloud computer. One file in the orgo.ai/v1 format describes the hardware, the software to install, the services to run, the secrets it needs, and what the user sees on connect. Orgo builds that file once into a golden snapshot, and every computer launched from it starts with that setup already in place, the same way every time (Templates).

Triggers live in the same file and make the computer react to what happens on it: a source such as a cron schedule, a file change, a log line, or a desktop event fires, and actions such as a webhook, a shell command, or a service restart run in response (Triggers). The curated Coding, OpenClaw, and Hermes Agent templates launch on any paid plan, or by the hour on a free account's credit. Publishing your own requires a Scale plan or higher.

What is an Orgo template?

The docs describe it as a Dockerfile for a full desktop computer: write it once, version it, and hand out reproducible computers from it (Templates). The difference from a container is that the result is a whole computer with a desktop, a browser, and the standard userland, reachable over HTTP and VNC, which is what computer use agents need to operate real software (llms.txt). Templates build Linux computers.

Every template version has a ref in the form namespace/name@version, for example system/coding@1.0.4 for a template Orgo curates or default/claude-code@1.0.0 for one you publish. Publishing different content under a version that already exists returns 409, so a published version stays as it is unless you deliberately replace it (see the FAQ below). You pass the ref as template_ref when you create a computer.

Why use a template instead of a base image and a setup script?

Without a template, every new computer starts from a base image and you script the setup yourself, and that script drifts over time. A template moves the setup to build time (Templates).

Source: Templates.

How does a golden snapshot work?

When you build a template, Orgo boots a real computer, runs your install steps, then pauses it and captures its full state (disk, memory, and CPU) as a golden snapshot. Launching from the template copies that snapshot and resumes it, so the computer comes up with your packages installed and your services already running (Templates).

Three properties follow from that design:

• Build once. You rebuild only when the template changes.
• No install at launch. A launch restores the snapshot instead of running your install steps again.
• Content-addressed. The snapshot is keyed by a SHA-256 digest of the canonical template, and changing one byte of the template produces a new digest.

One caveat: a launch that injects secrets, or lands on a host that cannot restore the snapshot's memory, cold-boots from the snapshot's disk instead. Your packages are still installed, but processes start fresh and the on_every_boot hook runs (Templates).

What goes in a template?

Sources: Templates and Template schema. Services declared under apps are managed by supervisord, so they start at boot and respawn on crash (Template schema).

Here is a minimal template in the short sugar form. Everything except api_version, the name, and the version is optional (Examples):

api_version: orgo.ai/v1
name:    my-template@1.0.0
cpu:     2
ram:     4gb
display: 1280x800

What are Orgo triggers?

A trigger pairs a source that produces events with one or more actions that run in response, plus optional dedup to suppress noise. Each trigger needs a unique name, a source, and at least one action. Triggers run continuously inside the computer, and a template can declare up to 256 of them (Triggers).

Actions are webhook (an HTTP request out), command (a shell command as root), service (start, stop, or restart a declared service), notify and log (lines in the trigger log), and api (a call to the computer's Desktop API) (Triggers). String fields can use placeholders such as {{trigger}}, {{time}}, and {{data.path}}, written without inner spaces.

For example, this trigger posts to a Slack webhook whenever a file lands in an inbox folder (Triggers):

triggers:
  - name: new-upload
    source:
      type: file
      path: /data/inbox
      events: [create]
    actions:
      - type: webhook
        url: https://hooks.slack.com/services/...
        method: POST
        headers:
          Content-Type: application/json
        body: '{"text": "new file: {{data.path}}"}'

Each trigger can use one dedup strategy: debounce, cooldown, or rate_limit (for example 10/1m). Separately, a trigger fires at most 120 times a minute (Triggers).

When should I use a trigger and when a health check?

They complement each other. A health check is a per-app watchdog: it probes one URL, port, command, or process and can restart a service after repeated failures. A trigger is general automation, any source to any action across the whole computer. Use a health check to keep a service alive, and a trigger to react to files, schedules, metrics, or desktop activity (Triggers).

How do templates handle API keys and secrets?

A template declares the secrets it needs by name only. The person launching a computer stores each value once in their Orgo vault, and at create time Orgo writes the matching secrets into the computer at /root/.env with mode 0600, under their uppercase names, so anthropic_api_key becomes ANTHROPIC_API_KEY. The value never lives in the template, the registry, or the golden snapshot, and build logs never print it (Secrets).

A template carries no one's keys, so the same template works for every computer launched from it, each with the keys of whoever launched it. A launch never fails over a missing secret; the variable is simply absent.

How do I launch or publish a template?

To try a curated template, pass its ref as template_ref when you create a computer. system/coding@1.0.4 boots with Claude Code and Codex already installed, each in its own terminal session (Templates quickstart):

curl -X POST https://www.orgo.ai/api/computers \
  -H "Authorization: Bearer $ORGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"workspace_id\": \"$WORKSPACE_ID\",
    \"name\": \"claude-1\",
    \"template_ref\": \"system/coding@1.0.4\"
  }"

From the CLI, orgo templates run system/coding@1.0.4 --name claude-1 does the same. Orgo also curates OpenClaw and Hermes Agent templates; List curated templates returns the current refs. On a free account, add "billing_mode": "hourly" to the request to run the Coding, OpenClaw, or Hermes Agent template by the hour on your credit.

Your own templates take four steps on a Scale plan or higher. The paths below are under https://www.orgo.ai/api (Templates quickstart):

1. Write the file in YAML or JSON.
2. Validate it with POST /templates/validate, which stores nothing and returns 422 with field-level errors when something is wrong.
3. Publish and build with POST /templates?auto_build=true, then poll GET /templates/{namespace}/{name}/{version}/build until status reads ready.
4. Launch with POST /computers and your template_ref.

Who are templates for?

Templates fit any team that hands out many identical computers: one per AI worker, one per end user, or one per client. When every user gets their own computer, see How to scale AI agent computers to thousands. When you run Orgo for clients, see Invoicing.

What are the limits today?

These are the current edges as of October 2026, and it is better to know them before you build:

• Publishing, building, and test-running your own templates require a Scale plan or higher; below it they return 403 with UPGRADE_REQUIRED. Launching a template is a normal computer create: it needs a paid plan and counts against the workspace owner's computer quota. A free account can still launch the curated Coding, OpenClaw, or Hermes Agent template by the hour on its credit (Templates).
• Templates larger than XL (more than 6 vCPU or 32 GB of RAM) are set up on request. Publishing, building, or test-running one returns 403 with CONTACT_US_FOR_SIZE until Orgo sets your account up for larger computers.
• Only two hooks run: on_first_boot, once during the build, and on_every_boot, on each cold boot. on_pre_snapshot, on_resume, and on_shutdown pass validation but do not run (Template schema).
• Some trigger sources pass validation but never fire, including the GPU metrics and the idle and active desktop events. The api trigger action does not send the Desktop API token, so routes that need it return 401 (Triggers).
• A health check on_fail of restart_vm or alert only writes a log line. Only restart_service acts (Template schema).

FAQ

Is an Orgo template the same as a Docker image? No. The docs compare it to a Dockerfile, but the output is a full desktop computer captured as a golden snapshot of disk, memory, and CPU state, not a container image (Templates).

Can I change a published template? Bump the version to ship a change. While you are still iterating, re-publish the same version with ?auto_build=true&force=true to replace it and build a fresh snapshot (Templates quickstart).

Can I make a template computer bigger at launch? Yes. cpu and ram in the create request override the template's defaults, up to your plan's per-computer limit; a value above it returns 403 (Templates quickstart). Sizes past XL (more than 6 vCPU or 32 GB of RAM) are set up on request.

Do triggers need an outside scheduler? No. Triggers run inside the computer, managed by Orgo, so they fire while the computer is running (Triggers).

Related

• What is computer use?
• Best hosting for OpenClaw and Hermes Agent
• How do you pause, fork, or clone an AI agent's computer?
• Cloud desktops vs. headless browsers