Olá a todos!
Quem me segue aqui há algum tempo sabe que eu tenho uma relação complicada com recursos desperdiçados. Não é mesquinhice, é princípio de engenharia. Cada container que está a correr sem ninguém lhe tocar é memória ocupada, CPU desperdiçado, e watts na conta da electricidade que podiam estar a fazer outra coisa. E se tens dois ou três serviços, a coisa ainda se aguenta. Mas quando tens vinte, trinta, quarenta containers no homelab ou num cluster de produção, e metade deles só são usados uma vez por semana ou duas vezes por mês, começas a perceber que estás a pagar para aquecer silício sem razão nenhuma.
Foi exactamente isto que me levou ao Sablier, e hoje vou explicar o que é, como funciona, como o podes meter no teu stack, e porque é que considero esta ferramenta uma peça fundamental na forma como penso a gestão de recursos em infraestrutura. Não importa se tens um Raspberry Pi na cave ou um cluster Kubernetes em produção. O conceito é o mesmo, e a poupança é real.
E sim, este post foi escrito com ajuda de um LLM particular.
O problema que toda a gente tem mas poucos param para resolver
Vamos começar pelo básico. A maioria das pessoas que corre serviços self-hosted, seja em casa ou em ambiente profissional, segue o mesmo padrão: levanta os containers, configura o reverse proxy, e esquece. Os serviços ficam ali, eternamente ligados, à espera que alguém lhes bata à porta. E para alguns serviços faz sentido. O teu DNS, o teu reverse proxy, o teu sistema de monitorização, essas coisas precisam de estar sempre activas. Mas aquele Stirling PDF que usas uma vez por semana? Aquele Draw.io que abres de vez em quando? Aquele ambiente de QA que a equipa de testes só toca às segundas? Não, esses não precisam de estar always on.
O problema é que ninguém quer ter o trabalho de andar a ligar e desligar containers manualmente. E com razão. É pouco prático, esquecemo-nos, e no fim acabamos por deixar tudo ligado porque “não custa nada”. Mas custa. Custa RAM que podia estar a ser usada por serviços que realmente precisam dela. Custa CPU cycles que podiam estar disponíveis para workloads reais. E em ambientes cloud, custa dinheiro literal, porque pagas por recurso alocado, não por recurso utilizado.
A cloud prometeu-nos elasticidade, mas na prática a maioria das pessoas corre os serviços como se estivessem numa máquina física dos anos 2000: tudo ligado, o tempo todo, reze quem quiser. E o on-premise não é diferente. Quem tem homelabs sabe que a memória é finita, que as placas gráficas não crescem, e que cada gigabyte de RAM ocupado por um container adormecido é um gigabyte que não podes dar ao teu LLM local ou ao teu servidor de bases de dados.
O que é o Sablier?
O Sablier é um projecto open source, gratuito, licenciado, que faz uma coisa simples e fá-la muito bem: arranca os teus workloads quando alguém precisa deles e desliga-os automaticamente quando ninguém os usa durante um período de tempo que tu defines. É, na sua essência, um sistema de scale-to-zero para serviços HTTP.
O nome vem do francês e significa “ampulheta”, o que é uma metáfora perfeita para o que o software faz. Cada vez que alguém acede ao serviço, a ampulheta vira-se. Enquanto houver actividade, o serviço fica de pé. Quando a areia acaba, o serviço deita-se. É elegante na simplicidade.
Na prática, o Sablier funciona como uma API que se integra com o teu reverse proxy. Quando um pedido HTTP chega para um serviço que está desligado, o Sablier intercepta esse pedido, arranca o container (ou o deployment, ou o pod, ou o LXC, depende do provider), espera que ele esteja saudável, e depois entrega o pedido ao serviço como se nada tivesse acontecido. O utilizador pode ver uma página de espera temática durante uns segundos (a chamada “dynamic strategy”) ou simplesmente experimentar um tempo de resposta um pouco mais longo no primeiro pedido (a “blocking strategy”). A partir daí, o serviço fica activo durante o tempo que configurares, e quando a sessão expira sem nova actividade, o Sablier desliga-o outra vez.
Suporta Docker standalone, Docker Swarm, Kubernetes, Podman e até Proxmox LXC como providers. Do lado dos reverse proxies, integra-se com Traefik (via plugin nativo), Caddy (via módulo nativo), Nginx (via WASM), Envoy (via Proxy-WASM), Istio e Apache APISIX. Ou seja, é agnóstico o suficiente para encaixar em praticamente qualquer stack que tenhas.
E os números de performance são interessantes: o Sablier adiciona cerca de 1.5 a 2 milissegundos de latência por pedido quando o container já está a correr (o chamado warm path), e aguenta entre 5000 e 5750 requests por segundo num único core. Os cold starts dependem exclusivamente do tempo que o teu container demora a arrancar. Uma vez pronto, estás de volta à latência normal imediatamente.
Deployment na prática: pôr o Sablier a trabalhar
Vamos ao que interessa. Vou mostrar como montar isto com Traefik e com Caddy, que são os dois reverse proxies que mais uso e que mais recomendo para este tipo de cenário.
Cenário 1: Docker Compose com Traefik
Este é provavelmente o cenário mais comum para quem tem um homelab ou um servidor de serviços interno. Tens o Traefik como reverse proxy, uma rede Docker partilhada, e um ou mais serviços que queres gerir com o Sablier.
Começas pelo docker-compose do Traefik e do Sablier em si. O Sablier precisa de acesso ao Docker socket para poder gerir os containers:
services:
traefik:
container_name: traefik
image: traefik:v3
ports:
- "80:80"
- "443:443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./traefik.yml:/etc/traefik/traefik.yml:ro
- ./dynamic:/etc/traefik/dynamic:ro
networks:
- traefik
restart: unless-stopped
sablier:
container_name: sablier
image: sablierapp/sablier:1.14.0
command:
- start
- --provider.name=docker
volumes:
- /var/run/docker.sock:/var/run/docker.sock
networks:
- traefik
restart: unless-stopped
networks:
traefik:
name: traefik
external: true
No teu ficheiro traefik.yml, precisas de registar o plugin do Sablier:
experimental:
plugins:
sablier:
moduleName: "github.com/acouvreur/sablier"
version: "v1.3.0"
providers:
docker:
endpoint: unix:///var/run/docker.sock
exposedByDefault: false
network: traefik
file:
directory: /etc/traefik/dynamic
Agora, o serviço que queres gerir. Digamos que tens um Stirling PDF que usas de vez em quando. A partir do Traefik v3.6.0, podes usar labels directamente no container:
services:
stirling-pdf:
image: frooodle/s-pdf:latest
container_name: stirling-pdf
labels:
- "sablier.enable=true"
- "sablier.group=pdf-tools"
- "traefik.enable=true"
- "traefik.docker.allownonrunning=true"
- "traefik.http.routers.stirling.rule=Host(`pdf.exemplo.local`)"
- "traefik.http.routers.stirling.middlewares=stirling-sablier"
- "traefik.http.middlewares.stirling-sablier.plugin.sablier.sablierUrl=http://sablier:10000"
- "traefik.http.middlewares.stirling-sablier.plugin.sablier.sessionDuration=30m"
- "traefik.http.middlewares.stirling-sablier.plugin.sablier.dynamic.displayName=Stirling PDF"
- "traefik.http.middlewares.stirling-sablier.plugin.sablier.dynamic.theme=hacker-terminal"
networks:
- traefik
Repara naquela label traefik.docker.allownonrunning=true. Isto é crítico. Sem ela, o Traefik ignora containers que estão parados, e nunca chega a chamar o Sablier para os ligar. Com esta flag, o Traefik mantém a rota registada mesmo quando o container não está a correr.
A partir daqui, o fluxo é automático. Alguém acede a pdf.exemplo.local, o Traefik vê que o container não está a correr, chama o Sablier, o Sablier arranca o container, o utilizador vê uma página de espera simpática com o tema que escolheste (neste caso o hacker-terminal, que é o que eu uso), e passados uns segundos tem o Stirling PDF à frente. Se ninguém lhe tocar durante 30 minutos, o Sablier desliga-o. Zero intervenção manual.
Em alternativa ao método de labels, se estiveres numa versão mais antiga do Traefik ou se preferires manter a configuração centralizada, podes usar ficheiros de configuração dinâmica:
http:
middlewares:
stirling-sablier:
plugin:
sablier:
sablierUrl: http://sablier:10000
sessionDuration: 30m
names: stirling-pdf
dynamic:
displayName: Stirling PDF
refreshFrequency: 5s
showDetails: true
theme: hacker-terminal
routers:
stirling-router:
rule: "Host(`pdf.exemplo.local`)"
service: stirling-service
middlewares:
- stirling-sablier@file
services:
stirling-service:
loadBalancer:
servers:
- url: http://stirling-pdf:8080
Cenário 2: Caddy
Para quem usa Caddy, a integração é igualmente limpa. Precisas de compilar o Caddy com o módulo do Sablier usando xcaddy, mas o resultado é um Caddyfile que se lê como prosa:
pdf.exemplo.local {
route {
sablier {
sablier_url http://sablier:10000
names stirling-pdf
session_duration 30m
strategy dynamic
theme hacker-terminal
}
reverse_proxy stirling-pdf:8080
}
} Quando o primeiro pedido chega, o módulo do Caddy detecta que o workload está desligado, fala com a API do Sablier, e serve uma página de carregamento com refresh automático (configurável, por defeito a cada 5 segundos). Quando o Sablier confirma que o container está saudável através do header X-Sablier-Status: ready, o pedido segue para o upstream normalmente.
Cenário 3: Kubernetes com Helm
Para ambientes Kubernetes, o Sablier tem um Helm chart oficial. O conceito é o mesmo, mas em vez de containers Docker, geres Deployments e StatefulSets:
helm repo add sablier https://sablierapp.github.io/helm-charts
helm install sablier sablier/sablier --set provider.name=kubernetes
O Sablier liga-se à API do Kubernetes e faz scale dos Deployments para 0 réplicas quando inactivos, e de volta para o número desejado quando chega um pedido. Precisas de configurar RBAC para dar ao Sablier permissões de leitura e escrita sobre os Deployments e StatefulSets no namespace em questão.
Cenário 4: Proxmox LXC
E isto é onde a coisa fica ainda mais interessante para quem gere infraestrutura on-premise. O Sablier suporta Proxmox LXC como provider, o que significa que podes gerir containers LXC inteiros da mesma forma que geres containers Docker. Configuras a autenticação via API token do Proxmox, etiquetas os teus LXC com a tag sablier, e o Sablier trata de os ligar e desligar conforme a procura. Para quem corre homelabs com Proxmox (e eu sei que muitos de vocês correm), isto é ouro.
E quem usa Apache httpd?
Sei que alguém ia perguntar isto, por isso vou adiantar-me. O Apache HTTP Server, o velho e bom httpd, não tem plugin nativo do Sablier. Os reverse proxies suportados oficialmente são o Traefik, o Caddy, o Nginx (via WASM), o Envoy, o Istio e o Apache APISIX. E atenção que o Apache APISIX é um produto completamente diferente do Apache httpd clássico. O APISIX é um API gateway moderno, construído sobre o OpenResty, que por acaso partilha o nome “Apache” porque faz parte da mesma fundação. Mas não tem nada a ver com o httpd que tens a servir os teus vhosts há 15 anos.
Dito isto, não estás sem opções. O Sablier é, no fundo, uma API HTTP simples. Qualquer coisa que consiga fazer um pedido HTTP antes de encaminhar tráfego para o backend pode funcionar como integração. No Apache httpd, podes usar o mod_lua para interceptar pedidos e chamar a API do Sablier antes de fazer o ProxyPass para o serviço. A lógica seria algo deste género no teu httpd.conf ou num ficheiro de configuração de vhost:
LuaHookAccessChecker /etc/apache2/lua/sablier_wake.lua wake_handler early
<VirtualHost *:80>
ServerName pdf.exemplo.local
ProxyPass / http://stirling-pdf:8080/
ProxyPassReverse / http://stirling-pdf:8080/
</VirtualHost>
E o script Lua faria o pedido à API do Sablier para garantir que o container está de pé antes de deixar o Apache encaminhar o tráfego:
-- /etc/apache2/lua/sablier_wake.lua
function wake_handler(r)
local host = r.hostname
if host == "pdf.exemplo.local" then
local sock = r:socket_connect("sablier", 10000)
-- chamada blocking ao Sablier
r:request("http://sablier:10000/api/strategies/blocking?group=pdf-tools&session_duration=30m")
end
return apache2.DECLINED
end
Funciona? Funciona. É elegante? Meh… Depende do que consideram elegante. Lá over-engineered é. O mod_lua não foi pensado para este tipo de orquestração, e estás a adicionar latência e complexidade num sítio que não foi desenhado para isso. Se fores por esta via, testa bem os timeouts e os cenários de falha, porque se o Sablier não responder a tempo, o Apache vai tentar fazer ProxyPass para um container que ainda não está de pé e o utilizador apanha um 502 ou um 503.
A minha recomendação honesta, se estás preso ao Apache por razões de legado, é esta: mete um Traefik ou um Caddy à frente apenas dos serviços que queres gerir com o Sablier, e mantém o Apache para tudo o resto. Podes até pôr o Apache a fazer ProxyPass para o Traefik nesses vhosts específicos, e deixar o Traefik tratar da integração com o Sablier de forma nativa. É mais uma peça no stack, sim, mas é uma peça que funciona como deve ser em vez de uma gambiarra em Lua que vais odiar daqui a seis meses quando te esquecer-se de como funciona.
Como eu uso isto para baixar a conta do hardware.
Certo, vamos à parte pessoal, que é onde este tipo de artigo ganha vida. Eu e clientes meus correm vários serviços em infraestrutura própria. Alguns deles são críticos e precisam de estar ligados 24/7: DNS, reverse proxy, monitorização, bases de dados de produção. Mas a maioria não é assim. Existem ferramentas de produtividade, ambientes de teste, serviços de conversão de documentos, interfaces de gestão, dashboards que só consulto de vez em quando.
Antes do Sablier, tudo isto estava ligado o tempo todo. A minha utilização média de RAM mesmo o KSM andava nos 85%, e o CPU em idle rondava os 15-20% por causa de todos aqueles processos a correrem para ninguém. Estávamos a falar de 20 e tal containers, a maioria dos quais tocados uma ou duas vezes por semana no máximo.
Depois de introduzir o Sablier, identifiquei os serviços que não precisavam de estar always-on e etiquetei-os. O resultado foi imediato: a utilização média de RAM caiu para perto dos 45%, e o CPU em idle desceu para valores residuais. Libertei recursos que pude redirecionar para coisas que realmente precisavam deles, como o meu motor de inferência local que corria apertado em VRAM e que agora respira melhor porque o sistema em volta não está a sufocar.
E aqui está o ponto chave que quero que fique claro: o Sablier não te faz perder funcionalidade. Os serviços continuam acessíveis exactamente da mesma forma. Alguém acede ao URL, espera três ou quatro segundos na primeira vez (dependendo do peso do container), e a partir daí está tudo normal. Ninguém nota a diferença no dia a dia, mas o hardware nota muito. E a conta da electricidade também.
Para quem está em cloud, a matemática é ainda mais directa. Se pagas por instância ou por recurso alocado, e tens serviços que só são usados em horário laboral ou esporadicamente, o Sablier permite-te desligar esses recursos fora das horas de utilização sem qualquer intervenção manual. Não precisas de cron jobs. Não precisas de scripts. O reverse proxy trata de tudo. O pedido chega, o serviço sobe. A inactividade passa, o serviço desce.
E funciona igualmente bem para cenários de staging e QA. Quantos ambientes de teste tens que só são usados durante sprints de duas semanas, ficam parados durante outra semana, e continuam a consumir recursos? Com o Sablier, esses ambientes dormem quando ninguém os usa e acordam automaticamente quando a equipa precisa deles. A poupança acumula-se depressa.
O Scale Mode: a cereja no topo do gelado para serviços que não podem ter cold start
Agora, há serviços que por natureza não se dão bem com cold starts. Pode ser porque demoram muito a arrancar, pode ser porque precisam de manter estado em memória, pode ser porque o tempo de resposta no primeiro pedido é inaceitável para o caso de uso. Para estes cenários, o Sablier tem uma funcionalidade que eu considero genial: o Scale Mode.
Em vez de parar o container completamente, o Scale Mode faz throttle dos recursos. Reduz o CPU e a memória alocados ao container para um mínimo residual quando não há actividade, e restaura os recursos originais no instante em que um novo pedido chega. O container nunca pára. Nunca tens cold start. Mas nos períodos de inactividade, está a consumir uma fracção dos recursos que consumiria normalmente.
A configuração é feita via labels no container:
services:
minha-app:
image: minha-app:latest
labels:
- "sablier.enable=true"
- "sablier.group=app-critica"
- "sablier.idle.replicas=1"
- "sablier.idle.cpu=0.1"
- "sablier.idle.memory=64m"
- "sablier.active.replicas=1"
- "sablier.active.cpu=2.0"
- "sablier.active.memory=2048m"
Lê isto com atenção. No estado idle, este container fica com 0.1 de CPU e 64MB de memória. No estado activo, salta para 2 cores e 2GB. É a diferença entre pagar para manter uma luzinha acesa e pagar para manter o forno ligado. O container está lá, vivo, com o seu estado intacto, mas a consumir quase nada. E no instante em que o Sablier detecta um pedido, restaura os recursos completos e o serviço responde como se nunca tivesse estado em modo de poupança.
Isto é particularmente poderoso em cenários onde tens hardware limitado, como um Raspberry Pi ou um mini PC, e queres correr mais serviços do que o hardware teoricamente permite. Com o Scale Mode, o hardware só precisa de aguentar os serviços que estão activamente a ser usados num dado momento, mais um consumo residual dos restantes. Na prática, multiplicas a capacidade efectiva do teu hardware.
Hot activate: como dar redundância a serviços usando o Sablier
E agora chegamos a um tema que pouco se fala em relação Sablier, mas que eu achei ser dos mais valiosos: usar o Scale Mode e os grupos para criar uma espécie de redundância hot standby de baixo custo.
O conceito é simples. Imagina que tens um serviço crítico que não pode ficar em baixo. A abordagem tradicional é ter duas instâncias a correr em paralelo, com load balancing entre elas. Funciona, mas custa o dobro de recursos. Se cada instância precisa de 2GB de RAM e 1 core, estás a alocar 4GB e 2 cores permanentemente, mesmo que a carga real só precise de uma instância 99% do tempo.
Com o Sablier e o Scale Mode, podes ter a instância primária a correr com recursos normais e a instância secundária em Scale Mode, com recursos mínimos. A instância secundária está viva, com o estado carregado, pronta para responder. Mas está a consumir 64MB de RAM e 0.1 de CPU em vez dos 2GB e 1 core completo.
Se configurares o teu load balancer para enviar tráfego para ambas as instâncias quando a primária está sobrecarregada ou indisponível, o Sablier escala a secundária para recursos completos no momento em que o primeiro pedido chega. Não há cold start porque o container nunca parou. Não há perda de estado porque a memória do processo foi mantida. É, na prática, um failover quase instantâneo com uma fracção do custo de recursos de um setup activo-activo tradicional.
A mesma lógica pode ser estendida para lidar com picos de carga. Em vez de dimensionares a tua infraestrutura para o pico (e pagares para o vale), dimensionas para a média e usas instâncias em Scale Mode como capacidade de burst. Quando o tráfego sobe, o Sablier escala as instâncias adicionais. Quando o tráfego desce, elas voltam ao estado idle. É elasticidade sem orquestrador complexo, sem auto-scaler caro, sem dependência de um cloud provider. Funciona no teu datacenter, no teu homelab, no teu Raspberry Pi.
Podes ainda combinar isto com os webhooks do Sablier. Cada vez que uma instância arranca ou pára, o Sablier pode enviar uma notificação HTTP normalizada para qualquer endpoint. Isto significa que podes integrar com o teu sistema de alertas, com o teu Grafana, com o teu Home Assistant, com o que quiseres. Sabes em tempo real o que está a acontecer com cada instância e podes reagir em conformidade.
Monitorização: não confies, mede
Lá porque o Sablier é simples não quer dizer que devas confiar cegamente. Uma das coisas que mais gosto neste projecto é que foi desenhado a pensar em observabilidade desde o início.
O Sablier expõe um endpoint /metrics compatível com Prometheus. Podes raspar essas métricas e alimentar dashboards no Grafana para veres em tempo real quantos containers estão activos, quantos estão dormentes, quantas sessões estão a decorrer, e quais os tempos de arranque. Se tiveres um Grafana a correr (e devias ter), isto é configuração de cinco minutos.
Além disso, o Sablier suporta distributed tracing via OpenTelemetry. Cada pedido HTTP e cada chamada ao provider de containers é capturada como um span e exportada para backends como Jaeger ou Grafana Tempo. Se o teu reverse proxy injectar um header traceparent (e o Traefik faz isto nativamente), o Sablier junta-se ao trace existente. Ou seja, tens visibilidade completa do percurso de um pedido desde o reverse proxy, passando pelo Sablier, até ao container final.
Isto é particularmente útil para diagnosticar problemas de cold start. Se um container está a demorar demasiado a arrancar, vês exactamente onde o tempo está a ser gasto: no arranque do container, no healthcheck, na propagação do pedido. Resolves o problema com dados, não com palpites.
Os cuidados a ter
Seria desonesto da minha parte escrever um post inteiro a elogiar uma ferramenta sem falar do que pode correr mal, por isso vamos lá.
Primeiro: o Sablier precisa de acesso ao Docker socket (ou à API do Kubernetes, ou à API do Proxmox). Isto significa que tem permissões privilegiadas sobre a tua infraestrutura. Trata-o como tratarias qualquer componente com acesso root. Isola-o na rede, limita o acesso, e não o exponhas para fora.
Segundo: os cold starts são reais. Para containers leves que arrancam em dois ou três segundos, o utilizador quase não nota. Para containers pesados que demoram 30 segundos ou mais a ficarem saudáveis, a experiência do primeiro pedido pode ser frustrante. Nestes casos, considera usar o Scale Mode em vez do stop completo, ou ajusta os healthchecks para serem mais rápidos.
Terceiro: sem healthchecks, o Sablier não consegue distinguir um container que está a arrancar de um container que já está pronto para receber pedidos. Isto significa que pode entregar o tráfego cedo demais e o utilizador apanhar um erro. Usa sempre healthchecks nos teus containers. Isto é boa prática com ou sem Sablier, mas com o Sablier é obrigatório.
Quarto: o Docker Swarm tem uma limitação conhecida. Quando um serviço é escalado para zero réplicas, o Traefik perde acesso às labels desse serviço. Isto significa que a configuração dos middlewares tem de ser centralizada num serviço que esteja sempre a correr (tipicamente o próprio Sablier), em vez de estar nas labels do serviço que queres gerir. Não é um bloqueio, é uma complicação que precisas de conhecer.
E quinto: o Scale Mode, apesar de brilhante, depende dos cgroups do container runtime para impor os limites de recursos. Se o teu container runtime ou o teu kernel não suporta actualizações dinâmicas de limites, o Scale Mode não vai funcionar como esperado. Em Docker recente com kernels modernos, isto não é problema. Mas se estiveres num sistema mais antigo, testa antes de confiar.
Porque é que isto encaixa na filosofia deste blog
Se andas por aqui há algum tempo, já percebeste a tese. A cloud promete elasticidade mas cobra rigidez. O on-premise dá controlo mas exige disciplina. E a disciplina que a maioria de nós não tem é a de desligar o que não está a ser usado.
O Sablier resolve exactamente isto: automatiza a disciplina. Não te pede que mudes a tua arquitectura, não te obriga a reescrever os teus serviços, não te empurra para uma plataforma proprietária. É uma peça que se mete entre o teu reverse proxy e os teus containers e faz o que tu farias se tivesses tempo e paciência para andar a ligar e desligar coisas manualmente. Mas sem a parte de teres de te lembrar.
É open source, corre localmente, suporta os providers e proxies que a maioria de nós já usa, e tem métricas e tracing para quem gosta de ver números (eu). É o tipo de ferramenta que descubro, meto no stack, e depois pergunto-me como é que vivia sem ela.
A independência tecnológica não se constrói só com o software que escolhes. Constrói-se também com a eficiência com que usas o hardware que tens. E se conseguires correr o dobro dos serviços na mesma máquina sem sacrificar a experiência do utilizador, acabaste de duplicar o valor do teu investimento em hardware sem gastar um cêntimo a mais.
Espero que tenham gostado do post. Se já usam o Sablier, especialmente com Scale Mode em cenários de redundância ou burst, mandem-me os vossos números. Esse é o tipo de dado que a documentação oficial ainda não tem muitos, e é onde acho que está o ouro por explorar. Se alguém tiver benchmarks reais de poupança de recursos em homelabs, faço continuação com dados de campo.
Abraço! Nuno
Links úteis:
- Sablier no GitHub: https://github.com/sablierapp/sablier
- Documentação oficial: https://sablierapp.dev
- Sablier no Docker Hub: https://hub.docker.com/r/sablierapp/sablier
- Plugin Traefik: https://plugins.traefik.io/plugins/633b4658a4caa9ddeffda119/sablier
- Helm Charts: https://github.com/sablierapp/helm-charts
- Exemplo Docker + Traefik + Sablier: https://github.com/davull/demo-docker-traefik-sablier