Redis

O Studio usa o Redis como barramento de mensagens e cache compartilhado. Os dois deployments já o incluem por padrão — o Docker Compose como um serviço redis, o Helm como um Deployment redis — então esta página trata principalmente de quando substituir a instância embutida por uma gerenciada, e do que deixa de funcionar se o Redis não existir.

O que ele sustenta

Uso	Sem o Redis
Pub/sub — status ao vivo de tarefas do Chat, eventos de tabela, cancelamento de execução, notificações de mudança de ferramentas MCP, confirmações de ferramentas do Studio	Cai para um emissor local ao processo: os eventos nunca saem do pod que os produziu
Adaptador do Socket.IO (realtime)	Eventos de colaboração não são entregues entre pods do realtime
Store de idempotência	Cai para o PostgreSQL
Marcadores de progresso de execução	Cai para o PostgreSQL
Limites distribuídos de execução	Aplicados por pod, e não por deployment
Store de aprovação de autenticação da CLI	Sem fallback — a autenticação da CLI exige Redis, independentemente do número de réplicas
Store de documentos colaborativos (realtime)	Cai para estado em memória do processo

Com mais de uma réplica de app ou de realtime e sem REDIS_URL, as pessoas em pods diferentes param de ver as edições e as atualizações de status umas das outras. Fora uma linha de log na inicialização indicando o modo de pod único, nada é registrado — o app parece saudável e perde eventos silenciosamente. Trate o Redis como obrigatório no momento em que replicaCount passar de 1.

Configuração

REDIS_URL=redis://:password@redis-host:6379
# or, with TLS
REDIS_URL=rediss://:password@redis-host:6380

Tanto o app quanto o serviço de realtime precisam dele — eles o usam para coisas diferentes.

O docker-compose.prod.yml já inclui um serviço redis:7-alpine e injeta REDIS_URL=redis://redis:6379 nos contêineres do app e do realtime. Nada a configurar.

A porta deliberadamente não é publicada no host, então um Redis já rodando localmente não vai conflitar. Sobrescreva REDIS_URL no .env para apontar para uma instância externa.

O chart faz o deploy do Redis por padrão, igual à stack do Compose. Nada a configurar.

Em produção, prefira uma instância gerenciada — desative a embutida e forneça uma URL:

redis:
  enabled: false

app:
  env:
    REDIS_URL: "rediss://:<password>@my-cache.internal:6380"

app.env.REDIS_URL assume o controle sempre que estiver definida, e o chart pula o Deployment embutido para você não ficar com um pod perdido.

Se a URL vier de um cofre de secrets — um Secret pré-criado ou um sincronizado pelo External Secrets — ela também prevalece, e não há nada extra a configurar. A URL embutida é entregue como um ConfigMap listado antes do Secret do app em envFrom, e o Kubernetes deixa a última fonte vencer em caso de chaves duplicadas, então o seu valor sobrescreve o dele sem que o chart precise lê-lo.

O Redis embutido é deliberadamente não persistente (--save "", --appendonly no) com um limite de 512 MB: o Studio guarda nele estado de coordenação e chaves de vida curta, então um restart custa atualizações ao vivo em andamento, não dados já gravados.

Se networkPolicy.enabled=true, o egresso para o Redis embutido é permitido automaticamente. Um Redis externo precisa da própria regra em networkPolicy.egress — o chart não tem como saber o seu host e porta na hora de renderizar.

Serviços gerenciados funcionam e são a escolha recomendada para produção:

AWS — ElastiCache for Redis ou MemoryDB
GCP — Memorystore for Redis
Azure — Azure Cache for Redis

Coloque a instância na mesma VPC/VNet do cluster e use o endpoint privado dela. Ative TLS (rediss://) e autenticação.

O dimensionamento é modesto: o Studio usa o Redis para coordenação, não para armazenamento em volume. Uma instância de 1–2 GB atende a maioria dos deployments. Prefira um tier replicado/HA para que um failover não interrompa a colaboração ao vivo.

TLS para um endereço IP

Se REDIS_URL usa rediss:// e o host é um IP puro — comum com endpoints do AWS PrivateLink — a verificação de hostname do TLS não consegue casar um IP com o certificado. O Studio lança um erro em vez de conectar de forma insegura, na primeira vez que abre uma conexão com o Redis. Defina a sobrescrita de SNI com o nome DNS para o qual o certificado foi emitido:

REDIS_URL=rediss://:password@10.0.12.34:6379
REDIS_TLS_SERVERNAME=my-cluster.abc123.ng.0001.use1.cache.amazonaws.com

Com um hostname DNS em REDIS_URL, a verificação padrão funciona e nenhuma sobrescrita é necessária.

Verificação

# Kubernetes
kubectl exec -n studio deploy/studio-app -- printenv REDIS_URL

# Docker Compose
docker compose -f docker-compose.prod.yml exec redis redis-cli ping   # PONG

O teste funcional: abra o mesmo workflow em duas janelas do navegador atendidas por réplicas diferentes e confirme que as edições aparecem nas duas. Com uma única réplica isso sempre passa, então suba para duas antes de testar.

Observe os logs do app na inicialização em busca de erros de conexão do Redis — uma senha errada ou um host inacessível são registrados ali.

Common Questions

É obrigatório em qualquer deployment com mais de uma réplica de app ou de realtime, porque o pub/sub e o adaptador do Socket.IO não têm fallback entre pods. Com uma única réplica, a maioria dos subsistemas cai para o Postgres ou para estado em memória — com uma exceção: a autenticação da CLI exige Redis em qualquer número de réplicas.

Sim, por padrão — a mesma imagem redis:7-alpine que o Docker Compose usa. Defina redis.enabled: false e coloque uma connection string em app.env.REDIS_URL para usar uma instância gerenciada, que é a melhor escolha para produção.

Pouco. O Studio o usa para coordenação e chaves de vida curta, não para dados em volume — 1–2 GB atendem a maioria dos deployments. Priorize um tier HA/replicado em vez de tamanho bruto.

Sim, sem perda de dados para a aplicação. O Redis guarda caches, chaves de coordenação e eventos em trânsito. Perdê-lo descarta as atualizações ao vivo em andamento; os dados já gravados ficam no PostgreSQL e no object storage. Persistência não é necessária.