Unbody is an Apache-2.0, TypeScript, modular open-source backend for building AI-native software that is designed for knowledge rather than static data, and it is aimed at developers and teams that want to self-host the ingestion, indexing and retrieval layer behind chat, search and agentic applications.
What it is
Unbody sits in the AI and machine learning infrastructure category, is written in TypeScript, and is released under the Apache-2.0 licence. The project frames itself as "the Supabase of AI era": a backend whose primary unit is knowledge rather than rows of static data. Its topics cover data ingestion, data enhancement, knowledge base, retrieval augmented generation, vector database, chatbot, generative AI and agentic AI work, and the repository carries 524 stars, 47 forks and 3 open issues at the time of this data. The homepage is https://unbody.io.
The problem it solves is the assembly work between raw content and a working AI application. Rather than hand-wiring an ingestion script to an embedding step to a vector store, an operator adds a source through the bundled CLI and lets the stack index it. Within the registry it occupies the supabase-alternative slot: the self-hosted backend promise Supabase made for application data, applied to the pipeline that turns content into retrievable knowledge.
Key capabilities
- Modular coverage of an AI-native stack: data ingestion, data enhancement, knowledge base, RAG, vector database, chatbot and agentic AI, per the repository topic list.
- Source onboarding through
yarn unbody-cli source add, the documented way to add a data source.
- Docker Compose runtime:
docker compose up -d brings the services up, then yarn start runs the application.
- Indexing visibility through the Temporal dashboard at http://localhost:8233/, which shows files as they are indexed.
- Configuration by environment file: copy
.env.example to .env.local and edit it, with an OpenAI API key as a prerequisite.
- A companion examples repository, https://github.com/unbody-io/examples, used to create a first project and to continue after indexing finishes.
- Apache-2.0 licensing, with 524 stars and 47 forks in the given repository data.
Who uses it and how
- Developers and teams building retrieval, chat or agentic features who would rather run the knowledge layer on their own hardware than on a managed platform.
- Self-hosters able to meet the documented prerequisites: Node.js LTS 20 or 22, Docker with Docker Compose, yarn, and an OpenAI API key.
- Operators who want to watch indexing progress directly, refreshing the Temporal dashboard at http://localhost:8233/ as files are processed.
- Teams following the examples workflow: clone https://github.com/unbody-io/examples, add a source with the CLI, wait for indexing to finish, then continue from that repository's README.
Getting started
Clone https://github.com/unbody-io/unbody, run yarn, copy .env.example to .env.local and fill it in, then start the stack with docker compose up -d followed by yarn start. Yarn is required here because, per the README, npm will not install the dependencies correctly.
How it compares
The repository files itself under the supabase-alternative topic and describes itself as "the Supabase of AI era", so Supabase is the named point of comparison. The contrast the project draws is one of subject matter: Supabase serves static application data, while Unbody is built for knowledge, meaning ingestion, enhancement, indexing and retrieval over content rather than rows. Because it is Apache-2.0 and self-hosted through Docker Compose, the deployment and cost model stay with the operator rather than with a hosted vendor.
When to use it — and when not to
Set expectations first: the repository is archived and no longer actively maintained, and the maintainers have moved to Unbody Labs with Adapt named as the most direct continuation of the mission, so a new project should evaluate Adapt before committing here. A self-hoster must run the Docker Compose stack, keep Node.js LTS 20 or 22 and yarn available, and supply an OpenAI API key, which means operating local services and accepting a third-party model dependency. The README is brief and redirects readers elsewhere for ongoing work, so it suits study, reference or an existing deployment better than a team that needs an active release cadence.