Not a drive. A base.

The model in one minute

What you can build

Everything below is just the same primitives composed — state = files, logic = a triggered script. If you can express it as "some files + a script run on a schedule / on change / on demand", you can build it.

Install the CLI

The CLI is a single self-contained binary (no runtime needed). The installer detects your OS/arch and puts capora on your PATH.

1 · Install

# installs the capora binary to /usr/local/bin (sudo fallback → ~/.local/bin)
curl -fsSL https://capora.cc/install | sh

capora help
capora update     # upgrade later, in place (sudo if needed)
# Windows: download https://capora.cc/dl/capora-windows-amd64.exe onto your PATH

2 · Sign in

Get a token from the web console — sign in, open Connect an agent, and generate one (starts with cpt_). Then hand it to the CLI, easiest first:

# 1 · recommended (esp. for agents): save the console token to ~/.capora/config
capora login --token cpt_xxxxxxxxxxxxxxxxxxxx

# 2 · or, stateless (CI / ephemeral shells) — nothing written to disk
export CAPORA_URL=https://capora.cc
export CAPORA_TOKEN=cpt_xxxxxxxxxxxxxxxxxxxx

capora whoami                      # confirm: user + Space + server

Using the CLI

Capora is a netdisk: your Space is a remote filesystem you operate on directly with S3-style commands. Remote paths are written remote://<space>/<path>; anything without that prefix is a local path. There's no pull/save dance — every write is versioned automatically. (Want git semantics on your own machine? Just use git.)

Copy files up, down, and around

capora cp ./apps/todo remote:///apps        # upload a folder → remote apps/todo/
capora ls remote:///apps                    # browse the remote tree
capora cp remote:///apps/todo/app.js ./     # pull one file down
# …edit ./app.js with any tool…
capora cp ./app.js remote:///apps/todo/     # push it back → a new save point

Omit the space (remote:/apps) to use your default Space from ~/.capora/config. Directory copies are rsync-style: cp apps/todo remote://…/apps keeps the todo name; a trailing slash on the source (cp apps/todo/ …) copies its contents. cp only adds/overwrites — it never deletes remote files.

Every command

Global: --space <space> to target a Space from anywhere. Env: CAPORA_URL, CAPORA_TOKEN, CAPORA_PROJECT. Run capora help for the built-in cheat sheet.

Starter kits — pull & go

Don't start from zero. A starter is a whole-Space scaffold (workflows + scripts + folders + a README) you pull, review, and upload. init lays it at your current directory including .capora/, so uploading it turns your Space into a running system.

capora starters                             # list official starter kits
capora init daily-brief --dir ./brief
cd brief && capora cp . remote:// -m "init daily-brief"
capora run daily-brief                       # fetch → summarize (Claude Code) → deploy a site

daily-brief fetches your sources, summarizes them with Claude Code, and deploys a dated brief to /x/<you>/brief (bring your own key: capora secret set ANTHROPIC_API_KEY …; works key-free with a placeholder). Starters ship with manual triggers — arm a cron yourself per the README (no surprise container spend).

Workflows

A workflow is a file at .capora/workflows/<name>.json: a trigger plus one entry script.

# .capora/workflows/nightly.json
{
  "on": { "schedule": "0 3 * * *" },   // or {"change":"data/**"}, or omit for manual
  "run": "scripts/nightly.sh"          // a script in your Space
}

Triggers: manual (capora run), change (on.change path globs, fired on matching saves), and cron (on.schedule, 5-field UTC). Jobs run asynchronously, so long builds are fine.

The runner container ships node/python/git, the capora CLI, and Claude Code (claude) — pre-configured — so a workflow can do AI steps (edit files, review a diff, gather data, generate content) then capora cp the result back. No key setup: runs route through Capora's AI gateway on a per-Space key, all permissions are bypassed by default, and a built-in capora skill lets claude read/write your Space. Just call it headless: claude -p "…".

Agent automations: keep the task's intent as a plain-language brief at .capora/automations/<name>.md and make the workflow's script a one-liner — claude -p "capora session start, then read .capora/automations/<name>.md and do exactly what it says, saving output back with the capora CLI". The agent logs in with a session (required before any write), then does the fetching, generation, error-handling and write-back; since the brief is a Space file, it can even refine it across runs.

Deploy an app

Deploying is just a workflow that builds your app and calls capora app deploy. Scaffold one from a template locally, then copy it up:

capora app templates                       # list official templates
capora app init myapp --template vite-react-tailwindcss-shadcn
capora cp ./myapp remote:///apps       # upload → the change workflow builds + deploys
# → live at https://capora.cc/x//myapp

app init writes an app folder with a capora.app.json (declares an assets directory and/or a worker entry), a deploy.sh, and a change-triggered workflow. On save the workflow builds in a container and hands the artifact to the platform, which uploads a Worker + real static assets — your build never holds any cloud keys.

Deploys are workflow-driven. You can't publish from your machine directly — the platform only accepts a deploy from inside a workflow run, so what ships is always a committed Space state (every deployment ties to a save point). Publish by saving (capora cp ./myapp remote://<you>/apps) → the on.change workflow deploys; re-deploy the current save with capora run <deploy-workflow>.

Templates: vite-react-tailwindcss-shadcn, static-basic, worker-api, fullstack. One app can be a static site (assets only), a backend API (worker only), or full-stack (both — a worker for /api/* plus static assets).

App SDK — talk to your Space from app code

A deployed app can read/write its own Space and trigger workflows from inside its Worker — via a zero-dependency SDK. This is what turns an app into an inbound gateway: receive a webhook/request, drop a file (fires an on.change workflow) or call one directly.

# vendor the SDK (single ESM file) into your app, then build/bundle it
curl -fsSL https://capora.cc/sdk/capora.js -o capora.js

// worker.js — inside a deployed Capora app
import { createClient } from "./capora.js";
export default {
  async fetch(req, env) {
    const capora = createClient(env);              // reads injected CAPORA_URL/SPACE/TOKEN + service binding
    await capora.write("events/hit.json", JSON.stringify({ t: Date.now() }));
    await capora.run("process");                    // trigger a workflow
    const cfg = await capora.read("config.json");    // read a file
    return new Response("ok");
  }
};

On deploy, Capora injects a Space-scoped token (read/write files + trigger workflows — never your secrets or other Spaces) plus a service binding, so createClient(env) just works. API: list · stat · read · readBytes · write · remove · mkdir · workflows · run · runs. TypeScript types at https://capora.cc/sdk/capora.d.ts. Outside an app (Node, etc.) pass createClient({ url, space, token }).

Agents — .capora/AGENT.md

A Space is a home base for you and your agents. .capora/AGENT.md is the file every agent reads first when it docks in — the equivalent of CLAUDE.md / AGENTS.md in a repo, but living inside the Space so it travels with the data and is shared across every framework (Claude Code, Codex, pi, …). It is a plain file — nothing special server-side; create it and cp it up.

Put in it whatever an agent needs to work here safely:

# create the contract, then cp it up (the CLI syncs .capora/ as normal content)
capora cp .capora/AGENT.md remote://<space>/.capora/AGENT.md

Layout is per-Space: different Spaces can define entirely different structures — the only rule is that AGENT.md describes the layout that Space actually uses, and agents honor it. When docking, an agent should read .capora/AGENT.md before acting; if it references Skills, list .capora/skills/*/SKILL.md and read each description to decide what applies.

Paths & API

Pages

HTTP API — account

Auth is a bearer token: Authorization: Bearer <CAPORA_TOKEN> (or the cap_sess cookie in the browser).

HTTP API — a Space

All under /api/p/<owner>/<space>/. Reads on a public Space need no token.

Database

Capora runs on TiDB (MySQL-compatible). Every table is cap_-prefixed; IDs are short prefixed strings. File bytes live in R2 (deduped by sha256) — the DB keeps only metadata.