Unbody: an archived AI backend, and what is left of it

What Unbody was trying to be for AI-native software

The pitch in the repository description is a backend for building AI-native software, "designed for knowledge, not static data", positioned as a Supabase alternative. That framing matters because it sets the scope: not a database, and not a model provider, but the layer between your content and the model that has to answer questions about it. The topic list on the repository confirms the intended audience, naming agentic-ai, rag, knowledge-base, etl-pipeline and data-ingestion. A team building a chatbot over internal documents, or a search product over a mixed corpus of pages and files, is the target user. The problem it addresses is the boring middle of retrieval-augmented generation: getting sources in, parsing them, chunking and embedding them, keeping the index current, and exposing a query surface. Most teams write that pipeline themselves and then maintain it forever. Unbody tried to ship it as a service you run.

Temporal workflows, Weaviate, MongoDB and Redis in one stack

The architecture is visible in docker-compose.yml rather than in prose. The stack runs five services and a file server. MongoDB 4.4.6 starts as a replica set with --replSet rs0, which is the configuration Mongoose needs for change streams and transactions. Redis listens on 6379. Temporal runs from temporalio/admin-tools, exposing 7233 for the server, 8233 for the UI and 60896 for metrics. Weaviate is built from a local Dockerfile and tagged weaviate:unbody, with modules enabled for text2vec-huggingface, generative-unbody, img2vec-custom, reranker-custom and multi2vec-custom. A separate img2vec-neural service runs semitechnologies/img2vec-pytorch:resnet50 on port 3456 with ENABLE_CUDA set to 0. The dependency list in package.json tells the same story from the application side: @temporalio/worker and @temporalio/client for durable execution, @nestjs/mongoose for persistence, crawlee for fetching, marked and node-html-parser for document handling, googleapis for Google sources, and the langchain packages for model calls. The data flow implied by that combination is: a source is registered through the CLI, an ingestion workflow is scheduled in Temporal, activities crawl and parse the source, embeddings go into Weaviate, and metadata lands in MongoDB. Temporal is the load-bearing choice here. Indexing a large corpus is a long-running, partially failing job, and putting it in a workflow engine gives you retries and resumability that a plain Node script does not.

Installing Unbody and running the first source

The original setup instructions survive inside a collapsed details block in the README. The prerequisites are listed as Node.js LTS (20 or 22), Docker and Docker Compose, yarn, and an OpenAI API key. The README is explicit that npm will not install dependencies correctly, which is an unusual constraint and worth respecting if you try this. Clone the repository and install with yarn.

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

Environment setup copies the example file. Note the README says .env.local here while .env.example itself says to copy to .env, so the two instructions disagree and you should check which file the config loader in config/ actually reads.

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

The only value you must supply is OPENAI_API_KEY. The remaining variables in .env.example point at the local file server and the img2vec service, and the comments state they are generally fine as they are if docker-compose.yml is unchanged. Then bring up the stack and start the Nest application.

docker compose up -d
yarn start

Creating a project means cloning the separate examples repository, and adding a data source goes through the CLI script defined in package.json as unbody-cli. The README shows it without arguments.

yarn unbody-cli source add

Indexing progress is visible in the Temporal dashboard at http://localhost:8233/. The README warns that the dashboard needs a manual refresh to show the latest state, which is a small but real friction point during a long ingestion run. Once indexing finishes, the README directs you to the examples repository for the next step.

The repository is archived, and the README says so first

The first line of the README is a heading that reads "Unbody (archived)", followed by a blockquote stating the repository is archived and no longer actively maintained. The repository metadata agrees: the archived flag is set, and the last push was on 2026-04-14. That is the single most important fact about this project and it should govern any decision to use it. Archived means no security patches, no dependency bumps, and no answers to issues. The dependency list makes the risk concrete rather than theoretical: it pins @langchain/openai at ^0.0.33 and langchain at ^0.2.0, both early lines that have moved on considerably, and it depends on mongo:4.4.6, a MongoDB release from 2021. Running this in production means owning that entire upgrade path yourself, including the Weaviate image built from a local Dockerfile whose base is not visible in the compose file. The README's own framing is that the vision evolved, which is a graceful way of saying the project was superseded rather than finished.

Adapt is the stated continuation, and it is a different kind of tool

The README points to Adapt as the most active and direct continuation of Unbody's mission, hosted at unbody-io/adapt. The description there is a lightweight (under 200KB) provider-agnostic AI memory and learning framework, which runs in the browser or on the server. That is a genuinely different approach from Unbody. Unbody was a multi-service backend: you ran Docker, Temporal, Weaviate, MongoDB and Redis, and the value was in the pipeline and the indexing. Adapt is a library with a size budget, and the value is in memory and learning behaviour inside an application. If what you wanted from Unbody was a hosted-style ingestion pipeline over a document corpus, Adapt is not a drop-in replacement, and the honest reading is that no direct replacement is named. If what you wanted was a way for a model to accumulate and organize context across sessions, Adapt is aimed at exactly that and is the thing the maintainers now work on. The other realistic alternative is to assemble the same components yourself, since every piece Unbody composed is independently available: Temporal for durable workflows, Weaviate for vectors, Mongoose for metadata. You would write the ingestion activities, which is the work Unbody was trying to save you.

Maintenance cost, licensing and what the archive means in practice

The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact. That is a permissive licence and it does not expire when a project is archived. Worth flagging: the package.json in the repository declares "license": "UNLICENSED" and "private": true, which conflicts with the LICENSE file at the repository root. The LICENSE file is the one that governs the source you cloned, but the mismatch is the kind of thing a legal reviewer will ask about, and it is not something to resolve by guessing. This is not legal advice; if the distinction matters to your organisation, have counsel read both files. On upgrade cost, the honest position is that there is no upstream to upgrade to. Any dependency bump is yours, and the Temporal, Weaviate and MongoDB versions in docker-compose.yml are pinned to a moment in 2025 or earlier. The practical cost of keeping this running is the cost of maintaining a fork, and that cost is only justified if the ingestion pipeline it contains is worth more to you than rewriting it.

Editorial conclusion

Unbody is not a project to adopt today: the README opens by stating the repository is archived and no longer actively maintained, and the last push was on 2026-04-14. It is worth reading if you want to see how an ingestion pipeline, a workflow engine and a vector store were wired together in a single NestJS service, or if you already have a checkout and want to understand the pieces before deciding whether to keep any of them. Anyone starting a new AI backend should look at Adapt, the continuation the README names, or at the individual components Unbody composed. Before reusing anything from this tree, verify that docker-compose.yml still starts on your machine, that the Weaviate image built from devenv/docker/weaviate/Dockerfile resolves, and that the OpenAI key path in .env.example matches the provider you intend to pay for.

Frequently asked questions

Official sources

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