Operations: containers + S3

The operational story for EvidentSource is intentionally small: a container for the runtime, object storage for durability. No relational database to tune, and no coordination service to run.

This page walks through what each piece does, why it’s enough, and how to run it.

The pieces

The EvidentSource container

One Rust binary, packaged as a container image. It serves:

• HTTP on port 3000: the API and the browser UI;
• gRPC on port 50051;
• the WebAssembly runtime that runs your State Changes and State Views;
• the write path, which commits each database’s transactions.

The same binary runs the MCP server as a separate process, on port 3001, in front of the HTTP API. See MCP API.

Object storage, through SlateDB

SlateDB is a storage engine that persists to object storage. It’s how EvidentSource gets durable writes without a separate database tier.

In production that means Amazon S3. The AWS Marketplace template also puts SlateDB’s write-ahead log on S3 Express One Zone, in an Availability Zone you choose, which should be the one your servers run in, for lower write latency.

That’s it

There is no required:

• relational database;
• cache or coordination service, such as ZooKeeper, etcd or Consul.

Kafka is needed only if you use async commands.

Why this works

Durable state lives in object storage, not on the container. A server can be replaced at any time; its replacement reads the database back from storage and carries on.

Servers are interchangeable. Run several, and each database’s writes go to one of them at a time, its writer, which the servers choose among themselves. If a writer goes away, another server takes over its databases.

The log is already durable. Nothing has to be replicated into a second system to be safe, so a consumer can read the same object storage the server writes. See Kafka streaming for getting events onto a broker when you want them there.

Running it

Locally

docker run -d -p 3000:3000 -p 50051:50051 evidentsource/evidentsource-dev:0.8.38@sha256:16c279e5dee4a1b0e3951067ed871040251266fd1d7404554744b31b04bbbc69 \
  server --scheme http --dev --node-id node-1 --writer memory

This keeps everything in memory, so data is lost when the container stops, and needs no cloud setup. The arguments matter:

• memory selects in-memory storage. The explicit arguments make this pinned release independent of image defaults; S3 storage requires its own backend arguments and AWS credentials.
• --writer makes this lone server the writer for its databases. Without it, every write is refused.

Then open http://localhost:3000, or set up the TodoMVC example against it.

On AWS

Deploy through the AWS Marketplace listing. Its CloudFormation template stands up an ECS service, a load balancer, the S3 buckets, IAM roles and logging, in a VPC you already have. See AWS Marketplace deployment.

What you don’t have to do

• Manage schema migrations
• Tune a database for transactional workloads
• Operate ZooKeeper
• Build a change-data-capture pipeline to get events out
• Design shard keys: each database is its own unit of write partitioning

What you still have to do

• Monitor the servers. They emit OpenTelemetry metrics and traces; the Marketplace template runs a collector alongside them that sends traces to AWS X-Ray and metrics to CloudWatch.
• Size them for your workload. See Tuning and AWS Marketplace deployment.
• Decide your retention for the S3 buckets.
• Configure authentication and authorization. See Security.

Next

• AWS Marketplace deployment: the template’s parameters and sizing.
• Security: authentication and authorization.
• Kafka prerequisites: if you use async commands.