Commanding Sablier Directly using GET Requests

A spelled-out topology following the trafik, sablier and background services layout that follows roughly the same abstraction but is expressed from the point of view of requests can be depicted by the following diagram:

where a request arrives and is then routed by a reverse-proxy like traefik onto sablier which then reaches a target container, possibly by waking up the container via sablier.

The problem is that the request arrives externally such that it first reaches the reverse-proxy, from where traefik and sablier can work together to determine what has to be done but a request might originate from a container trying to reach another container that could possibly be stopped in which case the request would fail.

Illustrated, container B now tries to reach services inside container A by making a request that takes place through the internal Docker bridge/VLAN such that the reverse proxy or sablier itself is never reached at all:

The result will be that the request would fail.

A possible fix would be to get container B to make a request through the external exposed hostname of the reverse proxy. Following the example, the request from container A will then have to traverse the whole chain all the way through the reverse proxy, sablier and then to container A. However, doing so has the obvious Address Resolution Protocol (ARP) issues where a request might be sent to sablier but when container B answers, the packets will be dropped because the MAC address between the destination and the source of the request do not match. Similarly, even if the ARP issue is addressed, perhaps by enabling martian packets, the solution is still messy because the request will have to go through the public hostname which might be protected by something like authelia and would thus need some credentials to be supplied as well.

Looking at the way that traefik works with sablier, requests can be observed by passing the parameter --logging.level=trace to sablier which allows the data to be monitored by looking at the log output and without any help from packet sniffing. The following is an example request from traefik to sablier that gets logged by sablier:

4:00AM INF slog-gin@v1.15.1/middleware.go:265 Incoming request request.time=2025-10-08T03:59:40.952Z request.method=GET request.host=sablier:10000 request.path=/api/strategies/blocking request.query="group=karakeep&session_duration=5m&timeout=5m" request.params=map[] request.route=/api/strategies/blocking request.ip=172.18.0.5 request.referer="" request.length=0 response.time=2025-10-08T04:00:25.887Z response.latency=44.935076469s response.status=200 response.length=0 id=0babb62c-2bac-452f-ac35-9051d8533108

which instructs sablier to start the services bound by the karakeep group label.

The request seems like a fairly standard GET request and if traefik can send one, then so can we, so here is the equivalent of the request logged by sablier using cURL:

curl \
  -G \
  --data-urlencode "group=karakeep" \
  --data-urlencode "session_duration=5m" \
  --data-urlencode "timeout=5m" \
  "http://sablier:10000/api/strategies/blocking"

which, on the client will output:

* Host sablier:10000 was resolved.
* IPv6: (none)
* IPv4: 172.18.0.24
*   Trying 172.18.0.24:10000...
* Connected to sablier (172.18.0.24) port 10000
* using HTTP/1.x
> GET /api/strategies/blocking?group=selenium&session_duration=5m&timeout=5m HTTP/1.1
> Host: sablier:10000
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< X-Request-Id: 3f794ae2-6fe4-45ab-b502-4725b7e5ca4c
< X-Sablier-Session-Status: ready
< Date: Wed, 08 Oct 2025 04:43:12 GMT
< Content-Length: 0
<
* Connection #0 to host sablier left intact

with sablier logging the request and starting the services in the selenium group.

So, in other words, a compliant solution is to perform two requests, one request will go to sablier and tell sablier to start the necessary services.

and then the second request will be the one that accesses the services from one container to the other.

The tradeoff is that there is no seamless transfer in just one request and there has to be the ability to send a preceding HTTP request before accessing the services.