DEV Community

Denis Tulupov
Denis Tulupov

Posted on

Conslee: a tiny Docker-aware reverse proxy that lets your containers sleep

I run a small homelab with the usual suspects: dashboards, admin panels, tools I don’t need every minute but still want “one click away”. The problem is familiar to anyone self-hosting for a while: either you keep everything running 24/7 or you start growing a zoo of systemd timers, cron jobs and bash scripts that start and stop containers on a schedule.

At some point I got tired of that trade-off and wrote my own tool in Go. That project became Conslee.

Conslee is a small reverse proxy that understands Docker. Instead of blindly forwarding traffic to always-on backends, it knows which containers belong to which “service” and can start them on demand, stop them again after an idle period, or keep them online only during a configured time window. It sits behind your existing reverse proxy like nginx or Caddy, so HTTPS termination and public routing can stay exactly as they are. You just point your upstream to Conslee instead of directly to a container port.

The idea is simple. You define a service by host name, for example portainer.example.com. Conslee watches incoming HTTP requests, and when the first request for that host arrives, it checks whether the corresponding container is running. If not, it starts the container through the Docker API, waits until the backend is actually listening and, if configured, performs a quick HTTP healthcheck like / or /health. Only after that it forwards the original request. From the user’s point of view this looks like a slightly slower first page load and then normal behaviour afterwards.

Each service tracks its last activity time. Conslee runs an idle reaper loop in the background and periodically looks for services that haven’t seen any traffic for a while. If a service has been idle longer than its configured timeout, Conslee stops the containers for that service. Heavy apps that you only open occasionally no longer need to sit in memory all day just in case.

In addition to idle timeouts there is also a schedule mode. For each service you can choose how it should behave: only on demand, only by schedule or a mix of both. The schedule is defined by weekdays and a time window, including cases that cross midnight. That makes it possible to keep something awake only during working hours, or during the evening, while still relying on auto-start when someone hits the URL within that allowed window.

I wanted Conslee to be usable without touching YAML every time I add or change a service, so it comes with a small web UI. The UI is served from /ui/ and lets you see all services, check which ones are running, adjust idle and startup timeouts, change the schedule and healthcheck path, and pick containers directly from the list that Conslee gets from the Docker socket. Underneath, there is a simple REST API that the UI uses, so it’s easy to automate things from scripts or other tools if you like.

Implementation-wise, Conslee is deliberately focused. It talks only to the local Docker engine through the socket, understands stacks and labels enough to suggest containers in the UI, and stores its configuration in a YAML file. On first run, if the config file is missing, it creates a minimal default so you don’t have to prepare anything up front. There is no Kubernetes support, no cluster management and no attempt to become a full orchestrator. The goal is to stay small, understandable and predictable for a single host.

Right now Conslee is at an early stage (v0.1.0), but it already runs my own stack and has survived a bunch of refactors. I’m exploring more adaptive modes for keeping services “awake” or “asleep”, and different ways to decide what “activity” means beyond a simple idle timer, but I’m trying to keep the core behaviour easy to reason about.

If the idea of “sleeping containers” that wake up on demand or on a schedule sounds useful for your homelab, you can take a look at the code and docs here:
GitHub: https://github.com/tulupovden/conslee
I’d be happy to hear how you would use something like this, and what would be important for you before trusting it with your own services.

Top comments (0)