Unbody is archived: what the Supabase-for-AI backend actually shipped

What Unbody set out to be, and why that matters now

The repository describes itself as "The Supabase of AI era" and as "a modular, open-source backend for building AI-native software, designed for knowledge, not static data." The topics attached to it fill in the intent: data ingestion, an ETL pipeline, a vector database, a knowledge base, RAG, and agentic AI. That combination describes a backend that accepts source documents, processes them through a pipeline, and exposes the result for retrieval by a language model rather than for row-oriented CRUD.

The audience was developers who wanted Supabase-style convenience but for unstructured content. Instead of writing your own ingestion scripts, chunking logic, embedding calls and vector storage, you would point the backend at a source and query the result. The README's own setup flow confirms this: it walks you through adding a data source with a CLI command and then watching files get indexed.

That framing matters because the project is gone. The README opens with a notice that the repository is archived and no longer actively maintained, and states that the original vision "has evolved." What remains is a snapshot of a specific architectural bet: that the hard part of AI-native software is the knowledge pipeline, not the model call.

The indexing pipeline is the product, and Temporal is where you watch it

The most concrete architectural signal in the README is the instruction to open a Temporal dashboard at http://localhost:8233/ to watch files being indexed. Temporal is a workflow orchestration engine, and its presence tells you how Unbody handled ingestion: as a durable, multi-step workflow rather than a single request. Indexing a document set is long-running and failure-prone, so running it as an orchestrated workflow means individual steps can retry without restarting the whole job.

The README also notes a limitation of that dashboard in plain terms: "The dashboard needs to be manually refreshed to get the latest state." That is a small detail with real consequences for anyone using it as an operational view. You cannot leave it open and trust that what you see is current.

The rest of the data flow is implied rather than documented in what we have. Docker Compose brings up the backing services, the CLI registers a source, and the workflow picks it up. The README does not specify which vector store, which embedding model, or how chunking is decided. Those choices live in the code and the .env.local file, not in the setup instructions. If you are evaluating the design, read the compose file and the environment example before the README, because the README stops at the point where the interesting decisions begin.

Getting it running: yarn, Docker, and an OpenAI key

The setup instructions are short and prescriptive. Prerequisites are Node.js LTS (20 or 22), Docker and Docker Compose, yarn, and an OpenAI API key. The yarn requirement is stated with a reason: "npm won't install dependencies correctly." That is an unusual constraint and worth taking literally, since a dependency tree that only resolves under one package manager usually means peer dependency conflicts or a workspace layout that npm handles differently.

The sequence is:

git clone https://github.com/unbody-io/unbody cd unbody yarn

Then environment setup, which copies the example file and expects you to edit it:

cp .env.example .env.local vim .env.local

The README does not enumerate the keys inside .env.local beyond the OpenAI prerequisite, so the file itself is the documentation. After that, the stack comes up and the app starts:

docker compose up -d yarn start

Creating a first project means cloning a separate repository, unbody-io/examples, and adding a source from there with yarn unbody-cli source add. So the CLI lives in the examples repo, not the main one. That split is a friction point: the main repository alone does not give you a working end-to-end path.

The maintenance question answers itself

Normally this section would weigh upgrade cadence, breaking changes and the cost of tracking upstream releases. Here the answer is simpler. The README states the repository is archived and no longer actively maintained. No recent releases were retrieved. The last push date on the repository metadata is 2026-04-14, which is consistent with a final archival commit rather than ongoing development.

That changes the cost model entirely. There is no upgrade path to plan for, because there will be no upgrades. The relevant cost is opportunity cost: time spent getting a Docker stack, a Temporal workflow engine and an OpenAI-backed pipeline running, on a codebase that will not receive security patches or dependency bumps. The dependencies themselves are the sharper risk. A TypeScript project with a Docker Compose stack and an orchestration engine has a deep dependency tree, and none of it is being maintained here.

The licence is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. That means forking is legally straightforward. It does not mean forking is cheap. Nothing in the README suggests the maintainers intend to review external contributions, and an archived repository typically has issues and pull requests closed by default. If you fork, you own the whole stack.

Adapt is the stated successor, and it is a different shape of project

The README does not leave you guessing about where the work went. It states that the team now builds under Unbody Labs and names Adapt as "the most active and direct continuation of Unbody's mission," linking to github.com/unbody-io/adapt, documentation at adapt.unbody.io/docs, and a live demo.

The difference in approach is not cosmetic. Unbody was a server-side backend: Docker Compose, a Temporal workflow engine, a Postgres-or-similar backing store, and an OpenAI key, all running as a service you deploy. Adapt is described as a "lightweight (< 200KB), provider-agnostic AI memory and learning framework" that runs "in the browser or on the server." Provider-agnostic is the operative phrase. Unbody's setup instructions hard-require an OpenAI API key; Adapt is described as not tied to one provider. And the deployment target differs: a framework that runs in the browser has no Docker Compose file and no dashboard on port 8233.

So the two projects solve adjacent but distinct problems. Unbody was infrastructure you operate. Adapt is a library you embed. If your need was a hosted-style ingestion service with observable workflow runs, Adapt is not a drop-in replacement, and the README does not claim it is. It claims continuity of mission, not of interface.

Where the original design would have struggled anyway

Set the archival aside for a moment and the setup path still has rough edges that are worth naming, because they explain the kind of project this was.

The dependency on a single model provider is the clearest one. An OpenAI API key is listed as a prerequisite with no alternative mentioned in the setup instructions. For a backend whose stated purpose is knowledge ingestion, that couples your indexing cost and your data flow to one vendor's pricing and availability. Adapt's provider-agnostic description reads like a direct response to this.

The split between the main repository and the examples repository is the second. The main repo gives you a server; the CLI that adds a data source lives elsewhere. Anyone following the README has to context-switch between two codebases to complete a first run, and the README explicitly defers the next step to the examples repository's own README.

The third is the dashboard refresh behaviour. An orchestration dashboard that does not update itself is a debugging tool you have to poll by hand. For a pipeline whose whole value proposition is tracking long-running indexing jobs, that is a mismatch between the tool and the task.

None of these are fatal in isolation. Together they describe a project that was early, and the archive notice is consistent with that.

Who should touch this repository, and who should not

If you are choosing a backend for a new AI product, do not start here. The repository is archived, the README says so in its first line, and the maintainers redirect readers to Adapt. Cloning a deprecated stack to build something new adds risk with no compensating benefit.

There are two cases where the code is still worth opening. The first is research: if you are designing your own ingestion pipeline and want to see how someone wired Temporal into a document indexing workflow, the repository is a readable artifact of that decision, and the Apache-2.0 licence makes reuse straightforward. The second is archaeology on a specific claim. The project marketed itself as a Supabase alternative for knowledge, and the gap between that claim and what the README actually documents (a Docker stack, a CLI in another repo, a manually refreshed dashboard) is instructive about how much of a backend product is glue rather than core.

What to verify first if you do proceed: that yarn resolves the tree, since the README warns npm will not; that docker compose up -d brings up Temporal on port 8233 alongside the rest of the stack; and that your .env.local contains everything the code expects, because the README does not list those keys. If any of those three fails, you are debugging an unmaintained repository, and the effort is almost certainly better spent reading Adapt's documentation instead.

Editorial conclusion

Unbody is not a tool to adopt in 2026: the README's first line states the repository is archived and no longer actively maintained, and the project points readers to Adapt instead. Anyone who needs a maintained AI memory layer should evaluate Adapt directly rather than cloning Unbody. If you still want to inspect the original, verify three things before investing time: that yarn (not npm) resolves the dependency tree, that Docker Compose brings up the stack including the Temporal dashboard on port 8233, and that you have an OpenAI API key, since the setup instructions list one as a prerequisite. Treat the code as a reference implementation of an indexing pipeline, not as a backend to run in production.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. unbody-io/unbody on GitHub