Skip to main content
s2-lite is designed to run as a single instance, making self-hosting straightforward. See the README for more on its internals and quickstart for running it via the s2 CLI. Docker images are available. You can also use the Helm chart for deploying to Kubernetes. The SDKs and CLI can connect to s2-lite by overriding the default endpoints. See SDK: Endpoints and CLI: Configuration for details.
Even if you plan to exclusively use the cloud service, s2-lite is useful as an S2 emulator for integration tests and CI/CD pipelines. This way your tests run against a real S2 instance without needing network access or credentials.

​
Cloud service comparison

Start with what’s the same. Both s2.dev and s2-lite implement the core S2 API — the OpenAPI spec is in fact generated from s2-lite — and the same SDKs, CLI, and Studio work with either. For s2-lite, this comparison assumes object storage mode, although local disk and in-memory are also supported.
s2.devs2-lite
ArchitectureElastic — components scale out, and streams migrate to balance loadSingle node that scales vertically, which can take you surprisingly far
Storage enginePurpose-built: low-latency WAL with batched segments on object storageSlateDB on object storage
Append latencyWithin 40 ms on express and 400 ms on standard storage classYour bucket’s PUT latency plus tunable flush interval; typically few hundred ms
DurabilityMulti-AZ before every ack, even on expressInherits your bucket’s durability, typically multi-AZ in the cloud
Read fan-outElastic read-through caching — effectively a CDN for streamsBounded by one node — layer your own caching on top for broadcast scale
SecuritySOC 2, HIPAA, and GDPR compliant; private networking and dedicated cells availableYour perimeter end-to-end — data touches only infrastructure you control
OperationsNone — serverless and scale-to-zero, with usage-based pricingSingle binary and a bucket: yours to provision, monitor, and scale
AuthGranular access controlGate with your own auth layer — access token API support is planned
MaturityGA with a 99.99% availability SLONewer, though shares code with the cloud service, and builds on top of SlateDB
Latency is mostly about proximity. With the cloud service it depends on how close your workload runs to your basin’s location; with s2-lite you control placement, so colocating it and its bucket with your workload can win where S2 does not have a nearby location yet. At a comparable distance, the express storage class delivers multi-AZ durability with tens-of-milliseconds acks — a combination that is hard to match when flushing to a single bucket. Like the cloud service, s2-lite also pipelines appends, so throughput holds up well even against high-latency object storage, and s2 bench makes it easy to measure your own numbers. Cost follows from operations. The cloud service is purely usage-based and scales to zero — there is no instance to keep warm, which for spiky or modest workloads usually makes it cheaper too — and there are no knobs to think about: storage class is the only latency lever, with durability never in question. With s2-lite you pay for the node and the bucket, and the flush interval ties latency to cost: flushing more aggressively acknowledges appends sooner but increases billable object storage requests. Reach for the cloud service when you want a production stream store without operating one: elasticity, high fan-out, the lowest acknowledgment latencies, granular access control. Reach for s2-lite when self-hosting is the point — keeping data in your own bucket and network, running where the cloud service does not (an edge site, an air-gapped environment, a location S2 does not offer yet), or as a zero-dependency emulator in dev and CI. Whichever you start with, the shared API means your application can switch with an endpoint override rather than a rewrite.

​
Init file

s2-lite can pre-create basins and streams at startup from a JSON spec file using the same format used by s2 apply. 
s2 lite --init-file init.json
Or set the environment variable: 
S2LITE_INIT_FILE=init.json s2 lite
The spec is applied with create-or-reconfigure semantics. Resources that already exist are reconfigured to match the spec, and only the fields present in the spec are updated. Example init.json: 
{
  "$schema": "https://raw.githubusercontent.com/s2-streamstore/s2/main/cli/schema.json",
  "basins": [
    {
      "name": "my-basin",
      "config": {
        "create_stream_on_append": true
      },
      "streams": [
        { "name": "events" }
      ]
    }
  ]
}
See CLI: Apply for the full spec file format reference.