Documentation
Everything you need to get started with ooda.
Also available as plain markdown for LLMs.
Getting started
ooda lets your team publish prototypes, tools, and sites to the web safely, from any agent. One command signs you in; ooda publish ships your built site to a private, shareable URL.
Quick start
$ curl -fsSL https://ooda.run/install | sh
$ ooda macOS and Linux. No Node.js needed.
$ npm install -g @oodarun/cli
$ ooda Node.js 20+. Works on Windows.
The first time you run it, you'll be asked to sign in with your email. If you're part of an organization, you'll join your team's org automatically. If you belong to several orgs, run ooda orgs to see them and ooda switch <org-id> to choose one. From a built site, run ooda publish to ship it.
ooda.json
ooda.json is the site configuration file. ooda publish reads the site's metadata from it, and writes the site's addresses back into it.
Example
{
"name": "My Cool App",
"description": "A React dashboard for analytics",
"tags": ["dashboard", "react"],
"color": "#0f766e"
} Fields
name
Human-readable site name (e.g. "My Cool App"). Shown in the dashboard instead of the site slug when set.
description
Short description of what the site is. Shown in the dashboard alongside the name.
tags
Keyword tags for the published site, used for filtering and search.
color
Brand colour ("#rrggbb"). The dashboard tints the site's card with it.
secrets
A manifest of the env vars and secrets the site needs, so ooda secrets check can prompt for the missing ones.
slug, siteName, urls
Written back by ooda publish — the resolved {slug}.ooda.run address and, when your org has short addresses, the {siteName}.{org}.ooda.run one. Keep them in the file so re-publishes stay on the same URL.
Publishing
Publish a built static site to a gated, shareable URL with a single command: ooda publish.
How it works
- Build your site (e.g.
npm run build) ooda publishdetects the build output directory and uploads it- Your site is available at a
{slug}.ooda.runURL, gated by your access policy
Every publish creates a new version. Previous versions are kept and accessible.
Access control
Every site is gated. By default a site requires a team login; you can make any site public or password-protected, per site or as an org-wide default. Site passwords are encrypted at rest. Manage access from the dashboard or with ooda sites access.
Supported frameworks
Any framework that produces static output works — Vite, Astro, Next.js (static export), and more. The publish script automatically detects your build output directory (dist, build, out, etc.).
Joining a team
On ooda, sites belong to a team (an organisation). If your team already uses ooda, join their team instead of creating a new one. Only a team admin can add you.
Get an invite
Ask an admin of your team to add you from the Team page in the dashboard. They can do this in two ways:
- Email invite. The admin enters your email address. You get an email with a link to create your account. Sign up with that same address. The invite expires after 7 days.
- Join link. The admin shares a link. Anyone who opens it can join the team, so the admin can limit how many times it works or revoke it.
If you already have an account
One account can belong to several teams. Open the Account page in the dashboard to accept a pending email invite. You must verify your email address first. A join link works the same way: open it while you are signed in.
To choose the team the CLI publishes to, run ooda orgs to list your teams and ooda switch <org-id> to select one.
Waitlist invites
A waitlist invite creates a new team with you as its admin. If you want to join an existing team, do not use it. Ask that team's admin for an invite.
CLI commands
$ ooda publish [path] Publish a built static site to a shareable {slug}.ooda.run URL. Non-interactive; --json supported.
$ ooda sites [list|access|password|delete] List and manage your published sites — set access (public / password / login), reveal a password, or unpublish.
$ ooda secrets [set|list|rm] Manage env vars & secrets for your published sites. --env values reach a site's page as window.__OODA_ENV__; true secrets never reach the browser. No reveal in the CLI — an admin reveals in the dashboard.
$ ooda login · ooda whoami · ooda logout Sign in with an email code (--email/--code for agents/CI), check the current session, or sign out.
$ ooda orgs · ooda switch <org-id> List the orgs your account belongs to, and choose the one that later commands act on. You join another org in the dashboard.
Agent skill
Teach your coding agent (Claude Code, Cursor, etc.) how to use ooda — publishing static sites, managing sites, and authenticating — with the ooda agent skill. The agent can then publish and manage sites on its own, non-interactively. No install is needed — the skill is hosted at ooda.run/skill.md. Tell the agent:
Fetch https://ooda.run/skill.md and follow its instructions. To install it into the agent's skills directory instead (so it loads automatically in future sessions), use the skills CLI:
# Global (all projects)
$ npx skills add toy-studio/ooda-skills -g
# Or per-project
$ npx skills add toy-studio/ooda-skills Source and details: github.com/toy-studio/ooda-skills.
Cloud agents
A cloud agent runs its code in a sandbox, and most sandboxes block ooda by default. Set up the network once for each environment:
- Open the environment settings of the cloud session.
- Set Network access to Custom.
- Add
ooda.runand*.ooda.runto Allowed domains, one on each line. - Select Also include default list of common package managers, so that the agent can install the CLI with npm.
The setting is per environment. It applies to Claude Code on the web, the desktop and mobile apps, and claude --cloud.
- Open the settings of the Codex cloud environment.
- Set Agent internet access to On.
- Choose the Common dependencies allowlist, and add
ooda.runandapi.ooda.run. - Keep all HTTP methods allowed. A publish uses
POST, so a GET-only setting blocks it.
Codex runs a task without you. When the agent asks for the login code, send the code as a follow-up message.
- No setup is necessary. By default, ChatGPT lets its code reach the internet.
- If a request fails, check Settings → Data controls → Work network access. In a workspace, an admin can turn this off.
- Go to Settings → Capabilities.
- Under Code execution and file creation, turn on Allow network egress.
- If the domain allowlist is not All domains, add
ooda.runand*.ooda.runto the additional allowed domains.
On Team and Enterprise plans, an admin controls this setting for the organisation.
Sign in and publish
The sandbox does not keep a session, so the agent signs in with an email code each time. The agent requests the code, you paste it into the chat, and the agent verifies it:
$ npm install -g @oodarun/cli
$ ooda login --email [email protected] --json
$ ooda login --email [email protected] --code 123456 --json
$ ooda publish ./dist --json
A new code cancels the earlier codes, so paste the code from the latest email. If your account is in several orgs, the CLI selects one and lists the others. Add --org <org-id> to the verify step to choose, or run ooda switch <org-id> after it.
In a sandbox, install the CLI with npm, not with the standalone installer. The sandboxes include Node.js and allow the npm registry, and the Node CLI uses the proxy that HTTPS_PROXY names. The standalone binary does not need Node.js, but some sandbox proxies do not work with it. If an older CLI fails with fetch failed, update it, or set NODE_USE_ENV_PROXY=1.