Docs menu · Guides

Because StrataDB is embedded, deploying it is unlike deploying a database server — there is no service to run, scale, or secure a network boundary around. A deployment is two pieces: the strata binary (or the Python SDK, which links the engine directly) and a database directory. This guide is the concrete recipes; every command below was run against the shipped binary.

One durable database is opened by one process at a time (an exclusive lock enforces it), so the deployment unit is “one process owns one database directory.” For throwaway or read-mostly workloads, cache mode (--cache) needs no directory at all.

Seed a database in your release build

A database is created on first write, so “prepare a dataset” is just a script that runs strata against the directory your build ships:

strata ./dist/appdb kv put config:mode production
strata ./dist/appdb json set catalog:1 '$' '{"name":"Starter dataset","rows":120}'
strata ./dist/appdb describe
created config:mode applied=true
created catalog:1 applied=true
{
  "branch": "default",
  ...
  "primitives": {
    "event_count": 0,
    "graphs": [],
    "json_count": 1,
    "kv_count": 1,
    "vector_collections": []
  },
  "target": "durable_local",
  "version": "1.0.0"
}

describe at the end of the seed step doubles as a build-time sanity check — assert on kv_count/json_count in CI and the artifact can’t ship empty.

Copy the directory as a unit

A database directory moves like any other build artifact — copy the whole directory, never individual files inside it:

cp -a ./dist/appdb ./appdb-copy
strata ./appdb-copy kv get config:mode
production

The copy is a fully independent database. Ship it in a tarball, bake it into an image, or sync it to a target host; the app opens it in place.

Ship it in a container

The same two pieces — binary plus directory — in a Dockerfile. This image installs the binary with the official install script, copies the seeded database from the build context, and starts the built-in MCP server as its entrypoint:

FROM debian:bookworm-slim

# The strata binary — installed from the official script at build time.
RUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates \
    && curl -fsSL https://stratadb.org/install.sh | sh \
    && apt-get purge -y curl && rm -rf /var/lib/apt/lists/*
ENV PATH="/root/.strata/bin:${PATH}"

# The database directory — seeded during the release build, copied as a unit.
COPY dist/appdb /data/appdb

CMD ["strata", "/data/appdb", "mcp", "serve"]
docker build -t strata-app .
docker run --rm strata-app strata /data/appdb kv get config:mode
production

Pin a release with STRATA_VERSION=<x.y.z> before the install line if you want builds reproducible against a specific binary version.

Clone at first run

For curated datasets, keep the data out of the artifact entirely and pull it from a hub on startup — the result is an ordinary local database that remembers its origin:

[ -d ./appdb ] || strata clone starter-dataset ./appdb

The [ -d ... ] guard makes startup idempotent: an existing directory is opened as-is, a missing one is cloned. See Cloning datasets for hub resolution and the failure modes (bad URL, unreachable host) with their error codes.

Expose it to an agent

To hand a deployed database to an AI agent, run the MCP server as the app’s subprocess — it speaks stdio, so there is still no network service to operate:

strata ./dist/appdb mcp serve
{"id":1,"jsonrpc":"2.0","result":{"capabilities":{"tools":{"listChanged":false}},"instructions":"Strata is an embedded multi-model database (KV, JSON, vectors, events, graphs) with branches and time travel. ...

(The line above is the server’s response to an initialize request on stdin — the full handshake is on the MCP server page.)

In the browser

StrataDB compiles to WebAssembly and runs entirely in the browser in cache mode — the same engine and the same commands, with nothing written to a server. The playground runs a full database this way, with no installation. Browser deployments are cache-mode: state lives for the life of the page, so persist anything you need to keep through your own application layer.

Edge and constrained environments

The embedded model — one binary, one directory, no server — is a natural fit for local-first apps, CLIs, notebooks, and constrained devices. Tuning StrataDB for very small footprints (single-board computers and smaller) is an active direction rather than a turnkey recipe today; if that is your target, the embedded architecture is the place to start and the shape the roadmap is building toward.

agents: this page as markdown → /docs/guides/deploying.md