Redis

¿Qué permite hacer?

Redis es un solo motor nativo por VPS y la app es el propio motor. ArduMaker lo instala (o adopta el que ya corre), le crea un usuario ACL propio y, si se pide, lo publica con TLS para ciertas IP.

• Usarlo como caché o cola desde las apps del VPS (127.0.0.1:6379).
• Iniciarlo, detenerlo o reiniciarlo.
• Revelar usuario, contraseña y URI rediss://.
• Desde la pestaña Redis del VPS: estadísticas, memoria, claves, tamaño por base, último guardado, persistencia, configuración y vaciado.

¿Cuándo conviene usarlo?

• Caché, sesiones o colas de trabajos de una app desplegada en el mismo VPS.
• Un servicio externo que necesita un Redis con TLS desde IP conocidas.

¿Cómo funciona en ArduMaker?

1. Motor: si no está, se instala una vez; si ya corre, se adopta sin reinstalar ni cambiar versión ni contraseña. Una versión anterior a 6.0 falla redis_no_soportado sin tocar nada.
2. Credencial app<id>_<hex> con contraseña aleatoria, guardada cifrada antes de tocar el VPS.
3. ACL SETUSER <usuario> reset on ~* &* +@all -@admin -@dangerous con la contraseña, por stdin; la clave administrativa viaja en REDISCLI_AUTH, nunca en -a. El usuario default no se toca.
4. Se persiste con ACL SAVE (si hay aclfile) o CONFIG REWRITE.
5. Salud como el usuario de la app: PING, SET de una clave temporal propia con EX 60, GET y DEL. Nunca lista ni lee claves del cliente.

En config solo se acepta external_access: las bases numéricas de Redis no aíslan y no se ofrecen. Un segundo pedido en el mismo VPS responde app_ya_existe con el id del que ya está.

config.external_access decide si la base sale a internet: {"ips": [...]} abre solo a esas IP; {"local": true} (o false) la deja solo adentro del VPS. Si no se indica, desde el panel se toma la IP de quien instala; por MCP la IP del agente no cuenta, así que sin ips la base queda local en vez de fallar.

¿Qué cambia realmente?

Acceso desde internet y lista de IP

Por defecto el motor escucha solo dentro del VPS (6380 en 127.0.0.1). Para usar la base desde afuera, ArduMaker publica un endpoint propio del motor: db-<id del VPS> dentro de la zona de la plataforma (registro DNS directo, sin proxy), en un puerto reservado entre 61000 y 64999. En el host, un proxy lleva ese puerto al 6380 del VPS y el firewall deja entrar solo las IP de la lista.

Para Redis el proxy apunta al tls-port 6380 con el certificado propio del nombre db-<id>; el 6379 sin TLS nunca se publica. Activar TLS la primera vez reinicia Redis: se hace solo si lo instaló Apps; en uno adoptado queda pendiente de confirmación.

La lista es del motor, no de cada base: cambiarla desde cualquier base de Redis cambia el acceso de todas las bases de ese motor en ese VPS (la respuesta lo indica con shared_with_engine y affected_apps).

1. Se agregan las reglas de firewall que faltan, una por CIDR (ufw allow from <cidr> to any port <puerto> proto tcp).
2. Después se quitan las que sobran y se cortan sus conexiones abiertas.
3. Recién entonces se crea el listener y se verifica: reglas iguales a la lista, ninguna regla abierta a cualquiera, listener presente y handshake TLS con el nombre correcto.

Desinstalar, persistencia y copias

• Sin delete_data (lo normal): se cierra el acceso externo propio y la app deja de figurar como instalada, pero la base, su usuario y sus datos quedan en el VPS. La siguiente reconciliación la muestra como detectada. No se pierde nada.
• En Redis la baja siempre quita el usuario ACL que creó Apps (es un acceso, no un dato). Con delete_data además vacía todas las claves (FLUSHALL), salvo que ese Redis guarde la cola de un n8n. El motor queda instalado.
• El motor nunca se desinstala desde Apps: queda instalado aunque no tenga bases.
• Si el VPS o el motor no responden, desinstalar_app con forzar=true intenta cada paso una vez, da de baja la app y lista en not_cleaned lo que quedó en el servidor.
• Los datos viven en el disco del VPS y viajan en su copia semanal, que se toma con el VPS andando. Para una copia consistente de una base concreta conviene además un volcado propio desde el gestor de bases de datos (exportar) o con las herramientas del motor.

Esquema

Resultado esperado

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

La URI rediss://<usuario>@<host>:<puerto>/0 aparece sin contraseña cuando el acceso está listo; nombra la base 0 (no se asigna una base numérica por app).

Errores y resolución

Relación con MCP

Todo el ciclo de la base se opera por MCP con los permisos de la persona que autorizó al agente. Referencia en /mcp/docs y /mcp/bases-de-datos.

• Lectura: ver_catalogo_apps, ver_preflight_app, listar_apps_empresa, ver_app, ver_acceso_app (host, puerto, TLS y lista de IP, sin secretos), ver_operacion_app.
• Modifican: instalar_app con app_type: redis (exige idempotency_key), cambiar_lista_ip_app (solo si su dueño es admin; las IP se nombran explícitas: la IP del agente no es la de la persona), reintentar_operacion_app, refrescar_apps.
• Sensible: revelar_credencial_app (solo admin, no acepta idempotency_key; la respuesta viene marcada sensible: true y la auditoría registra que se reveló, nunca el valor).
• Destructivas: revocar_acceso_app (cierra el acceso externo de todo el motor) y desinstalar_app (con delete_data borra los datos; requiere confirm_delete_data).

Para leer y escribir datos dentro de la base, el agente usa las herramientas del gestor de bases de datos. Un agente autorizado solo lectura no ve las herramientas que modifican ni puede revelar credenciales.

Además, controlar_app acepta start, stop y restart sobre la app Redis. Las claves y la configuración del motor se ven desde la pestaña Redis del panel: no tienen herramienta MCP.

Funciones relacionadas

• PostgreSQL
• n8n
• Firewall y puertos
• Túneles SSH
• Copias de seguridad