docker-compose.prod.yml
Rama main · réplica de lectura del repositorio original.
# DeskcommCRM — stack de produção self-host (VPS HostGator).
# Sobe: caddy (HTTPS) → app (Next standalone) + waha + redis+srh + scheduler.
# Só o Caddy publica portas (80/443). Todo o resto vive na rede interna.
#
# docker compose -f docker-compose.prod.yml --env-file .env up -d
x-logging: &default-logging
driver: json-file
options:
max-size: "10m" # rotação: evita que o log encha o disco do VPS
max-file: "3"
services:
app:
# Teto de memória — 335 MiB de pico MEDIDO nesta VPS.
#
# Sem ele o contêiner é ilimitado, e numa VPS de 3,8 GB isso não é teoria:
# um contêiner ALHEIO (agente da hospedagem, fora deste compose) registrou
# pico de 3.068 MiB no mesmo host. Quando a RAM acaba, o OOM killer escolhe
# a vítima por PONTUAÇÃO — quem cresceu mais rápido —, não por importância:
# o que morre pode ser o CRM.
#
# O teto não impede o pico legítimo; impede que UM serviço leve a máquina
# inteira. Estourá-lo mata só quem estourou, e o `restart: unless-stopped`
# o traz de volta — falha isolada em vez de queda geral.
# O teto vem do `.env` (APP_MEM_LIMIT), e sem a chave fica o de sempre. Numa
# VPS maior, suba-o lá — nunca aqui: este arquivo é do clone, e uma edição à
# mão faz o `git checkout` do update.sh recusar a versão nova que também o
# mudou.
mem_limit: ${APP_MEM_LIMIT:-768m}
# Imagem GENÉRICA pré-buildada: o leigo só puxa (sobe em ~2min, roda em 2GB).
# Os NEXT_PUBLIC_* reais vêm em RUNTIME (env_file abaixo) — o browser lê via
# <PublicEnvScript/> e o servidor via lib/env.ts. Não precisa buildar no VPS.
# Build local (avançado): docker compose -f docker-compose.prod.yml -f docker-compose.build.yml build
# `:stable` (última release), não `:latest` (topo da `main`). Quem cai neste
# default é quem NÃO tem APP_IMAGE no .env — avaliação, ou um .env que
# perdeu a chave. Nenhum desses casos quer código não lançado; quem quiser o
# topo da main pede `APP_IMAGE=…:latest` explicitamente.
image: ${APP_IMAGE:-ghcr.io/melgarafael/deskcommcrm:stable}
pull_policy: ${APP_PULL_POLICY:-always}
# SEM `build:` AO LADO, de propósito — e é assim que o portão do update.sh
# é consultado. Medido no Compose: com `image:` + `build:` no mesmo bloco,
# o `up -d` CONSTRÓI em QUALQUER falha de pull (tag inexistente, registro
# fora por DNS, "no matching manifest"), seja o `pull_policy` `always`,
# `missing` ou sem a chave. Aqui isso seria o pior desfecho possível: o app é
# o único build pesado da stack, e o portão `build_local_permitido` (#1955)
# — que RECUSA construir quando o registro não responde, depois do apagão de
# DNS que virou OOM no `next-build` e o CRM em 502 — só é consultado quando
# o `up -d` FALHA. Sem `build:` aqui, a falta da imagem do app é o que faz o
# `up -d` falhar e entrega a decisão ao portão; quem o Compose constrói
# sozinho é worker, scheduler e voice-agent, cujo build é barato (pnpm
# install e apk add) — o escape deles continua.
#
# Quem QUER construir o app usa o docker-compose.build.yml
# (`docker compose -f docker-compose.prod.yml -f docker-compose.build.yml
# build`), que passa `APP_VERSION` como argumento — por este `build:` o app
# sairia com o `APP_VERSION=dev` que está no Dockerfile.
#
# `image:` continua obrigatório (invariante 1 da doutrina de packaging):
# um serviço build-only é pulado pelo pull e NUNCA é atualizado. Aqui a
# imagem continua vindo do registro.
restart: unless-stopped
env_file: .env
environment:
SUPABASE_DB_ADMIN_URL: ""
# O `worker` deste arquivo drena o event_log em poucos segundos (2 s com
# fila, até 10 s parado); o webhook de mensagem não precisa mais drenar a
# fila de todas as organizações dentro da requisição
# (lib/dev/kick-local-pipeline.ts).
EVENT_LOG_WORKER_DRAINS: ${EVENT_LOG_WORKER_DRAINS:-true}
depends_on:
srh:
condition: service_started
waha:
condition: service_started
healthcheck:
# Probe TCP puro (node existe na imagem; curl/nc não). NÃO usar /api/v1/health:
# ele dá 503 se WAHA/Redis caem, o que deixaria o app "unhealthy" e derrubaria
# o Caddy junto (blackout total por uma dependência secundária).
test: ["CMD", "node", "-e", "require('net').connect(3000,'127.0.0.1').on('connect',()=>process.exit(0)).on('error',()=>process.exit(1))"]
# A cada 10 s, e não a cada 30 (conserto de @jmpo, PR #3393). Atrás do
# Traefik da hospedagem (Hostinger, Coolify, Dokploy — o
# docker-compose.traefik.yml), o tráfego só vai a contêiner `healthy`; o
# app fica pronto em ~5 s, mas com Docker 24 ou mais antigo a primeira
# checagem só rodava aos 30 s, e a atualização deixava o domínio em
# "404 page not found" por 30–45 s (medido numa instalação real em
# 24/09/2026, quatro deploys no dia).
# Com Docker 25 ou mais novo a janela já era de ~5 s e não muda. O Caddy
# padrão do kit não consulta a saúde para rotear.
# `retries` sobe na mesma proporção: 10 s × 15 = os mesmos 150 s de
# tolerância de antes (30 s × 5) para declarar o app doente.
#
# NÃO trocar por `start_interval` (que pergunta rápido só durante o
# `start_period`): o Compose 2.17 RECUSA o arquivo inteiro com
# "Additional property start_interval is not allowed", e o kit só exige
# "docker compose v2" — o `up -d` de quem tem Compose antigo morreria.
# Medido: 2.17.2 recusa; 2.21.0 e 5.5.1 com motor de API 1.43 (Docker
# 24) aceitam e ignoram calados. Vigiado em
# tests/unit/healthcheck-do-app-libera-o-trafego-cedo.test.ts.
interval: 10s
timeout: 5s
retries: 15
start_period: 40s
logging: *default-logging
networks: [internal]
# Worker 24/7 do agent-engine (fusão Vendaval) — cérebro do agente SDR.
worker:
# Teto de memória — 230 MiB de pico MEDIDO nesta VPS.
#
# Sem ele o contêiner é ilimitado, e numa VPS de 3,8 GB isso não é teoria:
# um contêiner ALHEIO (agente da hospedagem, fora deste compose) registrou
# pico de 3.068 MiB no mesmo host. Quando a RAM acaba, o OOM killer escolhe
# a vítima por PONTUAÇÃO — quem cresceu mais rápido —, não por importância:
# o que morre pode ser o CRM.
#
# O teto não impede o pico legítimo; impede que UM serviço leve a máquina
# inteira. Estourá-lo mata só quem estourou, e o `restart: unless-stopped`
# o traz de volta — falha isolada em vez de queda geral.
# O teto vem do `.env` (WORKER_MEM_LIMIT), e sem a chave fica o de sempre. Numa
# VPS maior, suba-o lá — nunca aqui: este arquivo é do clone, e uma edição à
# mão faz o `git checkout` do update.sh recusar a versão nova que também o
# mudou.
mem_limit: ${WORKER_MEM_LIMIT:-512m}
# Imagem publicada — e não mais `build:` sozinho. O motivo é o modo de falha
# que isso escondia: serviço build-only é PULADO por `docker compose pull`
# ("Skipped - No image to be pulled") e imune a `up -d` sem `--build`. Ele era
# construído na VPS de todo cliente, no install, e NENHUM update.sh jamais o
# reconstruía — o runtime do agente de IA congelava no código do dia da
# instalação e atravessava todas as atualizações seguintes.
#
# O `build:` continua abaixo de propósito: com os dois presentes, o Compose
# usa a imagem quando ela existe e CONSTRÓI quando não existe (medido). É o
# que mantém a mudança aditiva — registry fora do ar, ou versão anterior à
# primeira publicação, caem no comportamento antigo em vez de quebrar.
#
# O default é `:stable` (a última RELEASE), não `:latest`, e a diferença é
# concreta para o parque instalado. Numa VPS que atualiza pela primeira vez
# depois desta mudança, quem executa é o `update.sh` VELHO — o que está no
# disco —, e ele só sabe gravar APP_IMAGE. O `git checkout` da tag já trocou
# ESTE arquivo, então worker e scheduler caem no default daqui. Com
# `:latest`, esse default seria o TOPO DA MAIN (o canal segue a branch
# default): o app pinado numa release e o runtime do agente de
# IA rodando código não lançado, sobre o banco da release. `:stable` é a
# última release publicada — pareia com o app em vez de correr na frente.
image: ${WORKER_IMAGE:-ghcr.io/melgarafael/deskcomm-worker:stable}
pull_policy: ${WORKER_PULL_POLICY:-always}
build:
context: .
dockerfile: Dockerfile.worker
# ═══ O PRAZO QUE FALTAVA (#2823) ═══
#
# No `docker stop` o Docker manda SIGTERM e espera ESTE prazo; passado ele,
# manda SIGKILL. Sem a chave, o prazo é o PADRÃO DE 10 s — e o worker se dá
# 30 s (`SHUTDOWN_GRACE_MS`) para fechar laços + drain + pool. O SIGKILL
# chegava, portanto, na METADE do prazo que o próprio worker pediu, e o job
# em voo voltava `running` até o reaper (10 min de invisibilidade a cada
# `docker stop` — o defeito da issue, medido em 19,6 s de parada ociosa com
# o laço do `event_log` preso numa chamada de rede).
#
# ═══ POR QUE O NÚMERO NÃO RESOLVE A ISSUE SOZINHO ═══
#
# Aumentar o prazo do supervisor é o remédio que a issue #2823 PROÍBE como
# conserto único (o comentário do `Dockerfile.worker` registra isso): com o
# prazo armado depois de esperar os laços, o `stop_grace_period` que faltava
# cobriria uma janela que começava tarde — os 19,6 s do laço preso ficavam
# por fora de qualquer prazo, interno ou externo. O par só funciona junto:
# o worker conta o prazo DO SINAL (`workers/agent-worker/desligamento-no-prazo.ts`)
# e este número é o teto de fora.
#
# ═══ A REGRA DO PAR ═══
#
# `stop_grace_period` > `SHUTDOWN_GRACE_MS`/1000, com folga para o fecho do
# pool e do healthz. O default de 40 s para os 30 s internos dá 10 s de
# folga. Os dois são gravados juntos pelo `install.sh` (kit) e o par que não
# fecha é reprovado por `workers/agent-worker/prazo-do-shutdown-comeca-no-sinal.test.ts`.
stop_grace_period: ${WORKER_STOP_GRACE_PERIOD:-40s}
restart: unless-stopped
env_file: .env
environment:
# dentro da rede do compose, o WAHA é o serviço 'waha' na porta interna 3000
WAHA_API_BASE_URL: http://waha:3000
SUPABASE_DB_ADMIN_URL: ""
networks:
- internal
healthcheck:
test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://127.0.0.1:8787/healthz"]
interval: 30s
timeout: 5s
retries: 3
start_period: 20s
waha:
# Teto de memória — 893 MiB de pico MEDIDO nesta VPS.
#
# Sem ele o contêiner é ilimitado, e numa VPS de 3,8 GB isso não é teoria:
# um contêiner ALHEIO (agente da hospedagem, fora deste compose) registrou
# pico de 3.068 MiB no mesmo host. Quando a RAM acaba, o OOM killer escolhe
# a vítima por PONTUAÇÃO — quem cresceu mais rápido —, não por importância:
# o que morre pode ser o CRM.
#
# O teto não impede o pico legítimo; impede que UM serviço leve a máquina
# inteira. Estourá-lo mata só quem estourou, e o `restart: unless-stopped`
# o traz de volta — falha isolada em vez de queda geral.
# O teto vem do `.env` (WAHA_MEM_LIMIT), e sem a chave fica o de sempre. Numa
# VPS maior, suba-o lá — nunca aqui: este arquivo é do clone, e uma edição à
# mão faz o `git checkout` do update.sh recusar a versão nova que também o
# mudou.
mem_limit: ${WAHA_MEM_LIMIT:-1280m}
# Core grátis por padrão; troque para devlikeapro/waha-plus via WAHA_IMAGE se
# precisar de multi-número/retry/S3 (licença paga).
#
# Tag PINADA: `devlikeapro/waha` sem tag é `:latest`, e o `dc pull` do
# update.sh entregaria ao cliente qualquer versão que o upstream tivesse
# publicado. O instalador grava `latest-2026.7.2` em x86 e
# `noweb-arm-2026.7.2` em ARM64; as duas tags fixam a versão NOWEB.
# Bumpar faz parte do release.
image: ${WAHA_IMAGE:-devlikeapro/waha:latest-2026.7.2}
restart: unless-stopped
environment:
# Prefixo sha512: faz o WAHA HASHEAR o X-Api-Key recebido e comparar com este
# hash. Sem o prefixo ele compara literal → o app (que manda o plaintext) toma 401.
WAHA_API_KEY: "sha512:${WAHA_API_KEY_SHA512}"
# Fixo na rede interna, como o WAHA_API_BASE_URL do worker: o WAHA desta
# stack mora ao lado do `app`, e a rota global só atende a rede interna
# (app/api/v1/webhooks/waha/route.ts). Lido do .env, um endereço público
# ali faria a entrega parar sem nenhum arquivo ter mudado.
WHATSAPP_HOOK_URL: http://app:3000/api/v1/webhooks/waha
# `message` NÃO entra, e `message.any` sozinho não perde nada — medido.
#
# O WAHA emite os DOIS para a mesma mensagem, e `lib/waha/ingest.ts` já
# chama isso de corrida e deduplica. Só que o arquivo do corpo cru guarda
# as duas cópias: numa instalação real, 22.939 linhas de `message` ao lado
# de 24.582 de `message.any` — 41% da tabela que era 86% do banco.
#
# A prova de que dá para tirar veio do banco, não da doc: cruzando os ids
# de mensagem dos dois eventos em 22.815 mensagens reais, os que chegaram
# SÓ por `message` foram ZERO, e 1.642 chegaram só por `message.any` (os
# que saíram de nós, que `message` não cobre). Superconjunto estrito.
# `message.reaction` entra: é por onde chega o 👍/😐 do cliente (#2797).
# O WAHA trata reação como evento PRÓPRIO — sem assiná-lo, um gesto que o
# CRM recebe pela API oficial nunca chegaria pelo canal por QR. `message.any`
# NÃO o cobre (a reação não vem como mensagem).
WHATSAPP_HOOK_EVENTS: "message.any,message.ack,message.edited,message.revoked,message.reaction,session.status,state.change"
# Nome EXATO da doc do WAHA (events#hmac-authentication): WHATSAPP_HOOK_HMAC
# não existe nele — sem o _KEY ele ignora e nunca assina.
WHATSAPP_HOOK_HMAC_KEY: ${WAHA_HMAC_SECRET}
# WAHA lê WHATSAPP_DEFAULT_ENGINE (NÃO WAHA_DEFAULT_ENGINE — o nome errado
# fazia cair no default WEBJS, engine com browser que trava/corrompe a sessão
# quando o WhatsApp Web atualiza; NOWEB é websocket direto, estável e leve).
WHATSAPP_DEFAULT_ENGINE: ${WHATSAPP_DEFAULT_ENGINE:-NOWEB}
WAHA_DASHBOARD_ENABLED: "false" # nunca expor o dashboard num template público
# Sem isto o container volta e as sessões ficam STOPPED: o número continua
# pareado em /app/.sessions, mas nada entra nem sai até alguém clicar
# Reconectar. True retoma as que já existiam — não reloga, não pede QR.
# Default do WAHA é False.
WHATSAPP_RESTART_ALL_SESSIONS: "${WHATSAPP_RESTART_ALL_SESSIONS:-True}"
volumes:
- waha-data:/app/.sessions # sessões pareadas (QR) — perder = re-parear
- waha-media:/app/.media
logging: *default-logging
networks: [internal]
redis:
image: redis:7-alpine
restart: unless-stopped
command: ["redis-server", "--save", "", "--appendonly", "no"] # efêmero (rate-limit/debounce)
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 30s
timeout: 3s
retries: 3
logging: *default-logging
networks: [internal]
srh:
# serverless-redis-http: fala o REST do Upstash sobre o redis normal, mantendo
# o SDK @upstash/redis sem tocar código.
#
# Pinado por DIGEST, não por tag, e o motivo é específico: `latest` e `0.0.10`
# NÃO são a mesma imagem (5b0bb923… vs 65128347…), então trocar `:latest` por
# `:0.0.10` mudaria o binário que roda no parque — que é exatamente o risco
# que a pendência T6 mandava validar antes (encoding base64 do rate limit).
# O digest congela o que já está em produção HOJE: zero mudança de conteúdo,
# e o `:latest` deixa de poder mudar sozinho debaixo de todo mundo.
# Quando a T6 for validada, isto vira `:0.0.10` e o comentário sai.
image: hiett/serverless-redis-http@sha256:5b0bb9239fce53abf87b2018a7a0deb9ec7bd900c5360738fe5fbeeb426f9150
restart: unless-stopped
environment:
SRH_MODE: env
SRH_TOKEN: ${SRH_TOKEN}
SRH_CONNECTION_STRING: "redis://redis:6379"
depends_on:
redis:
condition: service_healthy
logging: *default-logging
networks: [internal]
scheduler:
# Cron sem docker.sock: crond interno batendo curl na rede interna.
# Resolução de 1 min — o menor passo que o crond tem, e o piso de latência
# de tudo que depende de cron (a lista tem rotas de minuto em minuto).
#
# A lista de crons mora em docker/scheduler/entrypoint.sh, não mais aqui. O
# `command:` inline instalava curl e tzdata (`apk add`) a CADA start — num
# serviço `restart: unless-stopped`, isso significa que o cron do cliente só
# voltava se a VPS tivesse internet e o mirror do Alpine estivesse de pé,
# justamente no momento em que a máquina está se recuperando de algo.
image: ${SCHEDULER_IMAGE:-ghcr.io/melgarafael/deskcomm-scheduler:stable}
pull_policy: ${SCHEDULER_PULL_POLICY:-always}
build:
context: .
dockerfile: Dockerfile.scheduler
restart: unless-stopped
depends_on:
app:
condition: service_healthy
environment:
TZ: UTC
INTERNAL_SECRET: ${INTERNAL_SECRET}
logging: *default-logging
networks: [internal]
# ── Chamada de voz WhatsApp (spec 18) — DESLIGADA POR PADRÃO ──────────────
#
# ═══ POR QUE ELA VIVE NUM PROFILE ═══
#
# A chamada de voz vincula um SEGUNDO APARELHO ao mesmo número que já atende,
# por um caminho que não é o oficial: o risco é a CONTA ser bloqueada. Serviço
# que sobe em toda instalação transforma esse risco em padrão — e um contêiner
# a mais custa RAM numa VPS onde o WAHA já registrou 893 MiB de pico.
#
# `profiles:` é o mesmo mecanismo com que `docker-compose.traefik.yml` desliga
# o Caddy: sem o profile ativo, o compose NÃO cria o contêiner. Ligar é uma
# linha no .env — `COMPOSE_PROFILES=voz` — e nada mais.
#
# ⚠️ DUAS ARMADILHAS MEDIDAS, as duas do próprio Compose:
#
# 1. Nomear o serviço explicitamente (`docker compose up -d wacalls`) ATIVA
# o profile e sobe o contêiner mesmo com COMPOSE_PROFILES vazio. É por
# isso que o update.sh checa antes de recriar o caddy, e vale igual aqui.
# 2. `app` e `worker` NÃO podem ganhar `depends_on: wacalls`. Dependência
# em serviço de profile inativo não sobe — o CRM inteiro deixaria de
# subir em toda instalação que não usa a feature.
#
# ═══ POR QUE A IMAGEM É DO UPSTREAM, PINADA POR DIGEST ═══
#
# WaCalls (github.com/JotaDev66/WaCalls, MIT) é peça UPSTREAM, e a doutrina
# (docs/doctrine/packaging.md) é explícita: peça upstream se REFERENCIA, nunca
# se republica — "a regra vale para todas, não só a licenciada, porque a
# exceção é o que apaga a regra". Construir e publicar `deskcomm-wacalls`
# seria republicar.
#
# O digest é o pin mais forte que existe e o único disponível aqui: `:latest`
# e `:latest-pure` NÃO existem neste registry (404 medido em 2026-09-08); as
# tags publicadas são `develop` e `sha-*`. Ele resolve para
# `sha-d16a076`/`develop`, index OCI multi-arch (linux/amd64 + linux/arm64).
#
# `pull_policy: missing` porque o digest é imutável: com `always`, um GHCR
# fora do ar impediria o contêiner de subir mesmo com a imagem já no disco.
#
# ═══ SEM `ports:` — E ISSO É VIGIADO ═══
#
# A API do WaCalls fica só na rede interna, alcançável pelo app e pelo worker.
# `tests/unit/portas-do-compose.test.ts` reprova quem publicar porta aqui.
wacalls:
profiles: ["voz"]
mem_limit: 256m
image: ${WACALLS_IMAGE:-ghcr.io/jotadev66/wacalls@sha256:9ff52ef9455cf42125a911c38bb8c855f0cc205516cada2054e5c05546909022}
pull_policy: ${WACALLS_PULL_POLICY:-missing}
restart: unless-stopped
environment:
# O serviço NÃO SOBE sem estes dois — é o upstream que exige, e é o que
# substitui o build anterior, cujo README dizia "the API has no
# authentication ... run it only on a trusted LAN".
WACALLS_ADMIN_USER: ${WACALLS_ADMIN_USER:-}
WACALLS_ADMIN_PASSWORD: ${WACALLS_ADMIN_PASSWORD:-}
# Bearer da automação. Sem ele a API só aceita o cookie de login, que um
# processo server-to-server não tem: o app não conseguiria falar nada.
WACALLS_API_TOKEN: ${WACALLS_API_TOKEN:-}
# Vazio = same-origin. Nossa UI não fala com o WaCalls direto do browser —
# tudo passa pelas rotas /api/v1/voice/*, então não há origem a liberar.
WACALLS_CORS_ORIGINS: ${WACALLS_CORS_ORIGINS:-}
WACALLS_TRUSTED_PROXIES: ${WACALLS_TRUSTED_PROXIES:-}
WACALLS_PUBLIC_IP: ${WACALLS_PUBLIC_IP:-}
# A porta que o áudio usa, e ela precisa ser FIXA. Sem esta variável o
# upstream não monta o mux de UDP e cai em portas efêmeras aleatórias —
# impossíveis de publicar aqui, e o áudio nunca sai da máquina.
WACALLS_WEBRTC_UDP_PORT: ${WACALLS_WEBRTC_UDP_PORT:-7881}
ports:
# A ÚNICA porta publicada por um serviço nosso que não é o proxy, e ela é
# UDP. Não é exceção sem razão: o áudio do WebRTC não fala HTTP, então não
# há proxy que o carregue — o Caddy é L7 e não repassa UDP.
#
# host == contêiner de PROPÓSITO. O número entra no candidato SDP que o
# navegador recebe; um remap (7881:7882) faria o navegador mandar mídia
# para uma porta que o host não escuta, e a ligação ficaria muda com tudo
# "certo" nos logs.
#
# NUNCA TCP: a API HTTP do serviço continua só na rede interna, alcançável
# apenas pelo app e pelo worker. Publicar TCP aqui exporia a interface de
# administração dele à internet.
- "${WACALLS_WEBRTC_UDP_PORT:-7881}:${WACALLS_WEBRTC_UDP_PORT:-7881}/udp"
volumes:
# wacalls.db guarda a credencial de sessão do WhatsApp — mesmo padrão do
# waha-data. Apagar o volume desvincula todos os aparelhos.
- wacalls-data:/data
logging: *default-logging
networks: [internal]
# ═══ TELEFONIA POR SIP (#677) — MÓDULO OPCIONAL, DESLIGADO POR PADRÃO ═══
#
# Decisão do dono (doc 27 da triagem): a telefonia por SIP entra como módulo
# opcional do compose, no molde do `wacalls`. Os dois serviços abaixo só
# existem com `telefonia` em COMPOSE_PROFILES no .env — sem isso o compose
# nem os cria, e nenhuma instalação que não pediu ganha porta aberta,
# contêiner ou consumo de memória.
#
# As mesmas duas regras do `wacalls` valem aqui: nomear o serviço no
# `up -d` ATIVA o profile; e `app`/`worker` não podem ganhar `depends_on`
# nestes serviços (dependência de profile inativo derruba o CRM inteiro).
#
# Para ligar: copiar asterisk/pjsip.conf.example e asterisk/ari.conf.example
# para os nomes sem `.example` (com as credenciais do tronco e do ARI),
# pôr `telefonia` em COMPOSE_PROFILES e subir.
#
# ═══ POR QUE O ASTERISK É PINADO POR DIGEST ═══
#
# Asterisk é peça UPSTREAM — se referencia, nunca se republica
# (docs/doctrine/packaging.md). E neste registry nenhuma tag é imutável: a
# `20-alpine` e até as tags de versão (`20.20.1-alpine`) são reconstruídas
# a cada build do mantenedor (medido em 18/09/2026: a mesma `20.20.1` com
# digests diferentes em 19/08, 26/08, 02/09, 09/09 e 16/09). O digest abaixo
# é o da `20-alpine` = `20.20.1_alpine-3.24-e9d725f` (16/09), multi-arch
# (amd64 + arm64). `pull_policy: missing` porque o digest é imutável.
asterisk:
profiles: ["telefonia"]
mem_limit: 256m
image: ${ASTERISK_IMAGE:-andrius/asterisk@sha256:927d4c98777149c3380c4f8d0e82b1b1ba9e7b38528f86c1e1593d5a25032f27}
pull_policy: ${ASTERISK_PULL_POLICY:-missing}
restart: unless-stopped
ports:
# Só UDP, e pelo mesmo motivo do `wacalls`: sinalização SIP e mídia RTP
# não falam HTTP, não há proxy L7 que as carregue, e o tronco do
# provedor precisa alcançá-las de fora.
#
# NUNCA TCP: a ARI (REST + WebSocket, 8088) é o controle total das
# chamadas e fica só na rede interna, alcançável apenas pelo
# `voice-agent`. Publicá-la entregaria à internet quem liga para quem.
- "5060:5060/udp"
# Faixa de RTP casada com asterisk/rtp.conf — mudar uma sem a outra deixa
# a ligação muda com tudo "conectado" nos logs.
- "10000-10200:10000-10200/udp"
volumes:
- ./asterisk/pjsip.conf:/etc/asterisk/pjsip.conf:ro
- ./asterisk/extensions.conf:/etc/asterisk/extensions.conf:ro
- ./asterisk/ari.conf:/etc/asterisk/ari.conf:ro
- ./asterisk/http.conf:/etc/asterisk/http.conf:ro
- ./asterisk/rtp.conf:/etc/asterisk/rtp.conf:ro
- asterisk-data:/var/lib/asterisk
- asterisk-logs:/var/log/asterisk
healthcheck:
test: ["CMD", "asterisk", "-rx", "core show uptime"]
interval: 15s
timeout: 5s
retries: 5
logging: *default-logging
networks: [internal]
# O runtime de voz é NOSSO: imagem publicada pelo CI (publish-image.yml),
# nunca build-only (doutrina de packaging, invariante 1). `build:` fica ao
# lado só como escape.
voice-agent:
profiles: ["telefonia"]
mem_limit: 512m
image: ${VOICE_AGENT_IMAGE:-ghcr.io/melgarafael/deskcomm-voice-agent:stable}
pull_policy: ${VOICE_AGENT_PULL_POLICY:-always}
build:
context: .
dockerfile: Dockerfile.voice-agent
restart: unless-stopped
depends_on:
asterisk:
condition: service_healthy
# env_file completo, como o `worker`: lib/env.ts valida todas as variáveis
# da aplicação no import, não só as de voz.
env_file: .env
environment:
ARI_URL: "http://asterisk:8088"
ARI_WS_URL: "ws://asterisk:8088/ari/events"
ARI_APP: "voice-agent"
# Como no app e no worker: a conexão do dono do banco fica no .env só
# para o kit no host (update.sh do cron); nenhum código de workers/ a lê.
SUPABASE_DB_ADMIN_URL: ""
logging: *default-logging
networks: [internal]
caddy:
image: caddy:2-alpine
restart: unless-stopped
ports:
- "80:80"
- "443:443"
environment:
DOMAIN: ${DOMAIN}
ACME_EMAIL: ${ACME_EMAIL}
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
# Ponto de extensão (#2724): arquivos .caddy soltos nesta pasta local são
# importados pelo fim do Caddyfile, e a pasta não é versionada — publicar
# outro serviço no mesmo VPS não mexe em arquivo nenhum do repositório,
# então nada trava o update.sh. Somente-leitura: o contêiner não escreve
# em configuração que o operador mantém no host.
- ./caddy-sites:/etc/caddy/sites:ro
- caddy-data:/data # certificados Let's Encrypt (persistir!)
- caddy-config:/config
depends_on:
app:
condition: service_healthy
logging: *default-logging
# `caddy-sites` (#2724): rede só entre o Caddy e os serviços extras que o
# operador publica por caddy-sites/. O serviço de terceiro entra nela, e
# não na `internal`, para não alcançar os serviços internos do CRM.
networks: [internal, caddy-sites]
volumes:
waha-data:
waha-media:
wacalls-data:
asterisk-data:
asterisk-logs:
caddy-data:
caddy-config:
networks:
internal:
driver: bridge
caddy-sites:
driver: bridge