Sablier

On-demand container lifecycle management, honestly reviewed. For self-hosters running services that sit idle 90% of the time.

TL;DR

• What it is: Open-source (AGPL-3.0) tool that starts Docker containers on demand when a request arrives and shuts them down automatically after a configurable idle period [README].
• Who it’s for: Self-hosters running infrequently-used services on constrained hardware — Raspberry Pi, a single home lab box, QA environments that only get traffic a few times a week [README][1].
• Cost savings: No SaaS pricing to compare against — Sablier is purely self-hosted, free software. The savings are in compute: running 5 idle containers instead of 15 means real RAM and CPU headroom [README][2].
• Key strength: Native reverse proxy integration. Sablier hooks directly into Traefik, Caddy, Nginx, and Envoy via plugins, intercepts incoming requests, starts the sleeping container, and shows a loading page — all transparently to the user [README].
• Key weakness: Tightly coupled to a handful of reverse proxies. If you’re not running Traefik or Caddy, you’ll either migrate your whole stack or build around Sablier rather than with it [2].

---

What is Sablier

Sablier is a single-purpose daemon that solves one specific problem: most self-hosted services sit idle for hours or days, burning RAM and CPU doing nothing. A Jellyfin instance used only in the evenings, a Gitea server touched once a week, a PDF tools container you spin up when you need it — there’s no good reason for these to run continuously.

Sablier watches for incoming HTTP requests through your reverse proxy. When a request hits a stopped container, Sablier intercepts it, starts the container, shows a user-friendly loading page while it boots, and then redirects the visitor to the live service. When nobody visits for a configurable timeout, Sablier stops the container again. The whole cycle is invisible to the end user except for a few seconds of loading page [README].

The project supports Docker, Docker Swarm, Podman, and Kubernetes as container runtimes, and integrates as a plugin or middleware into Traefik, Caddy, Nginx, Envoy, Istio, and Apache APISIX. It ships as a Docker image, a binary, or a Helm chart for Kubernetes. As of this writing it sits at 2,594 GitHub stars under an AGPL-3.0 license [README].

The name has nothing to do with the blockchain token streaming protocol that also goes by “Sablier” — completely different projects with unfortunately colliding names.

---

Why people choose it

The core problem it solves is well-documented in the self-hosting community. A typical home lab operator running 20–30 services on a single box sees most of those services idle the vast majority of the time [2]. A 32GB machine that runs 18GB of active containers at rest would rather use 9GB — and that headroom matters when you’re also running Jellyfin transcoding or Nextcloud syncs [2].

The philosophy is simple: productivity tools don’t need to run 24/7. A diagramming app, a PDF tools container, a budget tracker — these are utilities you reach for briefly then set down [1]. The XDA Developers piece on on-demand containers puts it directly: “productivity should be on demand” [1]. Sablier operationalizes that philosophy at the reverse proxy layer rather than requiring the user to manually run docker start and docker stop.

The Reddit thread where a user built an nginx-proxy alternative to Sablier [2] is actually one of the most useful secondary sources here, because it explains why someone would choose Sablier and why someone wouldn’t. The user called Sablier “really cool” but noted it was designed for Traefik/Caddy specifically — and they weren’t willing to migrate their entire nginx-proxy setup to use it. So they built their own tool instead. That’s both a validation of the concept and a precise statement of Sablier’s primary friction point: it asks you to standardize on a supported reverse proxy [2].

For Traefik users specifically, Sablier is the obvious choice. Traefik already has a plugin ecosystem [4], and Sablier’s Traefik plugin is the most mature of its integrations. If you’re already running Traefik as your reverse proxy, adding Sablier is additive. If you’re not, Sablier is a reason to evaluate the migration, which is a much bigger ask.

---

Features

Container lifecycle management:

• Starts containers on incoming HTTP request via reverse proxy intercept [README]
• Shuts containers down after configurable idle timeout [README]
• Loading/waiting page displayed while container boots — users see a status page rather than a connection error [README][2]
• Supports container grouping for services with dependencies (e.g., start the database before the application) [2]
• Pause mode available: freezes container in place instead of full stop/start — resume is near-instant at the cost of holding RAM [2]

Runtime support:

• Docker (standalone) [README]
• Docker Swarm Mode [README]
• Podman [README]
• Kubernetes [README]

Reverse proxy integration:

• Traefik (plugin) [README][4]
• Caddy [README]
• Nginx [README]
• Envoy [README]
• Istio [README]
• Apache APISIX [README]

Deployment options:

• Docker image on Docker Hub and GitHub Container Registry [README]
• Binary distribution for Linux/macOS/Windows [README]
• Helm chart for Kubernetes production deployments [README]
• Compile from source (Go) [README]

Configuration:

• YAML config file, environment variables, or CLI arguments [README]
• REST API [merged profile]
• Signed binary and container image attestations for supply-chain verification [README]

What it doesn’t do:

• It doesn’t handle path-based routing natively for services sharing a hostname — the nginx-proxy alternative built this specifically because Sablier lacked it [2]
• It doesn’t provide exclude-path rules out of the box, which means monitoring tools (Uptime Kuma, etc.) can inadvertently keep containers awake by health-checking them [2]
• No built-in readiness probes that wait for the app to actually respond — just container-is-running state [2]

---

Pricing: SaaS vs self-hosted math

Sablier has no SaaS offering and no commercial tier. It’s free software under AGPL-3.0 [README].

Self-hosted cost:

• Software: $0
• The hardware you’re already running: you’re already paying for it

The math here isn’t about subscription savings — it’s about resource efficiency on hardware you already own. If a box with 32GB RAM is running 18GB of containers at rest, Sablier can cut that to ~9GB by sleeping idle services [2]. That headroom translates to:

• Faster active services (more RAM available for Jellyfin, database, etc.)
• Lower power draw on always-on hardware
• Ability to run more total services on the same box without upgrading

For cloud deployments: if you’re paying per-GB RAM on a VPS, sleeping 6 idle services that each use 500MB means 3GB freed — which on a Hetzner cloud instance could translate to dropping from a 16GB instance to an 8GB instance. That’s a real monthly saving, but you’d need to instrument it for your own setup.

The AGPL-3.0 license is worth noting for anyone building a commercial product on top of Sablier. AGPL requires that source code be made available to users who interact with your service over a network. If you’re embedding Sablier into a commercial offering, talk to a lawyer. For personal and business internal use, AGPL is not a constraint [README].

---

Deployment reality check

What you need:

• A running reverse proxy — Traefik, Caddy, Nginx, or Envoy. Sablier integrates as a plugin/middleware, not as a standalone proxy [README]
• Docker (or Docker Swarm, Podman, Kubernetes)
• The Sablier container running alongside your stack, mounted to the Docker socket

Traefik setup (the happy path):

Traefik users are Sablier’s primary audience and the integration is well-documented. You add Sablier as a service in your docker-compose, add the Traefik plugin configuration, and label your target containers. The README provides a quickstart demo using a mimic container for testing [README].

What can go wrong:

First, monitoring tools are a real problem. If Uptime Kuma is health-checking your services every 60 seconds, it will keep every container awake indefinitely. The nginx-proxy alternative built an exclude_paths feature specifically for this [2] — check whether Sablier’s current version handles this before you deploy.

Second, dependency ordering matters. If your application depends on a database, you need to ensure both start together. The alternative tool from Reddit [2] built explicit container grouping for exactly this reason. Sablier may handle this, but the README excerpt doesn’t detail it clearly — verify against current docs before assuming.

Third, the loading page experience degrades for APIs. If a mobile app or script is hitting your service expecting JSON, getting an HTML loading page is a breaking change. Sablier is designed for browser-accessed web UIs, not headless API clients. Know which services you’re applying it to.

Fourth, the AGPL license on Sablier means the Docker socket mount gives it substantial access to your container runtime. Verify and trust the project before granting that access, as with any tool that touches the Docker socket.

For Traefik users on a home lab: realistic setup time is 30–60 minutes to a working demo, a few hours to configure for all target services thoughtfully. For Caddy or Nginx users: budget extra time to understand the plugin/middleware model for your specific proxy.

---

Pros and Cons

Pros

• Solves a real problem cleanly. Idle containers wasting resources is a genuine home lab pain point, and Sablier’s reverse-proxy interception model is the right architectural approach — the proxy layer is already seeing every request, so that’s where the wake-up logic belongs [README][2].
• User-visible loading page instead of connection errors. The alternative tools that predate Sablier showed users connection errors while containers booted. Sablier’s waiting page is a material UX improvement [2].
• Broad reverse proxy support. Traefik, Caddy, Nginx, Envoy, Istio, APISIX — if you’re running any mainstream proxy, there’s an integration [README].
• Multiple container runtimes. Docker, Swarm, Podman, Kubernetes — not locked to a single orchestrator [README].
• Signed releases. The README explicitly documents how to verify image and binary attestations — a good sign for operational security in a tool that touches the Docker socket [README].
• Actively maintained. Discord server, OpenSSF Scorecard badge, DigitalOcean sponsorship — the project signals real investment [README].

Cons

• Proxy lock-in. The biggest complaint in the wild: if you’re not on Traefik or Caddy, Sablier is a poor fit. The Reddit user who built an alternative did so specifically because migrating from nginx-proxy to Traefik felt like too much work just to get scale-to-zero [2].
• No exclude-path support (verify current state). Monitoring and health-check traffic can keep containers awake. Whether Sablier handles this natively needs verification against current docs — the alternative project built this as a first-class feature [2].
• No native container grouping documentation in README excerpt. Dependency ordering (app + database + cache) is a real operational need. The alternative project treats this as core [2] — unclear how Sablier handles it.
• No readiness probe by default. A container can be “running” but not yet serving traffic. The alternative waits for an actual HTTP response through the proxy [2] — verify whether Sablier does the same or just checks container state.
• AGPL-3.0 license. Not MIT. Embedding Sablier in a commercial product or hosted service requires careful review. Fine for internal and personal use, but worth flagging [README].
• API clients break. The waiting page is HTML. Any non-browser client hitting a sleeping container gets a bad response. Only deploy on browser-accessed services [README][implied].
• 2,594 stars — solid for a niche tool, but community size is smaller than Traefik or Caddy themselves, which means debugging novel issues may require going directly to Discord or the GitHub issues.

---

Who should use this / who shouldn’t

Use Sablier if:

• You run Traefik or Caddy as your reverse proxy and don’t plan to change.
• You have 10–30 browser-accessed services, most of which sit idle for hours at a time.
• You’re on constrained hardware — a Raspberry Pi, a budget VPS, or a single home lab box — where reclaiming RAM from idle services has real impact.
• Your QA or staging environment only gets traffic a few times a week and you want it dormant otherwise.
• You’re running tools like Excalidraw, PDF utilities, or budget trackers that you access occasionally and don’t need always-on [1].

Think carefully before using it if:

• You’re on nginx-proxy and don’t want to migrate your entire reverse proxy stack. The Reddit user who built an alternative specifically because of this represents a real and common situation [2].
• Any of your target services have API clients (mobile apps, scripts, webhooks) rather than browser users. The HTML waiting page will break those clients.
• Your services have complex startup dependencies that require ordered initialization — verify Sablier handles this before you’re debugging it in production.
• Your monitoring system (Uptime Kuma, etc.) health-checks your services, because it will keep containers awake. Solvable, but requires configuration.

Skip it entirely if:

• Your services need to respond in under 2 seconds and your containers take 10+ seconds to boot. The loading page experience becomes frustrating at that latency.
• You’re running production customer-facing services. Scale-to-zero introduces cold-start latency that’s appropriate for internal tools and home lab, not for services where a visitor’s first impression matters.
• You need a managed or SaaS version — there isn’t one. This is infrastructure you operate yourself.

---

Alternatives worth considering

nginx-proxy-ondemand [2] — Built specifically for nginx-proxy users who found Sablier too Traefik-centric. Adds container grouping, pause mode, exclude-path rules, and HTTP readiness probes. If you’re on nginx-proxy, this is worth evaluating before migrating your proxy stack.

Lazytainer — Mentioned in the Reddit thread [2] as the other existing alternative before nginx-proxy-ondemand. Works with any proxy via network-level container configuration, but has no loading page — users see a connection error while the container boots. A step behind Sablier UX-wise.

Manual docker start/stop — For services you access extremely infrequently (once a week), the operational overhead of Sablier may not be worth it. A shell alias to docker start myservice && open http://myservice.local is zero dependencies and zero configuration.

Kubernetes HPA + KEDA — For Kubernetes-native scale-to-zero, KEDA (Kubernetes Event-Driven Autoscaling) is the production-grade path. More complex to configure, but designed for production workloads where you need fine-grained scaling behavior rather than binary on/off.

WakeOnLAN + full machine sleep — For the most extreme resource savings on a home server, sleeping the entire machine and waking it on network activity goes further than container-level sleep. A different problem, but worth mentioning for the Raspberry Pi crowd.

---

Bottom line

Sablier does one thing and does it cleanly: it wakes sleeping containers when someone visits, shows them a loading page, and puts the container back to sleep after idle time. For Traefik and Caddy users running mixed home lab services — some accessed daily, some accessed weekly, some almost never — it’s a low-friction way to reclaim significant RAM without manual management overhead. The architecture is sound: intercepting at the reverse proxy layer rather than the container layer is the right design.

The constraints are real and worth stating plainly. AGPL-3.0 instead of MIT matters for commercial use. The reverse proxy coupling means nginx-proxy users need to either migrate or look at alternatives. The loading-page model only works for browser users. And some operational gaps (exclude-paths, container grouping, readiness probes) may need verification against current docs before you deploy.

For a non-technical founder running internal tools — a project management app, an analytics dashboard, a dev environment — on a VPS they want to keep cheap, Sablier is worth an afternoon of setup. The resource savings on a 5-10 service home lab are real. If you want someone to deploy and configure it for you, that’s exactly the kind of one-time infrastructure work that upready.dev handles for clients.

---

Sources

1. Yash Patel, XDA Developers — “4 productivity Docker containers that don’t require 24/7 runtime” (Dec 8, 2025). https://www.xda-developers.com/on-demand-productivity-docker-containers/
2. r/selfhosted (Reddit) — “I built a Sablier alternative which is plug-and-play for nginx-proxy users”. https://www.reddit.com/r/selfhosted/comments/1rs5cgf/i_built_a_sablier_alternative_which_is/
3. Brandon Lee, Virtualization Howto — “Best Traefik Plugins for Home Lab and Production (My Top Picks)” (Sep 4, 2025). https://www.virtualizationhowto.com/2025/09/best-traefik-plugins-for-home-lab-and-production-my-top-picks/

Primary sources:

• GitHub repository and README: https://github.com/sablierapp/sablier (2,594 stars, AGPL-3.0 license)
• Official website: https://sablierapp.dev
• Docker Hub image: https://hub.docker.com/r/sablierapp/sablier