Redis

What can you do with it?

Redis is a single native engine per VPS and the app is the engine itself. ArduMaker installs it (or adopts the one already running), creates its own ACL user and, if requested, publishes it with TLS for certain IPs.

• Use it as a cache or queue from the VPS apps (127.0.0.1:6379).
• Start, stop or restart it.
• Reveal user, password and the rediss:// URI.
• From the VPS Redis tab: statistics, memory, keys, size per database, last save, persistence, configuration and flushing.

When should you use it?

• Cache, sessions or job queues of an app deployed on the same VPS.
• An external service that needs Redis with TLS from known IPs.

How does it work in ArduMaker?

1. Engine: if absent, it is installed once; if it already runs, it is adopted without reinstalling or changing version or password. A version older than 6.0 fails with redis_no_soportado without touching anything.
2. app<id>_<hex> credential with a random password, stored encrypted before touching the VPS.
3. ACL SETUSER <user> reset on ~* &* +@all -@admin -@dangerous with the password, through stdin; the admin password travels in REDISCLI_AUTH, never in -a. The default user is not touched.
4. It is persisted with ACL SAVE (if there is an aclfile) or CONFIG REWRITE.
5. Health as the app user: PING, SET of its own temporary key with EX 60, GET and DEL. It never lists nor reads customer keys.

Only external_access is accepted in config: Redis numeric databases do not isolate and are not offered. A second request on the same VPS answers app_ya_existe with the id of the existing one.

config.external_access decides whether the database is reachable from the internet: {"ips": [...]} opens it only to those IPs; {"local": true} (or false) keeps it inside the VPS. If omitted, the dashboard uses the installer's IP; over MCP the agent's IP does not count, so without ips the database stays local instead of failing.

What actually changes?

Internet access and IP allowlist

By default the engine listens only inside the VPS (6380 on 127.0.0.1). To use the database from outside, ArduMaker publishes an endpoint of the engine: db-<VPS id> inside the platform zone (direct DNS record, no proxy), on a reserved port between 61000 and 64999. On the host, a proxy carries that port to the VPS 6380 and the firewall lets in only the IPs on the list.

For Redis the proxy points to tls-port 6380 with the certificate of the db-<id> name; plain 6379 is never published. Enabling TLS for the first time restarts Redis: it is done automatically only if Apps installed it; on an adopted one it waits for confirmation.

The list belongs to the engine, not to each database: changing it from any Redis database changes access for every database of that engine on that VPS (the answer says so with shared_with_engine and affected_apps).

1. Missing firewall rules are added, one per CIDR (ufw allow from <cidr> to any port <port> proto tcp).
2. Then the extra ones are removed and their open connections are cut.
3. Only then is the listener created and verified: rules equal to the list, no rule open to anyone, listener present and a TLS handshake with the right name.

Uninstalling, persistence and backups

• Without delete_data (the default): the app's own external access is closed and it stops being listed as installed, but the database, its user and its data stay on the VPS. The next reconciliation shows it as discovered. Nothing is lost.
• On Redis uninstalling always removes the ACL user Apps created (it is an access, not data). With delete_data it also flushes every key (FLUSHALL), unless that Redis holds an n8n queue. The engine stays installed.
• The engine is never uninstalled from Apps: it stays installed even with no databases.
• If the VPS or the engine do not answer, desinstalar_app with forzar=true tries each step once, removes the app and lists in not_cleaned what was left on the server.
• Data lives on the VPS disk and travels in its weekly backup, which is taken while the VPS is running. For a consistent copy of a specific database it is better to also make your own dump from the database manager (export) or with the engine's tools.

Diagram

Expected result

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

The rediss://<user>@<host>:<port>/0 URI appears without password once access is ready; it names database 0 (no numeric database is assigned per app).

Errors and troubleshooting

MCP access

The whole database lifecycle can be operated over MCP with the permissions of the person who authorized the agent. Reference at /mcp/docs and /mcp/bases-de-datos.

• Read: ver_catalogo_apps, ver_preflight_app, listar_apps_empresa, ver_app, ver_acceso_app (host, port, TLS and IP list, no secrets), ver_operacion_app.
• Modify: instalar_app with app_type: redis (requires idempotency_key), cambiar_lista_ip_app (only if its owner is an admin; IPs must be named explicitly: the agent's IP is not the person's), reintentar_operacion_app, refrescar_apps.
• Sensitive: revelar_credencial_app (admins only, no idempotency_key; the answer is marked sensible: true and the audit records that it was revealed, never the value).
• Destructive: revocar_acceso_app (closes external access for the whole engine) and desinstalar_app (with delete_data it erases data; requires confirm_delete_data).

To read and write data inside the database, the agent uses the database manager tools. An agent authorized as read-only does not see the tools that modify and cannot reveal credentials.

Also, controlar_app accepts start, stop and restart on the Redis app. Keys and engine configuration are seen from the dashboard Redis tab: they have no MCP tool.

Related features

• PostgreSQL
• n8n
• Firewall and ports
• SSH tunnels
• Backups