Service-type reference

Every [services.<name>] block in a manifest declares a type. The type is one of ten v1 service types (decision 2.21). They split into two groups:

Blessed services

Vertical implementations with a download recipe, a healthcheck, an inspection surface, and a per-service version-catalog entry:

TypeDefault versionDescription
postgres16.10PostgreSQL, source-built, loopback-only
redis7.4.6Last open-source Redis line
qdrant1.17.1Vector database
ollama0.23.2Local LLM runtime (defaults to shared isolation)
minioRELEASE.2025-09-07T16-13-09ZS3-compatible object store

These are the services Unibench actively manages binaries for. The orchestrator downloads them on first run, runs first-run init (initdb, root-cred mint), supervises the process, and ships a dedicated inspector in the GUI drawer.

Generic services

Wrap user-provided binaries; no per-version catalog entry:

TypeDescription
processLong-running user binary
task_serviceOne-shot script with timeout
containerDocker / Podman container
composeDocker Compose project (the escape hatch)
remoteReference to a service running outside the orchestrator

For these, the manifest declares command / image / url and the orchestrator wires up dependencies + healthchecks + port allocation without prescribing anything about the binary itself.

What "default" means

When a service's version field is omitted (or set to "default"), the orchestrator installs the version listed in the per-service version catalog. The inspector drawer's Version section + unibench versions <type> both surface the value plus a clickable link to upstream release notes.

Shared isolation

The default isolation for most services is per-project (decision 2.2) — each project gets its own Postgres instance, its own Qdrant, its own MinIO. Ollama is the exception, defaulting to isolation = "shared" (decision 2.46) so multiple projects don't each load the same multi-gigabyte model into RAM.

Override per service with isolation = "shared" or "per-project" in the manifest.