Redis

O que permite fazer?

O Redis é um único motor nativo por VPS e o app é o próprio motor. A ArduMaker o instala (ou adota o que já roda), cria um usuário ACL próprio e, se pedido, o publica com TLS para certos IPs.

• Usá-lo como cache ou fila pelos apps do VPS (127.0.0.1:6379).
• Iniciá-lo, pará-lo ou reiniciá-lo.
• Revelar usuário, senha e URI rediss://.
• Pela aba Redis do VPS: estatísticas, memória, chaves, tamanho por banco, último salvamento, persistência, configuração e esvaziamento.

Quando convém usar?

• Cache, sessões ou filas de tarefas de um app publicado no mesmo VPS.
• Um serviço externo que precisa de um Redis com TLS a partir de IPs conhecidos.

Como funciona na ArduMaker?

1. Motor: se não existir, é instalado uma vez; se já roda, é adotado sem reinstalar nem mudar versão ou senha. Uma versão anterior à 6.0 falha redis_no_soportado sem tocar nada.
2. Credencial app<id>_<hex> com senha aleatória, guardada criptografada antes de tocar o VPS.
3. ACL SETUSER <usuário> reset on ~* &* +@all -@admin -@dangerous com a senha, por stdin; a senha administrativa viaja em REDISCLI_AUTH, nunca em -a. O usuário default não é tocado.
4. É persistido com ACL SAVE (se houver aclfile) ou CONFIG REWRITE.
5. Saúde como o usuário do app: PING, SET de uma chave temporária própria com EX 60, GET e DEL. Nunca lista nem lê chaves do cliente.

Em config só se aceita external_access: os bancos numéricos do Redis não isolam e não são oferecidos. Um segundo pedido no mesmo VPS responde app_ya_existe com o id do existente.

config.external_access decide se o banco sai para a internet: {"ips": [...]} abre só para esses IPs; {"local": true} (ou false) o deixa só dentro do VPS. Se não for informado, pelo painel usa-se o IP de quem instala; via MCP o IP do agente não conta, então sem ips o banco fica local em vez de falhar.

O que muda realmente?

Acesso pela internet e lista de IP

Por padrão o motor escuta só dentro do VPS (6380 em 127.0.0.1). Para usar o banco de fora, a ArduMaker publica um endpoint próprio do motor: db-<id do VPS> dentro da zona da plataforma (registro DNS direto, sem proxy), em uma porta reservada entre 61000 e 64999. No host, um proxy leva essa porta ao 6380 do VPS e o firewall só deixa entrar os IPs da lista.

Para o Redis o proxy aponta para a tls-port 6380 com o certificado próprio do nome db-<id>; a 6379 sem TLS nunca é publicada. Ativar o TLS pela primeira vez reinicia o Redis: é feito sozinho só se o Apps o instalou; em um adotado fica pendente de confirmação.

A lista é do motor, não de cada banco: alterá-la a partir de qualquer banco Redis muda o acesso de todos os bancos desse motor nesse VPS (a resposta indica com shared_with_engine e affected_apps).

1. As regras de firewall que faltam são adicionadas, uma por CIDR (ufw allow from <cidr> to any port <porta> proto tcp).
2. Depois as que sobram são removidas e suas conexões abertas são cortadas.
3. Só então o listener é criado e verificado: regras iguais à lista, nenhuma regra aberta a qualquer um, listener presente e handshake TLS com o nome correto.

Desinstalar, persistência e cópias

• Sem delete_data (o normal): o acesso externo próprio é fechado e o app deixa de aparecer como instalado, mas o banco, seu usuário e seus dados ficam no VPS. A próxima reconciliação o mostra como detectado. Nada se perde.
• No Redis a desinstalação sempre remove o usuário ACL criado pelo Apps (é um acesso, não um dado). Com delete_data também esvazia todas as chaves (FLUSHALL), salvo se esse Redis salvar a fila de um n8n. O motor continua instalado.
• O motor nunca é desinstalado pelo Apps: fica instalado mesmo sem bancos.
• Se o VPS ou o motor não responderem, desinstalar_app com forzar=true tenta cada passo uma vez, remove o app e lista em not_cleaned o que ficou no servidor.
• Os dados vivem no disco do VPS e viajam na sua cópia semanal, feita com o VPS ligado. Para uma cópia consistente de um banco específico convém também um dump próprio pelo gerenciador de bancos de dados (exportar) ou com as ferramentas do motor.

Esquema

Resultado esperado

rediss://app<id>_<hex>@db-<vps>.<zona>:<puerto>/0

A URI rediss://<usuário>@<host>:<porta>/0 aparece sem senha quando o acesso está pronto; nomeia o banco 0 (não é atribuído um banco numérico por app).

Erros e resolução

Relação com MCP

Todo o ciclo do banco é operado via MCP com as permissões da pessoa que autorizou o agente. Referência em /mcp/docs e /mcp/bases-de-datos.

• Leitura: ver_catalogo_apps, ver_preflight_app, listar_apps_empresa, ver_app, ver_acceso_app (host, porta, TLS e lista de IP, sem segredos), ver_operacion_app.
• Modificam: instalar_app com app_type: redis (exige idempotency_key), cambiar_lista_ip_app (só se o dono for admin; os IPs são informados explicitamente: o IP do agente não é o da pessoa), reintentar_operacion_app, refrescar_apps.
• Sensível: revelar_credencial_app (só admin, não aceita idempotency_key; a resposta vem marcada sensible: true e a auditoria registra que foi revelado, nunca o valor).
• Destrutivas: revocar_acceso_app (fecha o acesso externo de todo o motor) e desinstalar_app (com delete_data apaga os dados; exige confirm_delete_data).

Para ler e escrever dados dentro do banco, o agente usa as ferramentas do gerenciador de bancos de dados. Um agente autorizado como somente leitura não vê as ferramentas que modificam nem pode revelar credenciais.

Além disso, controlar_app aceita start, stop e restart sobre o app Redis. As chaves e a configuração do motor são vistas pela aba Redis do painel: não têm ferramenta MCP.

Funcionalidades relacionadas

• PostgreSQL
• n8n
• Firewall e portas
• Túneis SSH
• Cópias de segurança