The cloud is where software lives.
NEBULA is how it ships.
- Plate 04, Evidence, unseals after plates 01, 02 and 03 have each been opened. Plate 04, Evidence, unseals after plates 01, 02 and 03 have each been opened.
01 · agents — opened
Six agents do the work: Planner, Coder, Reviewer, QA, Release, Observer. A work item moves through each in turn — planned, built, reviewed, tested, staged — and every step returns evidence, not promises.
Six of them.
Planner, Coder, Reviewer, QA, Release, Observer. A work item opens and the roles take it in turn: the Planner breaks it into steps, the Coder builds on a branch, the Reviewer checks the diff, QA runs the scenarios, Release stages the candidate, the Observer watches it all. Every role returns the same evidence envelope, so every step is checkable the same way. Successful runs move a work item to review — never straight to done; a failed check sends it back with the reason attached.
Agents are lane-bound: each one sees only its own work and the evidence it was handed. None of them can touch production — that line belongs to the gates.
02 · gates — opened
The rules that govern a release. Whether you already have some of the pieces or none at all, gates apply the same way: production moves only when a person approves it.
Humans decide the risk.
Everything agents do is preparation. The release candidate, the review verdicts, the test evidence, the deploy plan — all of it lands on one line: a person approves, or nothing ships. The approval is a role held by a named human, and every transition is written to an audit trail with who, what and when.
Run the loop any way that fits the risk — human-in-the-loop for every step, agents with checkpoints, or a full loop that stops at the gates. The release moment is identical in all three: a person clicks. That click is the one step Nebula never takes for you.
03 · adapters — opened
You don't choose a stack to join — you bring the one you have. Tracker, repo, cloud, or nothing yet: your app, branches, environments and developers all follow the rules you set, through the tools Nebula connects for you.
Keep your stack. Lose the glue.
There is no stack to pick and nothing to migrate. If you already run on Supabase, Google Cloud, AWS or Vercel, you keep it — Nebula connects to what's there. If you have none of it, that's fine too: your app, branches, environments and developers follow the rules you set either way, because the rules live in Nebula, not in any provider. Every tool is an adapter behind one contract, and the contract is the same for all of them.
The matrix below lists what Nebula speaks today. An entry turns green when its contract suite passes in public CI, and each one links to the run that proved it.
| Workflow | Adapter | Status |
|---|---|---|
| Plan | JRJira | SHIPPED |
| Plan | LNLinear | PLANNED |
| Plan | GIGitHub Issues | PLANNED |
| Code | GHGitHub | SHIPPED |
| Code | GLGitLab | PLANNED |
| Run | AWAWS (EKS / Lambda) | PLANNED |
| Run | VCVercel | PLANNED |
| Data | MAMongoDB Atlas | PLANNED |
| Data | PGPostgreSQL (branch-specific) | PLANNED |
| Data | SBSupabase | PLANNED |
| Build | LVLovable | PLANNED |
| Ops | SLSlack | PLANNED |
Adapter status: Jira is SHIPPED; Linear is PLANNED; GitHub Issues is PLANNED; GitHub is SHIPPED; GitLab is PLANNED; AWS (EKS / Lambda) is PLANNED; Vercel is PLANNED; MongoDB Atlas is PLANNED; PostgreSQL (branch-specific) is PLANNED; Supabase is PLANNED; Lovable is PLANNED; Slack is PLANNED.
04 · evidence — unsealed
Every work item leaves a trail: what ran, what passed, what it cost, who approved. Nebula builds itself through the same loop this page describes — the evidence below is its own run, not a demo.
Nebula builds Nebula.
This site, the CLI and the loop move through the same path: a work item, a branch, a preview, Planner → Coder → Reviewer → QA → Release, and a human approval. The lines below are the fields from a real run — what ran, in what order, what each step returned. That trail is the product: the same evidence a work item on your project would leave.
Shipped, in progress and planned are listed beneath. An item earns its status in the open; when something on this page changes, the trail says so.
- Marketing LeadR1-E1 · market_brief_ready · stub, no model callSTUB00:00:00
- Marketing LeadR1-E1-1 · market_brief_ready · stub, no model callSTUB00:00:00
- Product OwnerR1-E1-2 · ready_for_planning · stub, no model callSTUB00:00:00
- PlannerR1-E1-3 · success · stub, 0 tasks plannedSTUB00:00:00
- Codernot dispatched in this run · 0 commits · no PRSTUB00:00:00
- Reviewernot dispatched in this runSTUB00:00:00
- QAnot dispatched in this run · 0 scenariosSTUB00:00:00
- Releaseproduction · nothing approved, nothing releasedAWAITING HUMAN00:00:00