sedimentaRequest early access
Self-host

Your server. Your data. Your model.

Sedimenta installs with one command on a Linux server, or runs on one person’s laptop. A new installation is empty: no data, no telemetry, and the first administrator sets their own password.

Two ways to run it

From a laptop to a team server

one person

Desktop

For one person on their own computer: a local database in your user folder, listening on 127.0.0.1 only. It prints the lines to connect your agents on start.

npx sedimenta
team

Server

Docker builds the image and starts the application, PostgreSQL and a backup service. The first sign-in link is printed at the end.

docker compose up -d
Performance · example measurements

How it held up in our load tests

Three example setups from our test servers. Add application processes as the team grows — one PostgreSQL behind them.

measured

A team on a small server

8 cores · 12 GB · 2 app processes

600 active people
edits p95 260 ms
estimate

A department on a mid-size server

16 cores · 32 GB · 4 app processes

1,500 active people
edits p95 ~300 ms
measured

A company on the same server

48 cores · 96 GB · 16 app processes

4,000 active people
edits p95 212 ms · home page p95 336 ms
0 errors

for people at every load step; when overloaded, agents get 429 or 503 and retry

22–30 ms

median to move between pages inside the app, with 2,000 people working

~1 s

to open the app cold today — we are working on it

Examples from our load tests in November 2026; the mid-size server is an estimate between the two measured setups. Not a guarantee: your numbers depend on hardware, data and how people work. Test data: 50,000 records, 2,000 pages, 200 accounts; a workday scenario (home page, pages, databases, search, edits and co-editing) plus 20 agents writing over the API and MCP; 3-minute steps; time from the load generator to the server response, without browser rendering.

Requirements

What the server needs

Operating system

Linux with Docker Engine and Docker Compose v2.

CPU and memory

2 cores and 4 GB of RAM for the image build; a running installation uses less.

Disk

About 10 GB for the image, the database and backups.

Network

Internet access during the build only. After that it can run with no outgoing requests at all.

Running it

Operations, already thought through

backups

Daily backups

Database dump and files every night and right after the first start, kept for 30 days. Restore with one command; keys are backed up encrypted with your passphrase.

backup now · list · restore
updates

Safe updates

Migrations only add, never rewrite. Every release is tested by upgrading reference databases of earlier releases, and a database copy is taken before migrations.

scale

More processes when you grow

Run several application processes on one PostgreSQL behind your proxy when a team outgrows one.

search

Search inside your database

Full-text and vector search in PostgreSQL itself — no separate search service to run.

pgvector
models

Any model, your keys

Connect the model provider you choose, or a local model. Without a model the workspace and MCP keep working.

domain

Your domain and TLS

Put it behind your own domain and proxy, with your certificates.

Private preview

How to get it

During the private preview we share installation packages with pilot teams and help with the first setup. Request early access and tell us how you work with agents today.

See it on your own data

We’re working with a small number of teams that already use AI agents in their daily work.

Request early access