Self-host Appwrite on redu
Appwrite is an open-source backend-as-a-service that gives your apps authentication, databases, file storage, and serverless functions behind one API. Teams self-host it to keep user data and backend logic on infrastructure they control. On redu, your agent runs Appwrite for you on real EU infrastructure, so you set nothing up by hand.
License: Appwrite is licensed under BSD-3-Clause. That is a permissive open source license, so you can self-host it freely. In this guide you are the operator, running Appwrite 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 the example here, but any MCP client works) at Appwrite’s official Docker setup and tell it:
Deploy Appwrite on redu using its official docker-compose, and expose the web UI.Appwrite ships an official docker-compose setup and official Docker images. Your agent uses deploy_compose to bring the whole stack up on one EU VM with podman-compose up -d --build, then serves the Appwrite web console at https://<name>.redu.cloud. redu does not rewrite your compose file: it runs the official setup as-is and exposes the one service you point it at.
Database
Appwrite’s official compose file bundles its own datastore: MariaDB for persistent data (users, projects, collections, file metadata) plus Redis for sessions, cache, realtime, and job queues. Keeping those bundled services is the clean default, and it means Appwrite needs nothing external to run.
For most self-hosters, keeping the bundled MariaDB and Redis from the compose file is the simplest and most reliable path, and it is what we recommend for Appwrite.
If you would rather run the relational database on a separate machine, note that Appwrite needs a MariaDB/MySQL-compatible database, so use redu’s managed MySQL/MariaDB resource (not managed Postgres). Your agent can provision it and point Appwrite at it by appending the connection env to the compose project’s .env, including the DATABASE_* aliases redu injects alongside the standard variables:
Provision a redu managed MariaDB and configure Appwrite to use it instead of the bundled database.Appwrite still needs Redis for sessions, cache, and queues even when the relational database is external, so keep the bundled Redis service in the compose file in that case.
Access it
Once the deploy finishes, Appwrite comes up at https://<name>.redu.cloud with TLS already in place (a wildcard cert), so there is no per-app certificate setup. Open that URL and complete Appwrite’s first-run setup to create your initial account and project, then start wiring your apps to the API.
Keep it running
Deploys are self-healing: redu recreates and retries until Appwrite 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 Appwrite, adjust its configuration, or fix an issue in place, and commit any repo changes back with a GitHub token. Because these are real machines, the agent operates the app the same way you would.
What’s next
Stuck? support@redu.cloud