Appwrite Cloud cost vs self-hosted Appwrite: where the money goes
Self-hosting Appwrite removes the Cloud subscription and any overage line, but it replaces them with infrastructure, database operations and staff time that you pay for directly. If your renewal or a projected overage is pushing you to look at this, the honest answer is that the Cloud line item is only the start of the comparison. Appwrite's pricing page lists Pro from $25 per month, with 2 TB bandwidth, 150 GB storage and 200K monthly active users per project, and a Free plan at $0 with 75K monthly active users. Those figures are the subscription floor. Your real Cloud total depends on your bandwidth, storage, active users and any dedicated database tier or point-in-time recovery you add, so pull 90 days of usage from your Console and ask Appwrite for a written quote against that profile before comparing anything.
On the self-hosted side, the cost components are the servers, the database, backups and the people. Appwrite's installation guide sets a minimum of 2 CPU cores, 4 GB of RAM and 2 GB of swap for a single install, which is a floor for evaluation, not a production sizing. Production capacity should be sized from your own load tests. The database is the cost most often underestimated. Appwrite's Helm chart documentation states that the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, so a production budget should include a managed PostgreSQL service or an operator with replicas, backups and tested restores. Those services are billed separately, and their prices come from your provider, not from Appwrite. Ask your cloud or data center team for quotes on those components as well as on compute and object storage.
Staff time is the recurring cost that does not appear on any invoice from Appwrite. Someone must own upgrades (Appwrite 2.0 changed the engine and default database, and existing 1.9.x installs need a migration), on-call response, certificate and secret rotation, and restore drills. Your own staffing model and salary costs will decide how large that line is. Decide who owns each item before you compare totals, because a self-hosted total that leaves out a support rota is not a like-for-like comparison. A useful next step is to build a three-line model with infrastructure, managed database and operations hours, then ask a partner such as DeployOpen for a fixed-scope written estimate of the implementation and first-year run costs.
Which cost components change when you move from Appwrite Cloud
This table compares each cost line of Appwrite Cloud with the matching line when you run Appwrite yourself, and says whether it is one-time or recurring. Use it to see which lines the Appwrite pricing page itemizes and which you must confirm with the vendor before comparing totals.
| Cost component | Appwrite Cloud | Self-hosted Appwrite | One-time or recurring |
|---|---|---|---|
| Plan or subscription fee | Pro starts at $25 per month per the Appwrite pricing page; Enterprise is custom-priced | No Appwrite subscription fee for the open-source edition; you pay for servers and people | Cloud: recurring. Self-hosted: none for the software |
| Overages and usage above plan limits | Pro projects keep running and are billed for overage; email alerts fire at 75% and 100% of limits; an optional organization budget cap is available | Not billed by Appwrite; capacity cost is the servers, storage and bandwidth you provision and pay your cloud or data center provider | Cloud: recurring and variable. Self-hosted: recurring and sized by you |
| Dedicated database tiers and compute | Not itemized on the pricing page; confirm the tier, price and what it includes with Appwrite sales | Database hosts sized by you, or a managed PostgreSQL service priced by your provider | Both recurring |
| Point-in-time recovery | Not itemized on the pricing page; confirm whether it is included in Pro and at what cost | You configure WAL archiving and base backups in PostgreSQL; storage and engineering time are yours | Self-hosted: setup one-time, storage recurring |
| High availability replicas and failover | Not itemized on the pricing page; confirm replica pricing and failover terms with Appwrite | Appwrite's Helm chart runs its built-in datastores as a single replica without failover, so you add replicas, a failover tool and a load balancer or use managed services | Self-hosted: setup one-time, replicas and failover tooling recurring |
| Servers and infrastructure | Included in the plan; no separate line | Minimum stated by the install guide is 2 CPU cores, 4 GB RAM and 2 GB swap, but production sizing is larger and billed by your provider | Recurring |
| Managed PostgreSQL or operators | Included in the plan | Managed PostgreSQL from a cloud provider, or a PostgreSQL operator and its maintenance, billed separately | Recurring |
| Backups, upgrades and patching | Included in Pro, which includes daily backups per the pricing page; upgrades handled by Appwrite | Backup tooling, restore tests, Appwrite upgrades (2.0 required a migration) and PostgreSQL minor and major upgrades are your effort | Recurring staff time, mostly |
| Support and staff time | Support tier depends on plan; confirm response terms with Appwrite | Self-hosted Appwrite is community-supported; paid support, implementation and on-call come from you or a partner such as DeployOpen | Recurring, driven by your team and any retainer |
What moves the Appwrite cost comparison
Appwrite Cloud and self-hosted Appwrite price differently for the same stack, so the comparison turns on a few drivers. Each one below pushes cost in a known direction, and each is easier to check before a renewal or migration than after.
Monthly active users per project
Appwrite Cloud's Free plan includes up to 75K monthly active users and Pro includes 200K per project, so user growth is the first limit to model. On Cloud, moving past these allowances moves you to a higher plan or overage. Self-hosted, user count does not change your license cost, but it raises the compute, database and Redis capacity you provision. Ask your team for a monthly active user forecast for each project before comparing.
Bandwidth and storage allowances
Pro includes 2 TB of bandwidth and 150 GB of storage per project, so media-heavy apps reach these limits sooner than user-count limits. Self-hosted, bandwidth and storage become costs you pay directly: egress from your cloud or data center, and disks or object storage for uploads. Check the size of your largest file buckets and your average download volume, because these two numbers usually decide whether self-hosting saves money on storage-heavy workloads.
Freeze versus overage behavior
A Free project that hits a resource limit freezes with the Console in read-only mode, which can stop a live app. A Pro project keeps running and bills overage, with email alerts at 75% and 100% of limits and an optional organization budget cap. Self-hosted, there is no freeze or overage, but an outage or capacity shortfall becomes your operational problem. Decide which behavior your product can tolerate, and price the overage scenario against the cost of your own on-call time.
Required availability and failover
The Helm chart documentation states that the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without failover, so production data should move to managed services or operators. Managed HA databases, such as a PostgreSQL service with standby replicas, add recurring cost but shift failover and backup work to a provider. PostgreSQL itself does not detect primary failure, so automatic failover needs external tooling you must build or pay for. Ask which recovery time and recovery point your application needs before you choose.
Existing PostgreSQL and Docker skills
Appwrite 2.0 provisions PostgreSQL by default, and the installation guide uses Docker Compose, so a team that already runs PostgreSQL and containers spends less on learning and more on running. A team without those skills pays for training, outside help or a managed service. PostgreSQL's support policy gives each major version five years, so plan upgrades on a fixed schedule. Count the people who will carry pager duty, upgrades and backup restores, and compare that effort with the Cloud fee you avoid.
What you pay for on Cloud and what you pay for when you run it
Appwrite Cloud fees buy operation rather than software: the vendor runs the stack, keeps it patched, and provides backups and upgrades on the plan you choose. The Pro plan from $25 per month, according to the Appwrite pricing page, includes 2 TB of bandwidth, 150 GB of storage and 200K monthly active users per project, with daily backups. Usage beyond those allowances is billed as overage, so the recurring cost moves with traffic, storage and users, and you should ask for the overage rates in writing. Self-hosting removes per-usage billing from the Appwrite layer, but the buyer becomes the operator. You then pay for the servers or Kubernetes nodes, the object storage, the database, the backup target, the people who upgrade and patch Appwrite, and the on-call time when something fails. Those costs are partly one-time, such as migration and hardening, and partly recurring, such as infrastructure and staff time.
Appwrite 2.0 provisions PostgreSQL by default for new installs, with MariaDB and MongoDB also supported, so the database engine becomes a cost line you own directly. PostgreSQL is released under the PostgreSQL License, which carries no license fee, but its lifecycle is its own. The PostgreSQL versioning policy lists supported major versions 14 through 18, with 14 supported until November 12, 2026, and each major version supported for five years after release. Plan for a major upgrade within that window using pg_upgrade, a dump and restore, or logical replication, and confirm which PostgreSQL version your Appwrite release is tested against before you commit to a version. Use your own estimate of this work when comparing options, and ask any managed PostgreSQL provider for its backup, point-in-time recovery and replica pricing as separate line items.
How to build the Appwrite cost model with your own numbers
This sequence turns a vague comparison of Appwrite Cloud fees against self-hosting into a worksheet built from your own usage, your own vendor quotes and your own staffing assumptions. The result is a best case and worst case total you can take into a renewal or budget discussion.
Export current Cloud usage and plan details
The platform or finance owner pulls the current Appwrite Cloud plan, the project count, and the usage metrics the Console reports for each project, including bandwidth, storage, monthly active users, database size and function executions over the period you can access. Save the export with the date it was taken, because usage shifts month to month. The step is done when every project has one row with its plan and its consumption figures, and any metric you cannot export is listed as a gap to fill from the Console or the vendor.
Map each plan limit to a projected month
Place each measured usage figure beside the limit it counts against on the plan you are on, then project those figures forward using your own growth assumptions. Note which limits trigger a freeze on a Free project and which trigger overage charges and alerts on a Pro project, since those behaviors shape the cost when you cross a line. Confirm the current limits and overage terms on the Appwrite pricing page before you use them, because plan contents change. The step is done when each limit has a projected value for the months you are modeling and a note on what happens when it is exceeded.
Price each self-hosted component from written quotes
Build a line for each part of a self-hosted Appwrite estate: compute nodes, block and object storage, managed PostgreSQL or an operator, Redis, ClickHouse if you run it, backups, monitoring, load balancing and network egress. Request quotes from your cloud provider, your data center team or a managed database vendor, and ask each one for the same sizing so the lines compare. Appwrite's installation guide sets minimum host requirements, so use those only as a floor for sizing. The step is done when every component line carries a quoted or invoiced amount, and each figure names the quote it came from.
Separate one-time setup from recurring costs
Split the model into two columns. The one-time column holds the planning, installation, data migration, SDK endpoint changes, testing and cutover work, plus any hardening you need before go-live. The recurring column holds infrastructure, licenses or support contracts, backups, upgrades, on-call time and the share of platform engineering staff time that Appwrite will consume each month. Ask for the one-time figures as fixed-scope quotes where possible, and state whether each recurring line is fixed or variable with traffic. The step is done when every line sits in exactly one column and the recurring column has an owner.
Account for operations and upgrade effort
Estimate who runs the self-hosted stack and how much of their time it takes. Include routine Appwrite upgrades, which the 2.0 release notes describe as a single command plus a migration for existing 1.9.x installs, and the PostgreSQL minor and major upgrade cycle, which the PostgreSQL versioning policy governs. Also count the time for monitoring, incident response and restore testing. Because self-hosted Appwrite does not include vendor-managed high availability for its built-in datastores, decide whether you will pay for managed databases or operators, and price that choice explicitly. The step is done when staff hours or contract costs appear for each recurring task, and the owner has signed off on the on-call expectation.
Run best and worst case scenarios
Model at least two cases side by side. The best case uses your conservative user growth and assumes no availability incident that needs failover. The worst case uses fast user growth, a traffic spike, a storage jump and a database incident that requires restoring from backup. For each case, record how the Cloud plan cost changes, including overage, and how the self-hosted cost changes, including extra nodes or replicas. Label any scenario that is hypothetical so readers do not mistake it for your forecast. The step is done when both cases show a total cost per period for each option and the drivers that moved the numbers are listed.
Review the model with security and compliance owners
Share the worksheet with the security lead, the compliance owner and the platform owner before you decide. Ask them to confirm which costs are missing, such as audit preparation, log retention, key management or the controls you must document in your own environment. Note that DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so any assessment cost comes from an independent auditor you hire. The step is done when each reviewer has signed off on their lines and the open questions have named owners and a list of quotes still pending.
What the migration costs once and what it costs every month
The one-time cost of moving from Appwrite Cloud to self-hosted Appwrite is mostly engineering time spent on a target install, a project migration and client changes. Start by standing up the target: the installation guide asks for 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2 for a single node, but a production layout also needs a database, object storage and a load balancer that you size yourself. Next, use Appwrite Migrations to move projects, then re-point the SDK endpoint in each Web, Flutter, Apple, Android, React Native or Unity client. Check every function and storage bucket after the move, because function runtimes and file paths are the usual places where a migration breaks quietly. Confirm the exact migration scope with Appwrite before you commit.
Password hashes are the one-time item most likely to force a costly user reset. Appwrite's Users API accepts several imported hash types, including bcrypt, Argon2, Scrypt, Scrypt modified, MD5, PHPass and SHA, so check which algorithm and parameters your current users were stored with before you choose an import path. Test a few real accounts end to end in a staging install. Plan a reset flow only for users whose hash type cannot be imported, and budget that support work now, because it is the cost users notice.
The recurring cost is operations, and it does not stop after cutover. Appwrite releases often: 2.0 arrived on September 4, 2026 and 2.5.0 on October 13, 2026, and each upgrade needs a staging rehearsal, a backup taken immediately before, and a rollback plan. The Helm chart documentation says the built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without failover, so you also pay for managed databases or operators, their patching, and regular backup restore tests. Monitoring, alerting on disk, memory and queue depth, and an on-call rota are ongoing staffing decisions. Ask your team to estimate these hours per month, and ask any quote provider to itemize them separately from the one-time migration.
Questions buyers ask before they compare Appwrite Cloud costs
How does the cost of self-hosting Appwrite compare with the Appwrite Cloud Pro plan?
Self-hosting moves the cost from a monthly platform fee to the infrastructure and people who run it. The Pro plan is listed at $25 per month and includes 2 TB of bandwidth, 150 GB of storage and 200K monthly active users per project, according to Appwrite's pricing page, with overages billed beyond those limits. Your self-hosted costs depend on the servers or cloud instances you rent, the managed PostgreSQL or operator you choose, backup storage, monitoring, and the engineering hours to install, upgrade and patch the stack. Ask Appwrite which Cloud features and limits you would need at your user and data volume, then price each self-hosted component against them.
How long does it take to move from Appwrite Cloud to a self-hosted install?
The timeline depends on project size, the number of Functions and storage buckets, how many SDK clients point at the Cloud endpoint, and how much of the target environment you prepare first. Appwrite's Migrations feature can transfer complete projects, so much of the effort is in preparing the target install, testing the migration, re-pointing client SDK endpoints and checking functions and storage. No migration duration is supplied for this comparison, so ask Appwrite and your delivery partner to confirm timing against a copy of your own project before you commit to a date.
Can our team run self-hosted Appwrite without outside help?
A team with container orchestration experience can install Appwrite with the Docker Compose path or the official Helm chart, but running it in production needs more than the first install. Appwrite's installation guide asks for 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2 at minimum. The skills that matter most are PostgreSQL administration, backup and restore testing, TLS and secret handling, monitoring, and upgrade planning across Appwrite releases such as 2.0 and 2.5.0. If those skills are thin in-house, decide early whether you will train staff or buy support through a retainer or fixed-scope engagement.
What ongoing work does a self-hosted Appwrite install require?
Ongoing work is the recurring part of the cost. Appwrite has been releasing often, with 2.0 on September 4, 2026 and 2.5.0 on October 13, 2026, so the team must schedule upgrades, test them against Functions and client SDKs, and keep a rollback path. You also own backups, restore tests, certificate renewal, capacity planning, log retention and security patching of the host and containers. Ask whether your team or an external provider will cover these tasks each month and how incidents outside business hours are handled.
Does managed PostgreSQL or an operator change the self-hosting math?
Yes, it is often the largest single change to the total cost. Appwrite's Helm chart documentation says 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. PostgreSQL supports hot standby and synchronous or asynchronous replication, but it does not detect a primary failure on its own, so automatic failover needs external tools. A managed database adds a recurring service fee in exchange for backups, failover and patching, while an operator shifts that work to your team. Compare both options with the replica count and recovery objectives you need.
What should we ask for in a quote for self-hosted Appwrite?
Ask for a written scope that lists each component to be installed or configured, the target environment, the migration steps, the data volumes covered and the acceptance tests. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts, and it offers ongoing support and upgrades as retainers. Ask for the one-time items and the recurring items separately, the assumptions about Appwrite version and database engine, what is excluded such as hosting or licenses, and who handles backups, upgrades and incident response after handover. DeployOpen does not publish a price list, so the quote follows from that written scope.
What do Appwrite Cloud free-plan limits mean for a decision to self-host?
On the Free plan, a project that reaches a resource limit freezes with the Console in read-only mode, while Pro projects keep running with overage charges and email alerts at 75% and 100% of limits. This matters for planning because an app that outgrows the Free plan will need either a paid plan or your own infrastructure. The Free plan is listed at $0 with up to 2 projects, a pause after 1 week of inactivity and 75K monthly active users. Before choosing, model your expected growth against those limits and the Pro overage terms, and confirm current terms with Appwrite.
When self-hosting Appwrite costs less and when it costs more
Self-hosting Appwrite tends to cost less when your usage is steady and high, when you already run container platforms and database operations, or when data residency rules require the backend to stay in your own accounts or data centers. In those cases you pay for servers, storage, bandwidth and managed or operated PostgreSQL, and you avoid the per-project limits and overage model that Appwrite Cloud applies. The Pro plan starts at $25 per month according to the Appwrite pricing page, so the break-even point depends on how many projects, monthly active users and how much bandwidth and storage you expect. Ask your team to model those figures against your own traffic before comparing invoices, and include the engineering hours for upgrades and monitoring as a recurring cost.
Appwrite Cloud tends to cost less in total for small apps and for teams without spare platform engineers. The Cloud plans bundle backups, scaling, upgrades and vendor support into one subscription, and a Pro project keeps running with overage charges and email alerts at 75% and 100% of limits, which gives a predictable warning path. The main self-hosting trap is the default topology. The built-in PostgreSQL, Redis, ClickHouse and object storage each run as a single replica without failover, so a production install needs managed services or operators, and that adds monthly infrastructure cost and integration work. Confirm with Appwrite what support terms apply to your self-hosted deployment, because the self-hosting documentation does not replace a contract.
Before you decide, list the components you would own: the Appwrite containers, the PostgreSQL primary and standby, backups and point-in-time recovery, certificate and secret management, and the upgrade path across Appwrite releases such as 2.0 and 2.5.0. Unlike Supabase and PocketBase, where self-hosted support is community-driven, you should confirm in writing what Appwrite will support on your own infrastructure. If your evaluation shows that HA, backups and on-call coverage would have to be built from scratch, the cost of self-hosting usually rises above the cost of the hosted plan for all but the highest and most regulated workloads.
How DeployOpen scopes a fixed-price Appwrite cost and implementation review
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Appwrite Cloud cost versus self-hosted Appwrite, we start with a written scope that prices each component of your current bill and your self-hosted alternative, so the comparison rests on your numbers rather than assumptions.
How we scope
- Inventory your current Appwrite Cloud plan, overage history, database tier and backup settings before estimating anything.
- Define which self-hosted components are in scope, such as hosts, PostgreSQL, Redis, storage, backups and failover.
- Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
How we build
- Build a side-by-side cost model listing each component, who is paid for it and whether it is one-time or recurring.
- Deploy a reference Appwrite installation in your environment and test backups, restores and upgrade steps against it.
- Document the operating effort your team would carry, including on-call duties, patching and monitoring, so gaps are visible.
How we hand over
- Deliver the cost model with its assumptions, sensitivities and the inputs you should replace with your own figures.
- Provide runbooks for install, upgrade, backup restore and PostgreSQL major version upgrades, written for your staff.
- Give a clear list of what the self-hosted setup does not cover, such as compliance attestations, which independent auditors issue.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants help after handover.
- Schedule periodic reviews of Appwrite release notes and PostgreSQL support windows that affect your running cost.
- Confirm with us in writing which vendor-specific features you still need, so the retainer scope matches your environment.
