Self-host Supabase on redu
Supabase is an open-source Firebase alternative built on Postgres. It bundles a database, authentication, file storage, realtime subscriptions, and auto-generated REST and GraphQL APIs behind a single dashboard. People self-host it to keep their data in their own environment and avoid per-seat SaaS pricing. On redu, your AI agent runs the full Supabase stack for you on real EU infrastructure, so you set up nothing by hand.
License: Supabase is licensed under Apache-2.0. That is a permissive open-source license, so you are free to self-host it. In this guide you are the operator, running Supabase on your own redu infrastructure.
Deploy it with your agent
Connect the redu MCP:
claude mcp add --transport http redu-cloud https://mcp.redu.cloud/mcpPoint your agent (Claude Code is one example, but any MCP client works) at Supabase’s official Docker setup and tell it:
Deploy Supabase on redu using its official docker-compose, and expose the web UI.Supabase ships an official multi-container docker-compose.yml (Studio, the API gateway, auth, storage, realtime, and the database). Your agent uses deploy_compose to run that whole stack on one EU VM with podman-compose up -d --build, then exposes the Studio web UI at https://<name>.redu.cloud. redu never rewrites your compose file. Your agent discovers the exposed service’s host port at deploy time and points the public URL at it.
Database
Supabase runs on PostgreSQL, and its official compose file already includes a purpose-built Postgres container with the roles and extensions the rest of the stack depends on. The clean default is to keep that database service from the compose file (deploy_compose database mode compose), since Supabase’s services are tightly wired to their bundled Postgres.
If you would rather run Postgres as a separate managed instance, have your agent provision one:
Provision a redu managed Postgres for this deployment.redu injects the connection environment (including DATABASE_* aliases alongside the standard Postgres variables) so tools connect without manual mapping. For Supabase specifically, keeping its bundled Postgres is the simplest path; reach for managed Postgres only if you have a clear reason to separate it.
Access it
Once the stack is healthy, Supabase comes up at https://<name>.redu.cloud with TLS already handled by a wildcard certificate, so there is no per-app cert setup. Open that URL to reach Supabase Studio. On first run you will set up your project secrets and admin access following Supabase’s own configuration steps; be sure to replace the example placeholder passwords and keys before using it for anything real.
Keep it running
Deploys are self-healing: redu recreates and retries the stack until it actually runs, and get_deployment returns the build log if you want to see what happened. Day two, your agent can SSH into the VM (via get_ssh_command) to update Supabase, adjust configuration, or fix issues in place, and commit any repo fixes back with a GitHub token. It stays a real machine you and your agent can operate.
What’s next
Stuck? support@redu.cloud