An alert arrives from a service you run. Celmis already knows which repository that service is and who owns it, so the fix starts there: an embedded Claude Code session — on your subscription, inside your installation — edits the code, and the runner commits, pushes a branch and opens a pull request. On one measured finding that took 220 seconds, from whatever device the alert reached first.

Celmis does not watch your services. Grafana, or whatever you already run, does that and does it well. This is the part that comes after the alert: the walk from a firing rule to a diff someone can review.

To be exact, because the line is easy to blur. The application ingests no logs of its own — it starts from the alert. But the repository ships an optional observability overlay, and that does collect them:

docker compose -f docker-compose.yml -f docker-compose.observability.yml up -d

That brings up Prometheus, Loki, Promtail and Grafana. docker-compose.observability.yml is deliberately platform-wide rather than Celmis-only: Promtail tails the Docker daemon's container logs and labels each stream by container name, so every service on that host — all thirty of them, if you run thirty — shows up in Grafana's Loki explorer, filterable by container. Prometheus scrapes api:8000/metrics for Celmis's own counters alongside.

Every port binds to 127.0.0.1 and is reached over an SSH tunnel:

ssh -L 3100:localhost:3100 -L 9090:localhost:9090 you@your-server

That is not caution for its own sake. Loki has no authentication, so POST /loki/api/v1/push accepts writes from anyone who can reach it, and a log store strangers can write to is not a log store. GRAFANA_ADMIN_PASSWORD is required — the stack will not start without one.

That loop is the product. It closes because everything sits on one index: a symbol graph Celmis builds from your repositories once. The same index answers questions that cross repository boundaries, reviews pull requests, audits dependencies into a CycloneDX SBOM and a verifiable evidence pack, generates documentation, and serves twenty-three tools over MCP — surfaces worth having, and none of them the point on their own.

It runs on one machine under docker compose, with the model provider of your choice behind it, and nothing leaves your network except the calls you configure.

In the oldest telling, Kelmis was the smelter — one of the three Idaean Dactyls, alongside Damnameneus the hammer and Acmon the anvil, to whom the working of iron was credited. The index does the reducing here; the surfaces are what work the result.

What that buys you that a diff-only tool cannot

Ask a question that spans two repositories, and the answer quotes both:

That is not a search result. The gateway and the payments service are separate repositories with no shared code, and the answer traces the call chain between them — then notices, unprompted, that the Kafka topic name is hardcoded in both and that changing one silently breaks the other.

A reviewer that reads only the diff structurally cannot say that. It never had the other repository open.

Nine things people do with it

The first three are the ones a code-review tool does not do at all, and they are the reason this is a platform rather than a reviewer: index once, then read that index from whichever side of the work you are standing on.

Three numbers

That last one is deliberately unflattering, and it stays. It measures one of the surfaces below — pull-request review on isolated single-repository PRs — and that set has no sibling service for a symbol to have consumers in, so the thing this product is built around is not in the number at all. The table, the audit of every finding it scored false, and the command that reproduces both are in Results.

Table of contents

• What that buys you that a diff-only tool cannot
• Nine things people do with it
• Three numbers
• Quick start
• First user and admin
• Connect a repository
• Ask the code
• Pull-request review
• Dependencies, SBOM and the evidence pack
• Fix from here
• Alerts, and fixing from a phone
• Ask for work across repositories
• Who can see what
• Languages and formats
• Deterministic checks — no model, no false positives
• Connect Claude Code and other MCP clients
• Results
• Audit of the false positives
• Test repositories
• Configuration
• Operations
• Local development
• CLI reference
• Architecture
• Troubleshooting
• Project layout
• Provenance and rights

Quick start

What you need

Postgres and Qdrant are bundled — no external cluster to provision. No Python or Node.js install is needed for the Docker flow.

Start it

git clone https://github.com/Celmis-labs/Celmis.git celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

Open http://localhost.

Nothing is built here. The three images are pulled from the registry named by CELMIS_REGISTRY at the tag in CELMIS_TAG, for linux/amd64 and linux/arm64 — Apple Silicon and an ARM server both get a native image. Building them on the machine that runs them was measured at 485 seconds and 4.2GB of disk for api alone, which is why installing no longer means compiling.