> ## Documentation Index
> Fetch the complete documentation index at: https://s2.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# s2-lite

> s2-lite is an open source, self-hosted server implementing S2 APIs as a single binary powered by SlateDB for durable storage.

[<Icon icon="github" /> s2-lite](https://github.com/s2-streamstore/s2) is designed to run as a single instance, making self-hosting straightforward.

See the [README](https://github.com/s2-streamstore/s2?tab=readme-ov-file#design) for more on its internals and quickstart for running it via the `s2` CLI.

[<Icon icon="docker" /> Docker images](https://github.com/s2-streamstore/s2/pkgs/container/s2) are available. You can also use the [Helm chart](https://github.com/s2-streamstore/s2/blob/main/charts/s2-lite-helm/README.md) for deploying to Kubernetes.

The SDKs and CLI can connect to s2-lite by overriding the default endpoints. See [SDK: Endpoints](/sdk/endpoints) and [CLI: Configuration](/cli/configuration) for details.

<Tip>
  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.
</Tip>

## Cloud service comparison

Start with what's the same. Both s2.dev and s2-lite implement the core [S2 API](/api) — the [OpenAPI spec](https://github.com/s2-streamstore/s2-specs/blob/main/s2/v1/openapi.json) is in fact generated from s2-lite — and the same [SDKs](/sdk/languages), [CLI](/cli), and [Studio](/studio) work with either.

*For s2-lite, this comparison assumes object storage mode, although local disk and in-memory are also supported.*

|                    | s2.dev                                                                                                                                                                         | s2-lite                                                                                                                                                     |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Architecture**   | [Elastic](/platform/architecture) — components scale out, and streams migrate to balance load                                                                                  | Single node that scales vertically, which can take you surprisingly far                                                                                     |
| **Storage engine** | Purpose-built: low-latency [WAL with batched segments](/platform/architecture#write-path) on object storage                                                                    | [SlateDB](https://slatedb.io) on object storage                                                                                                             |
| **Append latency** | Within 40 ms on `express` and 400 ms on `standard` [storage class](/platform/architecture#storage-classes)                                                                     | Your bucket's PUT latency plus tunable [flush interval](https://github.com/s2-streamstore/s2?tab=readme-ov-file#slatedb-settings); typically few hundred ms |
| **Durability**     | Multi-AZ before every ack, even on `express`                                                                                                                                   | Inherits your bucket's durability, typically multi-AZ in the cloud                                                                                          |
| **Read fan-out**   | Elastic read-through [caching](/platform/architecture#read-path) — effectively a CDN for streams                                                                               | Bounded by one node — layer your own caching on top for broadcast scale                                                                                     |
| **Security**       | SOC 2, HIPAA, and GDPR [compliant](/platform/security#compliance); [private networking](/platform/private-networking) and [dedicated cells](/platform/cells#tenancy) available | Your perimeter end-to-end — data touches only infrastructure you control                                                                                    |
| **Operations**     | None — serverless and scale-to-zero, with usage-based [pricing](https://s2.dev/pricing)                                                                                        | Single binary and a bucket: yours to provision, monitor, and scale                                                                                          |
| **Auth**           | Granular [access control](/concepts/access-tokens)                                                                                                                             | Gate with your own auth layer — access token API support is planned                                                                                         |
| **Open source**    | Managed service; MIT-licensed API layer and ecosystem projects                                                                                                                 | MIT-licensed server implementation                                                                                                                          |
| **Maturity**       | [GA](https://s2.dev/blog/ga) with a 99.99% availability SLO                                                                                                                    | Newer, 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](/concepts/basins#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`](/cli/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](/sdk/endpoints) 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`](/cli/apply).

```bash theme={null}
s2 lite --init-file init.json
```

Or set the environment variable:

```bash theme={null}
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`:

```json theme={null}
{
  "$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](/cli/apply) for the full spec file format reference.