Redis-Compatible Cache Server

See client traffic turn into cache hits, misses, and persisted state.

Chabi sits between multiple clients and your cached data, exposing the request path, metrics surface, and snapshot behavior you need to run it with confidence.

Read The DocsSelf Host ChabiView Benchmarks
RESP compatibleSnapshot persistencePrometheus metricsDocker self-hosting
Live traffic preview
Hit rate92.4%
Miss rate7.6%
Sampled reads1.8k/s
Clients
api-1
worker-2
web-3
queue-4
Cache
GET session:42hit
SET feed:homewrite
SAVEsnapshot
Snapshot / DiskPersisted state/data/chabi.kdb
Why engineers evaluate Chabi

A cache server that reads like infrastructure, not just branding.

Client Flow

Traffic path

Multiple Redis-compatible clients converge on one cache layer, with clear separation between fast cache hits and slower miss paths that need a deeper read or restore path.

  • Multiple clients, one cache edge
  • Hit and miss behavior is visible
  • Redis-style request flow stays central
Observability

Operate it

Chabi keeps the operational surface small and explicit: health on `/`, Prometheus text on `/metrics`, and in-memory snapshot visibility on `/snapshot`.

  • Prometheus-friendly metrics
  • Health and snapshot inspection
  • Inspectable without extra services
State

Persist it

Snapshots are part of the runtime story, not an afterthought. Mount `/data`, set an interval, and keep the path from memory to disk straightforward.

  • Configurable snapshot path
  • Timed background persistence
  • Docker-first self-hosting path
BenchmarksHetzner CCX23

Published throughput stays visible from the landing page.

Current published comparison: Chabi 35633 ops/sec, Redis 12267, DiceDB 15655.

Open Benchmark Results
Self HostingDocker Compose

Container-first deployment with an explicit persistence path.

Start with ghcr.io/envsync-cloud/chabi:latest, expose Redis and HTTP, and mount /data for snapshots.

Open The Compose Guide