Sablier: scale-to-zero for Docker, Podman, Kubernetes and Proxmox LXC workloads

The problem Sablier solves: idle workloads that still cost memory

A self-hosted stack accumulates services nobody uses most of the day. A wiki, a dashboard, a QA instance used once a week. Each one holds RAM and CPU while it waits. Sablier's premise is that a container only needs to run while someone is actually talking to it. The README frames the target audience directly: a resource-constrained device such as a Raspberry Pi, a QA environment used once a week, or cloud workloads where scaling idle services to zero cuts the bill. It is free and open-source software, licensed AGPL-3.0, written in Go, and it ships as a container image, a binary, or a Helm chart. The unit of work is a group of containers rather than a single one, which matters because a typical service is a web frontend plus a database plus a cache, and starting only the frontend gets you nothing.

How Sablier decides to wake a workload

Sablier sits between the user and the workload. It does not proxy traffic itself. Instead, a reverse proxy plugin intercepts the incoming request, asks Sablier whether the target group is running, and if not, Sablier starts the containers and the plugin serves a waiting page until they are ready. The README lists Traefik, Caddy, Nginx, Envoy, Apache APISIX and Istio as integrations. Two mechanisms control readiness. A healthcheck tells Sablier the difference between a container that has started and one that can accept requests; the README warns that without a healthcheck Sablier cannot make that distinction, and marks it as a caution rather than a suggestion. The group label ties containers together: the quick start applies sablier.enable=true and sablier.group=demo to a container, and the proxy plugin addresses that group by name. Stopping is time-based. After a period of inactivity Sablier stops the group, and the README documents both stop and pause strategies, the latter for reclaiming resources without a full cold start. Scale mode is a third path: instead of stopping a workload, Sablier throttles its CPU and memory when idle, which the README describes as zero-cold-start.

Installing Sablier and running a first workload

The fastest path is the Docker image, which the README publishes on Docker Hub as sablierapp/sablier and on GHCR as ghcr.io/sablierapp/sablier. The compose file below starts Sablier with the Docker provider, exposes port 10000, and mounts the Docker socket so Sablier can inspect and start sibling containers. Run docker compose up -d and the service should come up listening on 10000.

services:
  sablier:
    image: sablierapp/sablier:1.18.0
    command:
      - start
      - --provider.name=docker
    ports:
      - "10000:10000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Next, start a workload that Sablier is allowed to manage. The README uses sablierapp/mimic, a configurable test web server, with a health command and two labels. The healthcheck is what lets Sablier know the container is ready; without it the README says Sablier cannot distinguish started from ready.

docker run -d --health-cmd "/mimic healthcheck" -p 8080:80 --name mimic \
  --label sablier.enable=true \
  --label sablier.group=demo \
  sablierapp/mimic:v0.3.3 \
  -running -running-after=5s \
  -healthy=true -healthy-after=5s

Now stop it to simulate the scaled-down state: docker stop mimic. Sablier can also stop containers at startup with --provider.auto-stop-on-startup, so an existing stack does not have to be shut down by hand. For Kubernetes, the README points to the Helm chart: helm repo add sablierapp https://sablierapp.github.io/helm-charts, then helm repo update and helm install sablier sablierapp/sablier. The binary route is a release tarball plus ./sablier --help, and the README notes that release images and binaries can be checked with gh attestation verify.

Where Sablier gets in the way

The waiting page is the honest cost of the design. A user who hits a sleeping group does not get their application; they get a themed page until the workload is ready. For an internal dashboard that is fine. For anything a customer pays for, it is a visible regression compared with leaving the service running. The healthcheck requirement is a second constraint that is easy to underestimate: a container without one is not safely scalable to zero, so every image in the group needs a working health command, and getting that wrong produces a service that either never becomes ready or is woken while still initializing. Third, the integration surface is narrow by design. Sablier does not terminate traffic itself, so it is useless unless your reverse proxy has a plugin in the supported list. The repository's examples directory shows how much configuration lives outside the tool: separate folders for anti-affinity, depends-on, running-hours, restart-policy, reject-unlabeled-requests and docker-socket-proxy. That last one is a hint about the security posture, since the Docker provider needs access to the Docker socket, which is effectively root on the host. The README does not document rollback behaviour for a group that fails to start, and it does not describe what happens to in-flight requests when a group is stopped mid-session.

Sablier compared with a plain reverse proxy and a scheduler

The obvious alternative is doing nothing: leave the containers running and let the reverse proxy route to them. That is simpler and has no cold start, and on a machine with spare RAM it is the right answer. Sablier's difference is that it makes the running state a function of demand rather than of deployment. A second alternative is a job scheduler such as cron or a systemd timer that starts and stops units on a fixed timetable, which the repository acknowledges with an examples/systemd directory. The difference in approach is fixed time versus observed activity: a timer does not know whether anyone is using the service, so it either stops a service that is in use or keeps one alive that is not. Sablier keys off requests reaching the proxy. A third comparison is the platform-native autoscaler, for example a Kubernetes HorizontalPodAutoscaler, which scales replicas between a minimum and a maximum based on metrics. That never reaches zero replicas by default and reacts to load rather than to the presence of a request, so it solves a different problem: capacity under load rather than elimination of idle capacity.

Maintenance, upgrades and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-23, one day before this review. Recent releases are close together: v1.16.2 on 2026-08-12, v1.17.0 on 2026-08-23, and v1.18.0 on 2026-09-02. Upgrade cost is mostly configuration drift rather than code. The Makefile shows that the project generates its own reference documents, including the CLI reference, the label reference, the OpenAPI schema, the metrics documentation and the theme JSON schema, and it includes check targets that fail if the generated files are out of date. Practically, that means labels and CLI flags are versioned artifacts you can diff between releases instead of guessing. The image tag in the README is pinned to a full version such as 1.18.0, not a floating tag, which makes upgrades a deliberate edit. On licensing, Sablier is AGPL-3.0, the strongest of the common copyleft licences, and it applies to a network service. If you modify Sablier and let users interact with it over a network, the AGPL's source-availability condition is the part to read with your own counsel; this article is not legal advice. Running the unmodified image as a separate service is a different situation from embedding its code in your product.

Editorial conclusion

Adopt Sablier if you run self-hosted services, a QA environment, or constrained hardware where idle containers should not hold memory, and if you can attach healthchecks and route traffic through a supported reverse proxy. Do not adopt it if a cold start of your workload is unacceptable to users, or if your proxy is not in the plugin list. Before rolling it out, verify three things: that every workload carries a healthcheck, that the group labels match what your proxy plugin sends, and that your chosen stop strategy (stop or pause) behaves as you expect on your provider.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. sablierapp/sablier on GitHub