Self-hosting Octopedia in about ten minutes

One of the design rules behind Octopedia is that the managed cloud and the self-hosted build are not two products. They are the same artifact, configured differently. That rule has a pleasant consequence: running the whole thing yourself is genuinely quick.

Here is the path, start to finish.

What you need

A machine, virtual or physical, that can run Docker. A small cloud instance is plenty for a team.
Docker and the Docker Compose plugin installed.
A domain name, if you want TLS handled for you. This is optional for a local trial.

That is the entire list. There is no separate database to provision, no message queue to babysit, no search cluster to feed. The stack brings its own.

Bring up the stack

Clone the repository and start it:

git clone https://github.com/tealsai/octopedia.git
cd octopedia
docker compose -f infra/docker-compose.yml up

That single command starts the server, the git host for your vault, the database, and a reverse proxy that handles TLS. When it settles, the client is waiting for you in the browser.

For a quick local look without certificates, set the local flag and the proxy will serve plain HTTP:

OCTOPEDIA_LOCAL=1 docker compose -f infra/docker-compose.yml up

Point a channel at it

A team memory with nothing to listen to is just an empty folder. Open the settings, connect the first channel, and send the assistant a message. Within a moment you will see your first entity appear in the vault, committed to git, and showing up in the client.

Where your data lives

This is the part that matters most. On a self-hosted install, the vault is a git repository on your own disk. It does not travel to us. It does not travel anywhere. Backups are whatever backup process you already trust, pointed at a directory of plain markdown files.

Self-hosting should not mean self-supporting a fragile pile of services. One command up, one command down, and the data is just files.

Moving in, moving on

Because the cloud and self-hosted builds are identical, nothing about this decision is permanent. A team that starts on the managed cloud can move in-house later, and a self-hosted team can hand operations to us, by changing configuration rather than running a migration.