redu.cloud agent-mutable clusters, on a real production workflow
An AI agent takes a real app all the way to production on redu.cloud in one session. It deploys Chatwoot onto a single VM with its own dedicated managed Postgres and Redis, upgrades that live VM into an autoscaling cluster behind a load balancer, turns on automated backups, then does the part immutable clouds do not allow: it mutates the running production cluster live. It creates an account that stays consistent across every member, and it resolves a real incident by going into the live machine and fixing it in place, all behind the same URL. On redu a cluster is a real, mutable machine an agent can change while it serves production. On Kubernetes a pod is stamped from an immutable image, so fixing production means building a new image and rolling it while it bleeds; on an AWS autoscaling group a live edit sticks only on that one instance and is thrown away on the next refresh. Raw, only dead time cut, every mistake and self-heal left in.
- ChatwootThe open-source customer engagement platform the agent deploys, clusters, and fixes live in production.
- 0:00Intro
- 0:30Deploy the app on one VM with dedicated managed Postgres and Redis
- 2:28Upgrade the live VM into an autoscaling cluster
- 4:23The cluster in the console
- 5:13Automated backups
- 6:15redu clusters vs Kubernetes and AWS autoscaling: live production mutations
- 8:30First live mutation: create an account, consistent across every member
- 10:02An incident on the live cluster, and the agent resolves it in place
- 13:00Wrap-up
1. Connect the redu MCP:
claude mcp add --transport http redu https://mcp.redu.cloud/mcp --client-id redu-mcp2. Point your agent at the repo and say: Deploy Chatwoot on redu, upgrade it to a cluster, and when it breaks in production, go in and fix it live.


