Question
Appwrite Cloud versus Self‑Hosted: Trade‑off Between Managed Simplicity and Full Control for Production Deployments
Dev Dey
0 reputation · 03 Nov 2020, 06:48 UTC
24.4K views
Loading…
0 reputation · 03 Nov 2020, 06:48 UTC
The goal is to select a deployment strategy that preserves the straightforward local development experience while ensuring reliable production operation, data sovereignty, and the ability to tailor backend services as needed.
Locally, a Docker Compose setup relies on APP_DOMAIN=localhost and default environment variables, which works until the service is exposed via a public FQDN; in production this mismatch causes connection failures unless the variables are updated. Appwrite Cloud removes infrastructure management but locks the underlying MariaDB and Redis configurations, limiting fine‑grained tuning. Self‑hosting grants complete control over databases, storage volumes, and function runtimes, yet it introduces the responsibility for SSL certificates, reverse‑proxy configuration, and careful volume mapping to avoid data loss during upgrades. Additionally, the integrated Appwrite Functions runtime may be insufficient for complex, long‑running background jobs, prompting consideration of external webhooks.
Given these constraints, which approach best balances operational simplicity with the need for configurable infrastructure and extensible function execution?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 03 Nov 2020, 16:42 UTC
When you self‑host Appwrite, the APP_DOMAIN variable must exactly match the public FQDN that browsers use to reach the console and API. If you keep the localhost value used in Docker Compose, the session cookies are set for localhost and are rejected by the browser, leading to CORS or authentication errors once the service is exposed behind a reverse proxy.
In addition, SSL termination is typically handled by the reverse proxy (e.g., Nginx, Traefik). The proxy forwards plain HTTP to the Appwrite containers, so APP_HOST and APP_WORKER_HOST should point to the internal Docker service names (often appwrite and appwrite-worker) rather than the public domain. Mis‑aligning these variables causes internal routing failures between the console, API and workers.
Appwrite Cloud removes the need to manage SSL certificates and reverse‑proxy configuration; it automatically provisions a Let’s Encrypt certificate for custom domains and terminates TLS at the edge. However, the underlying MariaDB and Redis instances are locked to the defaults provided by the platform, so you cannot adjust parameters such as innodb_buffer_pool_size or redis maxmemory.
Regarding functions, the built‑in runtime enforces a short execution window (typically a few seconds to a minute) and limited memory, making it unsuitable for long‑running background jobs. For such workloads the recommended pattern is to trigger an external webhook or worker service via Appwrite events.
appwrite