Labels are not enforced on InstanceStart/InstanceStop operations

[mzyy94]

Describe the bug
sablier.enable=true labels are checked during discovery (InstanceList, InstanceGroups), but the operational methods — InstanceStart, InstanceStop, and NotifyInstanceStopped — do not validate whether the target instance has the management label.

Was this the intended behavior when the label system was introduced in #134 ? It seems like the label was meant to define which instances Sablier manages, but the enforcement is only partial — discovery respects it, while operations do not.

This means:

1. Any container can be started/stopped by name through the Sablier API, even if it was never intended to be managed by Sablier
2. Session expiry stops unlabeled containers — OnInstanceExpired calls InstanceStop without any label check, so a container started via Sablier API (even without the label) will be stopped when the session expires.
3. NotifyInstanceStopped watches all containers — Docker/Podman listen to all die events, Kubernetes informers watch all deployments/statefulsets, regardless of labels.

Context

• Sablier version: <= 1.11.2
• Provider: all
• Reverse proxy: N/A
• Sablier running inside a container? No

Expected behavior

• InstanceStart / InstanceStop should return an error when the target instance does not have the management label.
• NotifyInstanceStopped should only report events for managed (labeled) instances.
• Session expiry should gracefully handle the case where a container is not managed.

Additional context

• I ran into a case with Caddy wildcard setup where an unlabeled container that was already running got stopped when a session expired. It wasn't meant to be managed by Sablier at all.

[acouvreur]

The overall design of labels is for auto discovery and configuration at the instance level. So this is kinda wanted.

I ran into a case with sablierapp/sablier-caddy-plugin#33 (comment) where an unlabeled container that was already running got stopped when a session expired. It wasn't meant to be managed by Sablier at all.

That's unexpected, can you please give more details about your setup ?

Sablier only stops containers it starts in the first place.

[mzyy94]

here's my setup:

I have multiple containers on the same Docker host — some are managed by Sablier (with sablier.enable=true), and others are long-running services that have nothing to do with Sablier (no label).

*.lab.example.com {
    route {
        sablier {
            names {labels.3}
            dynamic
        }
        reverse_proxy {labels.3}:8080
    }
}

With this wildcard config, any subdomain resolves to a container name. The container in question didn't have sablier.enable=true label — so I didn't expect Sablier to start or stop it at all.

But here's what happens:

1. I access foo.lab.example.com — Caddy sends a start request to Sablier InstanceStart("foo")
2. Container foo is already running (it doesn't have sablier.enable=true label and was started independently, not by Sablier)
3. Sablier sees it's ready (=container running) and the request passes through — but a session is now created
4. When the session expires, OnInstanceExpired calls InstanceStop("foo")
5. The container gets stopped, even though Sablier didn't actually start it

So technically Sablier does "start" it (via InstanceStart), but the container was already running before Sablier got involved. Since I hadn't labeled it, I assumed it would be left alone.

[acouvreur]

I understand, you want to have a single entrypoint for sablier using Caddy, but that backfired by trying to start every containers.

The issue that I see, is that you will still invoke the middleware in every containers accessed through Caddy.

So if you want that to work, the API would need to silently fail / ignore. Which I think is a bit counter intuitive.

---

Your setup clearly overuse the middleare and invoke Sablier when it should not. How do you think we should fix this ?

[mzyy94]

You're right, my setup overuses the middleware. I think the fix could work at two levels:

• Sablier Provider level: A strict mode where the API rejects unlabeled containers (Enforce management labels on InstanceStart/InstanceStop/NotifyInstanceStopped #858)
• Reverse Proxy level: Skip Sablier handler entirely for unlabeled containers

If this doesn't align with the project's design philosophy, feel free to close the issue and PR — no hard feelings!

[acouvreur]

I think the strict mode is a good feature, but it should probably be implemented in a way that would not fit your needs.

However, I know that a lot of people want a to be able to do that with Sablier. Right now, each instance must define it's own middleware for Traefik and it's a bit painful.

So that feature set might be useful for those scenarios.

Maybe instead of strict mode, a simple ignore-unlabeled or ignore-non-enbled etc. would work.

[mzyy94]

Oh yeah, ignore-unlabeled sounds like a better direction, more intuitive than strict mode. I'll close the PR for now. Thanks for the feedback!

[massimeddu-sj]

I think we have a similar use case. We use sablier for ephemeral environments in K8s, so we deploy the deployments using labels

sablier.enable: "true"
sablier.group: default-{{ trimSuffix "-" (trunc 55 $.Release.Namespace) }}

Now, sometimes we promote this ephemeral environments to persistent ones, so we remove these labels from the deployments.

However sablier apparently still try to scale down the deployments that it found during discovery, not checking when scaling down if the label is still present or not.

This is quite annoying for us as it requires to restart sablier to flush the memory and force re-discovery.

Is your PR able to fix this use case as well @mzyy94 ?

Thanks

[louisdtt]

We have been running into the exact same issue as @massimeddu-sj, we want to use Sablier for ephemeral dev envs, they sometimes need to be kept on for awhile so we thought of removing Sablier labels on them, but they are still getting downscaled after session ends which is not optimal for us

[mzyy94]

@massimeddu-sj @louisdtt The PR should handle your use case. It re-checks the label at InstanceStop time, so removing sablier.enable from a deployment would prevent Sablier from scaling it down. Feel free to try it out :)

[louisdtt]

Hey @mzyy94, I tried out your enforce-label-check branch, in a local kind cluster with --provider.strict-labels=true, it works well and I think it could be a nice addition to the project, i saw that the associated PR was closed, do you plan on reopening it ? Thanks

[louisdtt]

Hello @mzyy94, do you mind if I open a PR based on your enforce-label-check branch ? The feature as it is works well for us, i'd be happy to tweak it a bit, change the flag to ignore-unlabeled maybe, add documentation... Thanks