Mirobody - Mirobody

What is Mirobody?

Mirobody is an open-source health data engine you run yourself. It reads lab reports, wearable exports, photos and genetic files, assigns one standard code and unit to each value, keeps the record in a Postgres you operate, and lets an agent answer questions over it while naming the source of every reading. Since 1.5.4 every model can run on the same machine, on llama.cpp, so your documents and questions need not leave it, and the record exports, backs up and restores as files you hold. The engine is open source under Apache 2.0, built by Theta Health, and is the engine under its Theta Wellness app. Mirobody Cloud offers the same standardization and agent capabilities as a hosted API.

First steps

Choose where the record will run. The two paths use the same coding approach, but have different setup and API endpoints.

Mirobody Cloud

Create a key, write sample readings, and ask a question through /v1. We operate storage and models.

Self-Host

Run the library or the Docker stack yourself. Records stay in storage you operate; the models run at the vendor you choose, or entirely on your own machine.

Cloud exposes /v1. A self-hosted deployment exposes its own /api/* and /mcp endpoints.

Your first goal	Start here	Result to check
Call a hosted API	Cloud quickstart	Two sample readings share a LOINC code; a question can cite them.
Resolve a name or unit locally	Library path	A code is returned without a database or model key.
Explore the full product locally	Docker demo	The service is healthy and demo readings appear in Data.
Keep every question and document on one machine	Run locally	With no key in `.env`, `mirobody doctor --probe` reports PASS for the local entries.
Choose a model for the privacy and answers you need	Choosing a model	`mirobody doctor --probe` reports PASS for the model you chose.

From data to answers

Collect, Translate, Agent: health data moves from sources to coded records and answers — The same three stages organize Cloud and the open-source engine.

Stage	What you can observe	Read more
① Collect	A file, device reading or structured record enters the system with its source.	Cloud data inputs · Open Source collection
② Translate	Different names for the same test resolve to a standard LOINC code; units use UCUM. Unmatched names remain unmatched.	Standardization
③ Agent	A question runs over the coded record and returns an answer with its supporting readings.	Cloud Answers API · Open Source agent

On Cloud, your application sends data to /v1; the service stores and processes it. In a self-hosted deployment, the engine runs on infrastructure you manage. See Cloud capabilities and the local setup guide for their respective paths.

Storage and operations

Decision	Mirobody Cloud	Self-Host
Stored records	Operated by Mirobody, under the API’s retention settings	In your Postgres and file storage
Model requests, with a vendor key	Handled by the hosted service	Sent to the vendor whose key you paste, under its terms
Model requests, 100% on this machine	Not offered: Cloud runs the models	Served by llama.cpp on the same machine; nothing about you is sent
Taking data out	Data lifecycle: retention and Subject offboarding	CSV, JSON and NDJSON exports, VCF for genotypes, and a backup script; see Export Your Data
Deployment and upgrades	Operated by Mirobody	Follow the server deployment guide

Cloud API overview

Authentication, Subjects, retention and the /v1 endpoint map.

Open Source architecture

Follow a reading from its original file to a coded answer.

Run locally

Every model on your own machine with llama.cpp: what each size needs and how to start it.

Export your data

The export routes, their formats and limits, and the backup that is the complete copy.

​What is Mirobody?

​First steps