Which Appwrite option fits your team and constraints
Choose between Appwrite Cloud and self-hosted Appwrite by starting from the constraint that is forcing the question. A renewal, a data residency or compliance requirement, or a Free or Pro plan limit you are approaching each points to a different answer. Appwrite Cloud fits teams that want Appwrite operated for them and can work within the plan limits, including the freeze behavior on Free projects and the overage model on Pro. Self-hosted Appwrite fits teams that must keep project data inside their own environment and have people to operate it. Both run the same core stack, which the Appwrite README describes as covering Auth, Databases, Storage, Functions, Sites, Messaging, Firewall, Realtime and MCP, and the repository is available under the BSD-3-Clause license. The license lets you run it yourself, but it does not decide who carries the operating work.
Neither option is simply cheaper or safer. The 2.5.0 release, dated October 13, 2026, is the version a new self-hosted install would normally start from, and you should confirm the current release and upgrade path before you plan around it. Self-hosting also moves responsibility for backups, upgrades and failover onto your team. The Appwrite Helm chart documentation states that its built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so any production expectation of high availability means you add managed services or operators. Ask your vendor or platform team what availability target your users actually need before you choose.
Four questions usually settle the decision: where project data must physically live, how many engineers you can commit to running the platform over time, what failover behavior your service level requires, and how often your projects are likely to hit resource limits. If data location and compliance rules are fixed, self-hosting is often the starting point, and the remaining question is staffing. If limits are the trigger, check how often Pro overages would occur and whether a budget cap and alerts would be acceptable before you assume you must leave Cloud. Document your answers in writing, because they will drive the migration plan, the cost model and the evidence your auditors will ask for.
Which option fits each scenario
This table matches five common situations to the option that usually fits better, with the condition that tips the decision. Read each row as a starting point, then confirm the limits and plan details against Appwrite's current pricing page and your own compliance and staffing constraints.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Prototype or small app within Free limits | Appwrite Cloud Free | The project stays under the Free plan's project, user and resource limits, and a pause after a week of inactivity is acceptable for testing |
| Growing app that needs steady uptime on Pro | Appwrite Cloud Pro | Usage fits the Pro limits per project, and the team accepts overage charges and budget alerts in exchange for no infrastructure to run |
| Regulated workload with data residency requirements | Self-hosted Appwrite | Your compliance team needs control over where data sits, which logs are kept and who holds backups, and you can run the platform inside your audited environment |
| Team without database operations staff | Appwrite Cloud (Pro or Enterprise) | No one on the team can own PostgreSQL backups, upgrades and failover, so a managed hosted service reduces the operational burden |
| Team with existing Kubernetes or Docker operations | Self-hosted Appwrite | The team already runs container platforms, monitoring and backups, and can add production datastores such as managed PostgreSQL or operators, since the built-in datastores run a single replica |
What happens on Appwrite Cloud when a project hits a limit
The first thing to know is that Appwrite Cloud handles a limit breach differently by plan. On the Free plan, a project that reaches a resource limit freezes and the Console switches to read-only mode, so writes stop until you upgrade or the usage resets. On Pro, projects keep running and overage is billed instead, with email alerts at 75% and 100% of each limit and an optional organization budget cap that you set. The Free plan also pauses a project after one week of inactivity, and the pricing page lists its ceiling at 2 projects and 75K monthly active users. Pro is listed at $25 per month with 2 TB of bandwidth, 150 GB of storage and 200K monthly active users per project, plus daily backups.
For an app with traffic spikes, the plan decides whether a launch day or a viral post becomes an outage. A Free project that crosses its monthly active user or bandwidth ceiling during a spike loses writes at the moment users are most active, and a project left idle for a week may be paused before a scheduled demo. On Pro, the spike is served but the invoice grows, so the decision is whether the organization budget cap should stop spending or let the project run. Confirm with Appwrite exactly how overage is metered for each resource, and whether the 75% alert gives your team enough time to act, before you pick a cap value.
Teams that need uninterrupted writes should treat the Cloud limit model as a commercial decision rather than a technical setting. Map your expected monthly active users, storage growth and bandwidth against the Pro limits, decide who receives the alert emails, and agree who may raise the budget cap at 2 a.m. If your requirement is that writes never stop, ask whether a Pro project with a cap still freezes at its limit, and which Enterprise terms change that. In a self-hosted install you own the capacity, so a limit becomes a sizing and monitoring task rather than a billing event, which shifts the risk to your own on-call process.
Where data lives and which compliance evidence you inherit or build
Appwrite Cloud and self-hosted Appwrite put different parties in charge of where data sits, which logs and backups exist, and who can prove the controls work. Each card below marks a decision that changes when you move from the hosted edition to your own infrastructure. Confirm current Cloud coverage with Appwrite directly before relying on it.
Data location and region choice
On Appwrite Cloud, the provider chooses where your project's infrastructure runs, so you need to confirm which regions are available and where backups and logs are stored. With self-hosted Appwrite, the location is whatever cloud account, data centre or air-gapped network you choose, and you decide it before the first install. Check whether any sub-processors or support tooling move data outside the region you need. Ask Appwrite in writing for the data residency options on your plan.
SOC 2 Type II coverage on Cloud
Appwrite Cloud is described as SOC 2 Type II certified, which covers the provider's controls over a period and is issued by an independent auditor. That report describes Appwrite's environment, not yours, so it does not cover your application code, your access reviews or your configuration of projects. Ask for the current report and its scope, and confirm which of your own controls the provider's report leaves to you.
BAA availability and HIPAA scope
Appwrite Cloud can sign a Business Associate Agreement, with HIPAA listed on the Enterprise plan. A BAA covers the provider's obligations, so you still need to confirm which features and regions fall inside its scope. Self-hosting removes the provider from the chain, but then the safeguards that a BAA would have covered become your responsibility. Confirm the current BAA terms and plan eligibility directly with Appwrite.
Controls you must evidence yourself
Self-hosted Appwrite means you produce the evidence for access control, change management, encryption settings, vulnerability handling and incident response. DeployOpen can plan and implement these controls, document them and prepare the evidence an assessor will ask for. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies perform those assessments.
Logs and backup ownership
On Cloud, the provider holds the platform logs and the backup schedule, and Pro plans include daily backups. Self-hosted, you own the retention period, the storage location, restore testing and the logs from the API, workers and reverse proxy. The built-in datastores in the Helm chart run a single replica without failover, so your backup and recovery plan must come from managed services or operators. Document who can read the logs and how long they are kept.
Identity and admin access
On Cloud, Appwrite staff access to your environment is governed by the provider's own controls, and your team administers projects through the Console. Self-hosted, you control the console administrators, the API keys, the server secrets and the host-level access to the database and object storage. Map who holds root access to the containers, the database and the Console, and set a review cycle for those accounts. Keep these records because assessors ask for them.
Docker Compose or Helm: how a self-hosted Appwrite install differs
The Docker path is the quickest route to a working self-hosted Appwrite. The installation guide lists the minimum host as 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2. The install starts with a docker run command using the appwrite/appwrite:2.5.0 image, which opens a setup wizard on port 20080, and the wizard generates the Compose configuration for the stack.
The sample Compose file runs several services on one host:
- Datastores: PostgreSQL, Redis and ClickHouse, all on the same machine as the API.
- Edge: Traefik for routing and TLS termination in front of the console and API.
- Application services: the Appwrite API, background workers, realtime and console containers.
- Functions: an Open Runtimes executor that runs your server-side functions.
- Storage: file storage on the local host, unless you configure an external target.
Treat this file as a starting point for a lab, pilot or small internal app, not as a production topology. A single host means one failure domain, and the datastores have no replica. Ask whether your team will add host-level backups, monitoring and a tested restore procedure, and whether the host sits in a region that meets your data residency rules.
The Helm path suits teams that already run Kubernetes and want Appwrite managed like their other workloads. Appwrite publishes an official chart at oci://ghcr.io/appwrite/charts/appwrite, so you install it from an OCI registry rather than from a classic chart repository. The chart deploys the application services into your cluster, and it is the most direct way to fit Appwrite into existing GitOps and namespace controls.
The key constraint sits in the datastores. The chart docs say the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover. Installing with the chart's defaults therefore gives you the same availability limits as the Compose host, now inside a cluster that may hide them.
- Managed services: point Appwrite at a managed PostgreSQL, Redis and object store with backups and failover in your cloud account.
- Operators: run PostgreSQL and other datastores under a Kubernetes operator that handles replicas and failover.
- Storage classes: confirm persistent volume behavior, snapshot support and node-failure handling for each stateful component.
- Ownership: assign who patches the datastores, rotates credentials and restores data during an incident.
Before you approve a Helm deployment, ask for a written map of which component is managed, which is operator-run and which uses the chart's single-replica defaults.
How costs split between Appwrite Cloud fees and self-hosting
On Appwrite Cloud, most of the bill is a subscription plus whatever you use beyond it. The Pro plan starts at $25 per month according to the Appwrite pricing page, and that figure includes 2 TB of bandwidth, 150 GB of storage and 200K monthly active users per project. Beyond those allowances, Pro projects keep running and incur overage charges, so the variable part is usage. Enterprise is custom-priced. Two controls limit surprises: email alerts at 75% and 100% of limits, and an optional organization budget cap. Ask the vendor for the overage rates, what the budget cap does when it is reached, and whether dedicated database compute or point-in-time recovery are add-ons to the plan you pick.
Self-hosting replaces that subscription with components you pay for directly: compute nodes for the Docker Compose or Kubernetes install, block and object storage, backup retention, monitoring, and a managed PostgreSQL service or database operator. Appwrite's own Helm chart documentation says its built-in datastores run a single replica without failover, so most production teams budget for managed databases or operators, which add their own line items. The largest recurring cost is usually staff time for upgrades, such as the move from 1.9.x to 2.x, plus on-call response. Those rates depend on your labor market and infrastructure, so confirm them internally rather than relying on any published figure.
Some costs are one-time and others recur. Setup, data migration, hardening and the first restore test are one-time efforts, though a migration of a live project may need a parallel run. Hosting, backups, monitoring, security testing and upgrade cycles recur for as long as you run the stack. When you request a quote from an implementation partner such as DeployOpen, ask for the fixed scope, the deliverables and which items are one-time versus retainer-based, and ask which infrastructure costs the partner will not cover. Then build a side-by-side model for a three-year horizon that includes both the Cloud overage exposure and the self-hosted staffing assumptions.
Cost components by side, one-time and recurring
Appwrite Cloud bills you for a plan and any overage, while self-hosted Appwrite moves those costs to infrastructure, data services and people. Each card below names one cost component, marks whether it is one-time or recurring, and states what moves it up or down, so you can ask a provider or your own team for the same line items.
Appwrite Cloud plan fees
Recurring. Cloud Pro is a monthly subscription per organization, and the plan includes bandwidth, storage and monthly active user allowances per project. Check which plan each project needs, how many projects share one organization, and how many monthly active users you expect before you commit. Confirm current fees on the pricing page, since plan terms change.
Cloud overages and budget caps
Recurring and variable. On Pro, projects keep running past their included limits and overage is billed, so the monthly total follows your traffic and storage growth. Ask whether the optional organization budget cap applies to every project, how alerts at 75% and 100% of limits reach your finance and operations contacts, and what happens to functions and storage once the cap is reached.
Dedicated database tiers on Cloud
Recurring. Larger database compute on Appwrite Cloud is a separate line item that you select per project. Ask the provider for the tier names, the compute and memory each includes, whether it can be resized without downtime, and whether the tier change is billed pro rata. Compare the tier you need with the single-node database you would size and run yourself.
Point-in-time recovery and backup retention
Recurring. Daily backups are part of the Pro plan, but point-in-time recovery is a distinct capability that you must confirm for your plan and region. Ask how many days backups are kept, where they are stored, how long a restore takes, and who performs it. On self-hosting, you pay for backup storage, the tool that takes consistent snapshots of PostgreSQL, and restore tests.
Self-hosted infrastructure and HA replicas
Recurring. Servers or cluster nodes for the Appwrite services, the database, Redis, ClickHouse and object storage are your largest self-hosted line. The Helm chart runs each built-in datastore as a single replica without failover, so high availability means extra replicas or managed services, which add compute, storage and cross-zone network cost. Size the install from the stated minimum of 2 CPU cores and 4 GB of RAM, then model production load with your own tests.
Managed database or operator fees
Recurring, or one-time to set up an operator. Choosing a managed PostgreSQL service replaces the single-replica database with a vendor fee that scales with instance size, storage and backup options. Choosing a Kubernetes operator avoids that fee but moves the cost to setup, upgrades and the engineers who run it. Ask the managed provider for replica, backup and point-in-time recovery pricing, and ask your own team how much time the operator will need each quarter.
Upgrade testing and on-call time
Recurring people cost. Appwrite releases often, and 2.0 moved new installs to PostgreSQL by default, so each upgrade needs a staging rehearsal, migration checks and a rollback plan. Add on-call coverage for database, storage and function incidents, plus monitoring and log retention. On Cloud, the provider absorbs this work, so budget this line only for the self-hosted side and count it against your internal team capacity.
What moving from Appwrite Cloud to self-hosted Appwrite involves
The sequence runs from confirming the target version and topology through migration, cutover and day-two operations, and ends with a self-hosted install that holds the migrated projects, with a rollback path until you are satisfied. Each step closes with a check you can run before moving on.
Confirm target version and topology
Your platform or infrastructure lead chooses the Appwrite release to run, the database engine (PostgreSQL is the default for new installs in Appwrite 2.0, with MariaDB and MongoDB also supported), and whether you run Docker Compose or the official Helm chart. Check the release notes for the version you pick, since 2.5.0 is the current release line in the facts and the Helm chart docs say built-in datastores run a single replica without failover. Confirm which features your projects use, such as Functions, Storage and Auth, and whether DocumentsDB or VectorsDB are needed, because those ship disabled and require engines a stock install does not deploy. Done when the topology decision is written down and signed off by the people who will run it.
Prepare the target install and datastores
Your infrastructure team provisions hosts that meet the installation guide's minimums (2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2 for a single-host install). For production, place PostgreSQL, Redis, ClickHouse and object storage on managed services or operators with replication and backups, because the built-in services are single-replica. Set up TLS, DNS and the domain Appwrite will serve on. Done when a fresh install completes its setup wizard and the Console loads, and the datastores have a tested restore path.
Inventory projects, users and credentials
Your team lists every project, database, bucket, function and site on Appwrite Cloud, along with the API keys, webhooks and domains that depend on them. Record which users need password hashes carried over, since Appwrite's Users API accepts several imported hash formats, so most users can keep their passwords without a reset if the source hash matches a supported type. Flag any custom domains, email providers and third-party callbacks that will change. Done when the inventory is complete and each dependency has an owner.
Run Appwrite Migrations in the supported direction
Using the Migrations feature described in the Appwrite docs, your engineer runs the transfer from the Cloud project into the self-hosted instance, after confirming in the docs that the current scope covers the resource types you use for the target version. Run a full migration against a staging install first. Done when the migration report shows the expected counts of users, documents, files and functions, and a sample of records matches the source.
Re-point SDK endpoints and configuration
Developers change the endpoint and project settings in each client and server SDK so apps talk to the self-hosted API, and update environment variables that hold API keys and project IDs. Mobile builds may need a new release because endpoints are often compiled in. Done when staging builds of the web, mobile and server applications sign in, read and write data against the self-hosted instance and no Cloud endpoint is called in logs.
Verify functions, storage and authentication
Your QA team exercises every function trigger, file upload and download, and login path, including password sign-in for migrated users, social logins, email verification and password reset emails. Confirm that the self-hosted executor runs each function with the same runtime and environment variables. Done when every critical user journey has passed in staging with test accounts, and the results are recorded.
Plan cutover and rollback
Agree the cutover window with application owners, freeze writes on Appwrite Cloud, run a final delta sync if your migration approach needs one, switch DNS or configuration, and keep the Cloud project intact until the new install has run in production without critical defects. Write down the rollback trigger and the steps to point clients back. Done when the runbook is approved and a rollback has been rehearsed in staging.
Set up backups and monitoring
Your operations team configures backups for PostgreSQL and object storage, tests a full restore into a separate environment, and sets alerts for API health, worker queues, disk, memory and certificate expiry. Confirm which parts of the Cloud service (such as daily backups on Pro) you now own and must replicate. Done when a restore has been tested end to end and alerts reach an on-call rota.
Questions buyers ask before choosing self-hosted Appwrite
How much effort does self-hosting Appwrite take, and who does the work?
Self-hosting moves the operational work from the vendor to your team. You run the Appwrite services, the databases, the object storage, backups, upgrades and monitoring inside your own accounts or data centers. The minimum install is modest: the installation guide lists 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2. Production effort is larger than that minimum because you must provision and operate the datastores yourself. Confirm the staffing model with your platform team before you commit, since the work recurs for as long as the platform runs.
Can a small team run self-hosted Appwrite alone?
A small team can run a single-node evaluation or a small internal app, but production needs someone accountable for backups, restores, upgrades and incident response. The Helm chart documentation states that the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so production data should use managed services or operators. Plan for on-call coverage and a tested restore procedure. If nobody on the team has run stateful services on Kubernetes or Docker before, the learning curve belongs in your estimate.
How long does a migration from Appwrite Cloud or another platform take?
The duration depends on the size of your data, the number of users, the number of functions and storage files, and how many client apps must be re-pointed. Appwrite Migrations can transfer complete projects, and the Migrations documentation describes the supported sources. DeployOpen does not publish a fixed timeline; a migration timeline follows from the written scope after the team inventories your projects. Ask the vendor and your own environment team to confirm the limits for your data volume before you schedule cutover.
Which password hash formats can I keep when moving users?
Appwrite's Users API accepts imported Scrypt modified, bcrypt, Argon2, MD5, PHPass, Scrypt and SHA hashes, so users can often keep their passwords without a forced reset. Firebase Auth uses a modified scrypt by default, and the Firebase CLI exports hashes with their parameters. Confirm your source algorithm and parameters in the export before you start, and test a sample login after import. Hash formats from other providers may not match, in which case a reset flow is the fallback.
Are DocumentsDB and VectorsDB available by default in self-hosted Appwrite?
No. Appwrite 2.0 added DocumentsDB for schemaless JSON documents and VectorsDB for embeddings, but both need PostgreSQL and MongoDB engines that a stock Appwrite install does not deploy. They ship disabled until you enable them and provision the required engines. Plan the datastore layout before you turn these features on, and confirm the configuration steps against the release notes for your version.
How often do releases arrive, and what do upgrades require?
Appwrite releases frequently. Appwrite 2.0 arrived on September 4, 2026, and 2.5.0 followed on October 13, 2026. Existing 1.9.x installs upgrade with one command and a migration, according to the 2.0 release notes, while the 1.9 line still received a maintenance release on October 8, 2026. Budget regular upgrade windows, test each upgrade in a staging copy, and take a verified backup first. Upgrade effort recurs, so include it in your running cost.
What support is available for a self-hosted Appwrite install?
Support for self-hosted Appwrite comes from the open-source project, its documentation and the community, and from any commercial support contract you arrange separately. Hosted plans and their support terms do not automatically apply to your install, so ask the vendor directly what it offers for self-managed deployments. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and agrees scope, deliverables and timelines in writing before work starts, so you can compare that with your internal capacity.
What a fixed-scope engagement covers for self-hosted Appwrite
A fixed-scope engagement for self-hosted Appwrite starts with decisions that Appwrite Cloud makes for you: where the stack runs, how the databases are provisioned, and who is accountable for backups and failover. DeployOpen agrees these in writing before work begins, so the scope document should name each item explicitly. Expect it to cover the topology: the install method (Docker Compose for a single host or the Helm chart for Kubernetes), the database engine choice between PostgreSQL, MariaDB and MongoDB, and how the built-in PostgreSQL, Redis, ClickHouse and object storage will be replaced by managed services or operators. The Appwrite Helm chart documentation notes that its built-in datastores run a single replica without failover, so the topology decision is where high availability gets designed, not assumed.
Implementation then covers installing Appwrite on your infrastructure, integrating it with your identity provider and your object storage, and hardening the install. Ask the proposal to name the authentication methods, the storage backend, the network paths, the secrets handling and the logging destination, since on Cloud some of these are supplied by the platform. The deliverables should also include backup and failover design, an upgrade runbook for moving between releases such as 2.0 and 2.5.0, and documentation your operators can use without the original team. Confirm with DeployOpen how upgrades and continuous testing would be delivered after go-live.
Pricing follows the written scope. DeployOpen does not publish a price list, so a quote is built from the components above, the number of environments, the migration work if you are moving from Appwrite Cloud, and whether ongoing support, upgrades or testing are needed as a retainer. Ask for each deliverable to be priced separately, so you can see which costs are one-time (design, installation, migration, documentation) and which recur (retainer support, infrastructure, your own staff time). DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any attestation, so ask for that boundary to be written into the scope too.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Appwrite Cloud vs self-hosted Appwrite, we start from the plan limits, data location and operating responsibilities your team actually faces, then build and hand over only what your environment needs.
How we scope
- Engagements are fixed-scope, with the Appwrite components, environments and data flows agreed in writing before work starts.
- The written scope lists which Cloud features you need that self-hosted Appwrite must replace, such as backups, failover and database tiers.
- Ask for a quote that separates hosting, database, backup, monitoring and staff time so each component can be compared.
How we build
- We deploy Appwrite from the official Docker or Helm installs into your infrastructure, with the database layer chosen during scoping.
- Test plans cover authentication, database access rules, storage, functions and realtime endpoints against your application requirements.
- Backup and restore runs are tested, and the results are recorded, before any production traffic is pointed at the install.
How we hand over
- You receive configuration, runbooks for upgrades and restores, and documented ownership of databases, backups and SDK endpoint changes.
- Migration steps for moving projects, users and password hashes are documented so your team can repeat them after handover.
- We prepare control evidence and documentation for your compliance assessment, while independent auditors issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Appwrite release upgrades, such as moving between major lines, with the upgrade plan reviewed in advance.
- Confirm the support response expectations, upgrade cadence and change windows in the written scope before signing.
