diff --git a/.optimize-cache.json b/.optimize-cache.json
index a5ce059c89..7728bce7e9 100644
--- a/.optimize-cache.json
+++ b/.optimize-cache.json
@@ -393,6 +393,7 @@
   "static/images/blog/best-pagination-technique/graph2.png": "f255336a0b2352ab3665735cab0b0e7f8e0a4351c3fe020e793d3aa55a371394",
   "static/images/blog/best-postman-alternative-options/cover.png": "c55b7135fda0f895563b0c6b751b879e0639bd42ad8aab8540f7b6de5735ecf9",
   "static/images/blog/best-push-notification-strategies/cover.png": "18d7e0f8374ec092f1102180326600246bcd9c08ee0495f3d3adbe24f982e0f1",
+  "static/images/blog/best-self-hosted-backend-solutions-for-mobile-apps/cover.png": "d4e3b9d28d8685b136244ab6638b9467f5d5f3c999df936a42a053f58f2d2159",
   "static/images/blog/best-vibe-coding-tips/cover.png": "31a4e02feaf78b71b1c76f2be833dc80fe719bd6541721954ac0cf50b31b8b7d",
   "static/images/blog/best-vibe-coding-tools-for-beginners-in-2026/cover.png": "d80b4be2c2029b467b7483ff01e24060e7d8c39778bc00ca9bf65d20d6a20e5f",
   "static/images/blog/Blog-cover-oss-journey.png": "0599716142966c9efc71769c4e3dfc4b3e8c0c7aa53eeff94a11dcd30e3bc245",
@@ -1073,6 +1074,7 @@
   "static/images/blog/secure-user-data-non-expert/cover.png": "763c1181c63cb099f1fc19da5044287690d9ce5d7c80005f368c36b650928b80",
   "static/images/blog/security-is-a-revolving-door/cover.png": "1c9bc30487829ceb8659da7920bcb9d90cea6201e9b1322bb0f6cdc68eba4627",
   "static/images/blog/security-update-regarding-the-axios-npm-incident/cover.png": "8f05bcaf2aad7786b043d17421f69fbe19f49b11c4c10a576898c2438076e130",
+  "static/images/blog/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/cover.png": "2f28092839e9c6d45e985e5daff90a453e0def85329f8950ef44ea9aadc7037a",
   "static/images/blog/self-hosted-vs-managed-backends-a-practical-comparison/cover.png": "9a819d76faf91a78fc6116b4202f08290d24a6002bcdd737dca2f85bd2546793",
   "static/images/blog/self-hosting-appwrite-with-coolify/add-appwrite.png": "b1efadc68d075357c32698569856f7cb106ddce6caf3b88e50698a1ef97e283a",
   "static/images/blog/self-hosting-appwrite-with-coolify/add-ssh-key-to-digitalocean.png": "0eb128b8cdfde988da008385254e1c49621e4b98072f3959267a32b5765df827",
@@ -1293,6 +1295,7 @@
   "static/images/blog/what-is-redis-a-complete-guide-for-developers/cover.png": "b7b87a372bbb99421c2ab6df37430da960728b5cf339f1803c432644154c764f",
   "static/images/blog/what-is-serverless-an-expert-guide-for-developers/cover.png": "fd88e32613ca877625cd69e0e38ba76c3c2cc73da05b789739928712bdd7b454",
   "static/images/blog/when-custom-backend-stops-being-worth-it/cover.png": "d03b13c4e8f3294823a7883cdae89ca18a4030b170c51f597bd139c9ca274793",
+  "static/images/blog/when-should-you-self-host-your-backend/cover.png": "94f2f81d9f9ff2e1c46e26dbec52118ddc73b7964339bf675e546518723738e7",
   "static/images/blog/why-ai-generated-apps-need-backend/cover.png": "8761878c13c51dd8a720a625606b89b93d9c56651aed636fa1b2bd346bd4fd82",
   "static/images/blog/why-developers-choose-appwrite-auth/cover.png": "f56c37ebfc25191e113b928ff3cf144563be740159e46d75a427bdafdd11214b",
   "static/images/blog/why-developers-leaving-nextjs-tanstack-start/cover.png": "4581dead0651adab3e28e50610efa900956a0d120f222d991c207a65fbd09f7c",
diff --git a/src/routes/blog/post/best-self-hosted-backend-solutions-for-mobile-apps/+page.markdoc b/src/routes/blog/post/best-self-hosted-backend-solutions-for-mobile-apps/+page.markdoc
new file mode 100644
index 0000000000..d6cf6fb023
--- /dev/null
+++ b/src/routes/blog/post/best-self-hosted-backend-solutions-for-mobile-apps/+page.markdoc
@@ -0,0 +1,158 @@
+---
+layout: post
+title: Best self-hosted backend solutions for mobile apps
+description: Compare the best self-hosted backend solutions for mobile apps based on features, scalability, and developer experience.
+date: 2026-08-03
+cover: /images/blog/best-self-hosted-backend-solutions-for-mobile-apps/cover.avif
+timeToRead: 5
+author: aditya-oberai
+category: comparisons
+featured: false
+unlisted: true
+---
+
+Most self-hosted backend platforms were designed for web apps first. That distinction stops being academic the moment you ship to the App Store, because mobile apps need things web apps don't: native SDKs for Swift and Kotlin, push notifications through APNs and FCM, offline behavior when the network drops, and API stability across app versions you can no longer control.
+
+That last point is the one teams underestimate. A web app updates when the user refreshes. A mobile app sits on devices running a build you shipped eight months ago, and your self-hosted backend has to keep serving it. Picking a platform without native mobile support means you end up writing the SDK layer, the push pipeline, and the token registration logic yourself.
+
+This post compares the self-hosted backend solutions that actually hold up for mobile, and how to choose between them.
+
+# Short answer: which self-hosted backend should you use for a mobile app?
+
+- **[Appwrite](/docs)** if you want native Flutter, Swift, Kotlin, and React Native SDKs plus built-in push notifications in one Docker deployment.
+- **[Supabase](https://supabase.com)** if Postgres and raw SQL are non-negotiable and you're comfortable wiring push notifications yourself.
+- **[PocketBase](https://pocketbase.io)** if you're a solo developer shipping a small app and want a single binary with near-zero operations.
+- **[Parse Platform](https://parseplatform.org)** if you need a battle-tested mobile SDK surface and are fine maintaining a Node.js and MongoDB stack.
+- **[Nhost](https://nhost.io)** if your team is already GraphQL-first and wants Hasura on Postgres.
+
+If you're still deciding whether to self-host at all, read [self-hosted vs managed backends](/blog/post/self-hosted-vs-managed-backends-a-practical-comparison) first. The rest of this post assumes you've made that call.
+
+# What a mobile app needs from a self-hosted backend
+
+Feature checklists for backend platforms tend to be written from a web perspective. Here is what actually determines whether a self-hosted backend works for a mobile app:
+
+| Requirement | Why it matters on mobile |
+| --- | --- |
+| Native mobile SDKs | REST works, but you'll hand-roll session persistence, token refresh, and file uploads on every platform |
+| Push notifications | APNs and FCM are the only delivery paths to iOS and Android, and both need device token management |
+| Offline behavior | Connectivity drops in elevators, tunnels, and rural areas. Your app still has to function |
+| Realtime updates | Chat, presence, and collaborative features need a persistent connection, not polling that drains battery |
+| OAuth and social login | Sign in with Apple is an App Store requirement if you offer any third-party login |
+| Backward-compatible APIs | Old app versions stay in production for months. Breaking changes strand users |
+| File storage with transforms | Serving full-resolution images to a phone wastes bandwidth and looks slow |
+
+A backend that handles the first two badly costs you weeks. A backend that handles the last one badly costs you app store reviews.
+
+# The best self-hosted backend solutions for mobile apps
+
+## Appwrite
+
+Appwrite is an open-source backend platform that covers [authentication](/docs/products/auth), [databases](/docs/products/databases), [file storage](/docs/products/storage), [serverless functions](/docs/products/functions), and [messaging](/docs/products/messaging) in a single deployment. It self-hosts on any Docker-compatible infrastructure and is BSD 3-Clause licensed, so there are no commercial-use restrictions or paid tiers on the server itself.
+
+For mobile specifically, Appwrite ships first-party SDKs for [Flutter](/docs/quick-starts/flutter), [Apple platforms](/docs/quick-starts/apple), [Android](/docs/quick-starts/android), and [React Native](/docs/quick-starts/react-native). Session handling, OAuth2 redirects, and file uploads are handled by the SDK rather than by your networking layer.
+
+Push notifications are part of the platform, not an add-on. [Appwrite Messaging](/docs/products/messaging/send-push-notifications) manages device targets and sends through [APNs](/docs/products/messaging/apns) and [FCM](/docs/products/messaging/fcm), with topics for broadcast and scheduling built in. Email and SMS run through the same API, so a single notification flow covers all three channels.
+
+**Self-hosting requirements:** Docker, 2 CPU cores, 4GB RAM, and 2GB swap for a baseline instance, per the [installation guide](/docs/advanced/self-hosting/installation).
+
+**Best for:** Teams that want the full mobile backend surface, including push, without assembling it from separate services.
+
+**Trade-off:** The database is SQL-backed but accessed through a REST or GraphQL API rather than direct SQL. If your team wants to write raw queries and run `psql` against production, that's a real constraint.
+
+## Supabase
+
+Supabase is an open-source Firebase alternative built on Postgres, with auth, storage, realtime subscriptions, and edge functions. It offers official mobile SDKs for Flutter, Swift, and Kotlin Multiplatform, and Row Level Security gives you a clean way to express per-user data access rules directly in the database.
+
+The gap for mobile is push notifications. Supabase doesn't deliver them, so you connect FCM, APNs, or a third-party service like OneSignal and trigger sends from an edge function or database webhook. That's a solvable problem, but it's a component you build, monitor, and debug yourself.
+
+Self-hosting Supabase means running a multi-container stack: Postgres, GoTrue, PostgREST, Realtime, Storage, Kong, and Studio. It's documented, but it's meaningfully more operational surface than a single Compose file.
+
+**Best for:** Teams with Postgres expertise and complex relational query patterns.
+
+**Trade-off:** Higher self-hosting complexity, and push notifications are your responsibility.
+
+## PocketBase
+
+PocketBase is a single Go executable with an embedded SQLite database, auth, file storage, and realtime over server-sent events. Operationally it's the simplest option here: one binary, one data directory, no external dependencies.
+
+Mobile support is functional but thin. There are official JavaScript and Dart SDKs, so Flutter and React Native are covered, but native Swift and Kotlin clients come from the community. There's no built-in push notification pipeline.
+
+SQLite also sets the scaling ceiling. It runs on one machine, which is fine for a lot of apps and a hard stop for others.
+
+**Best for:** Solo developers and small apps where operational simplicity outweighs feature breadth.
+
+**Trade-off:** No push notifications, no horizontal scaling, and limited native SDK coverage.
+
+## Parse Platform
+
+Parse Server is the open-source continuation of the original Parse backend, maintained by the community since Facebook shut down the hosted service in 2017. Its mobile SDK coverage is the most mature of any platform on this list, with long-standing iOS, Android, and Flutter clients, and push notification support has been part of the product since the beginning.
+
+The cost is the stack you inherit. Parse Server runs on Node.js with MongoDB or Postgres, and you assemble the dashboard, file adapter, and push configuration yourself. It's a set of components with a shared history rather than an integrated platform.
+
+**Best for:** Teams migrating legacy Parse apps, or teams that value proven mobile SDKs above all else.
+
+**Trade-off:** Community-driven roadmap and more assembly required than a modern all-in-one platform.
+
+## Nhost
+
+Nhost pairs Postgres with Hasura's GraphQL engine, adding auth, storage, and serverless functions. If your mobile team already writes GraphQL and uses a client like Ferry or Apollo, the data layer feels natural, and subscriptions come free with the GraphQL model.
+
+SDK coverage is JavaScript and Dart. Native iOS and Android apps talk to Nhost through a standard GraphQL client rather than a first-party SDK, which means auth and storage integration is more manual. Push notifications, as with Supabase, are external.
+
+**Best for:** GraphQL-first teams comfortable operating Hasura.
+
+**Trade-off:** No native Swift or Kotlin SDK, and no built-in push.
+
+# Self-hosted mobile backend comparison
+
+| | Appwrite | Supabase | PocketBase | Parse Platform | Nhost |
+| --- | --- | --- | --- | --- | --- |
+| **Flutter SDK** | Official | Official | Official (Dart) | Official | Official (Dart) |
+| **Swift SDK** | Official | Official | Community | Official | GraphQL client |
+| **Kotlin SDK** | Official | Official (KMP) | Community | Official | GraphQL client |
+| **React Native** | Official | Official | Official (JS) | Official (JS) | Official (JS) |
+| **Push notifications** | Built in (APNs, FCM) | External | External | Built in | External |
+| **Realtime** | WebSockets | WebSockets | Server-sent events | LiveQuery | GraphQL subscriptions |
+| **Database** | SQL-backed (API) | Postgres | SQLite | MongoDB or Postgres | Postgres (GraphQL) |
+| **Offline sync** | Via integration | Community libraries | Community libraries | Local datastore | Community libraries |
+| **Self-hosting** | Docker Compose | Multi-container | Single binary | Node.js + database | Docker Compose |
+| **License** | BSD 3-Clause | Apache 2.0 | MIT | BSD-style | MIT |
+
+# How to choose a self-hosted backend for your mobile app
+
+Work through these in order. The first hard constraint you hit usually decides it:
+
+1. **Do you need push notifications on day one?** If yes, Appwrite and Parse are the only options that don't require building the delivery pipeline yourself. Push is where most mobile backend timelines slip.
+2. **Is Postgres and raw SQL a hard requirement?** Then it's Supabase or Nhost, and you accept the extra operational and push-integration work.
+3. **Do you have native iOS and Android apps, not just Flutter or React Native?** Weight first-party Swift and Kotlin SDKs heavily. Talking to a GraphQL endpoint from Swift is fine until you're implementing token refresh and multipart uploads by hand.
+4. **Who operates the infrastructure?** No DevOps capacity points to a single binary or a single Compose file. A multi-container stack needs someone who owns it.
+5. **What happens if you outgrow it?** Check for a managed option with identical APIs, and check whether the license permits your commercial use at scale.
+
+Then prototype. Ship auth, one read and write path, and one push notification on your top two finalists before committing your data model. Push is the step that exposes the difference between platforms fastest.
+
+# Self-hosting realities specific to mobile
+
+Two operational details matter more for mobile than for web.
+
+**API versioning is not optional.** Your users decide when to update. A breaking API change strands every device running an older build, and you can't hotfix a shipped binary. Pin your backend version, read the release notes before upgrading, and treat your API contract as something older clients still depend on.
+
+**Push credentials are infrastructure.** APNs keys and FCM service accounts expire, rotate, and break silently. A self-hosted backend means you own that rotation. Put it in your runbook alongside TLS certificate renewal and database backups, and cover it in your [production checklist](/docs/advanced/self-hosting/production).
+
+Beyond that, the usual self-hosting responsibilities apply: TLS, backups, monitoring, and patching. For a lighter path, [self-hosting Appwrite with Coolify](/blog/post/self-hosting-appwrite-with-coolify) handles a lot of that scaffolding for you.
+
+# Getting started with self-hosted Appwrite for your mobile app
+
+If you want native mobile SDKs and push notifications without stitching services together, Appwrite is the shortest path. It self-hosts on a single Docker Compose file, and [Appwrite Cloud](https://cloud.appwrite.io) runs the same APIs, so you can start managed and move to your own infrastructure later without rewriting your app. If you're coming from Firebase, [Appwrite Migrations](/docs/advanced/migrations/firebase) transfers users, databases, and storage files directly.
+
+# Resources
+
+- [Self-hosting Appwrite](/docs/advanced/self-hosting)
+- [Appwrite installation guide](/docs/advanced/self-hosting/installation)
+- [Send push notifications with Appwrite Messaging](/docs/products/messaging/send-push-notifications)
+- [Flutter quick start](/docs/quick-starts/flutter)
+- [Apple quick start](/docs/quick-starts/apple)
+- [Android quick start](/docs/quick-starts/android)
+- [Offline sync for Appwrite Databases](/docs/products/databases/offline)
+- [Open-source alternatives to proprietary BaaS tools](/blog/post/open-source-baas-alternatives)
+- [Migrate your Firebase project to Appwrite](/blog/post/migrate-firebase-projects-to-appwrite)
+- [Join the Appwrite Discord community](https://appwrite.io/discord)
diff --git a/src/routes/blog/post/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/+page.markdoc b/src/routes/blog/post/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/+page.markdoc
new file mode 100644
index 0000000000..87825dfadf
--- /dev/null
+++ b/src/routes/blog/post/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/+page.markdoc
@@ -0,0 +1,169 @@
+---
+layout: post
+title: "Self-hosted backend vs cloud backend: Which is better for developers?"
+description: Compare self-hosted and cloud backends across cost, control, scalability, and security.
+date: 2026-08-03
+cover: /images/blog/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/cover.avif
+timeToRead: 5
+author: aditya-oberai
+category: comparisons
+featured: false
+unlisted: true
+---
+
+Most teams pick between a self-hosted backend and a cloud backend for the wrong reason: the monthly bill. A $20 VPS looks cheaper than a managed platform, so self-hosting wins on the spreadsheet. Then someone spends a weekend restoring a database after a failed upgrade, and the spreadsheet turns out to have been measuring the wrong thing.
+
+The real comparison is not compute price. It is who owns the operational surface of your backend, and what that ownership costs in engineering hours, incident risk, and shipping speed. This post breaks the decision down across cost, control, scalability, security, and compliance, and gives you a framework you can apply to your own project today.
+
+# Self-hosted backend vs cloud backend: the short answer
+
+**A cloud backend is better for most developers most of the time.** It removes provisioning, patching, scaling, and backup work so your team spends its hours on product. **A self-hosted backend is better when you have a hard requirement that a managed platform cannot satisfy**, most commonly data residency, regulatory control, deep infrastructure customization, or per-request economics that break down at very high volume.
+
+Here is the difference at a glance:
+
+| Dimension | Self-hosted backend | Cloud backend |
+| --- | --- | --- |
+| Infrastructure ownership | Your team | Provider |
+| Time to first deploy | Hours to days | Minutes |
+| Security patching | You schedule and test it | Applied for you |
+| Scaling | You design and tune it | Built in |
+| Backups and disaster recovery | You configure and test restores | Provider-managed |
+| On-call burden | Yours | Provider's |
+| Data residency control | Complete | Limited to provider regions |
+| Cost shape | Fixed infrastructure plus engineering time | Usage-based, no ops headcount |
+| Customization | Full, including source-level changes | Limited to platform features |
+| Predictable failure mode | Ops debt | Bill growth at scale |
+
+If nothing in the self-hosted column is a requirement for you, choose the cloud backend and revisit the decision when something changes.
+
+# What a self-hosted backend actually involves
+
+Self-hosting means your team runs the backend. Not just the initial `docker compose up`, but everything after it. The recurring work includes:
+
+- Provisioning and sizing servers or containers
+- Managing the database, including migrations, connection limits, and tuning
+- Configuring object storage and CDN delivery for files
+- Setting up TLS, DNS, and reverse proxying
+- Monitoring uptime, latency, and disk pressure, plus alerting on all three
+- Applying security patches to the platform and the host OS
+- Running backups and, critically, testing restores
+- Responding to incidents at whatever hour they happen
+
+The first item takes an afternoon. The rest never finishes. That is the honest framing of self-hosting: you are trading a recurring bill for a recurring commitment.
+
+To be fair, this work is meaningfully easier than it was five years ago. [Docker Compose](https://docs.docker.com/compose/) and [Kubernetes](https://kubernetes.io/) have made deployment reproducible, managed Postgres and object storage are available from every major provider, and modern open-source backends ship sensible defaults. A single engineer who knows their way around containers can run a production self-hosted backend. The question is whether that is the highest-value use of their week.
+
+# What a cloud backend actually covers
+
+A cloud backend hands the operational surface to the provider. You get an endpoint, an API key, and SDKs. Provisioning, scaling rules, failover, patch cycles, and backups are the provider's problem, usually backed by an SLA and a dedicated operations team.
+
+What you give up is control at the edges. You get the features the platform supports, in the regions it operates, under the limits it enforces. When you need a specific database index type, a custom authentication flow, or a compute runtime the platform does not offer, you either work around it or wait for the roadmap.
+
+For most teams building a product rather than a platform, that is an easy trade. The features you actually need from a backend ([authentication](/docs/products/auth), [databases](/docs/products/databases), [file storage](/docs/products/storage), [serverless functions](/docs/products/functions), and [hosting](/docs/products/sites)) are exactly the ones managed platforms have standardized.
+
+# Cost: comparing self-hosted backend and cloud backend pricing
+
+This is where the decision most often goes wrong, so it is worth being precise. Self-hosted backend cost has two components, and teams routinely model only the first.
+
+**Infrastructure cost** is the visible one: compute, managed database, object storage, bandwidth, and backup storage. For a small production workload this can genuinely land under $100 a month, and it scales sub-linearly with traffic.
+
+**Engineering cost** is the invisible one:
+
+- Initial setup, hardening, and staging environment
+- Monitoring and observability tooling, plus the time to wire it up
+- Patch and upgrade cycles, including regression testing
+- On-call rotation coverage
+- Incident response and post-incident work
+- Security review and audit preparation
+
+Price a mid-level engineer's time honestly and even a few hours a week on backend operations exceeds most managed platform bills by a wide margin. That is the break-even nobody puts in the spreadsheet.
+
+Where self-hosting wins on cost is at the other end of the curve. Managed platforms typically price on monthly active users, API calls, reads and writes, or storage volume, and those metrics grow with your product. At high enough volume, per-request pricing crosses above the cost of running your own infrastructure plus a dedicated ops engineer. If you have modeled your usage trajectory and can see that crossover coming, self-hosting is a rational cost decision rather than a false economy.
+
+**The rule of thumb:** below the crossover, a cloud backend is cheaper in total cost of ownership. Above it, self-hosting is. Most teams never reach the crossover, and the ones that do usually reach it long after launch.
+
+# Control and customization
+
+Self-hosting is the only option that gives you source-level control. With an open-source backend you can read the code, patch behavior, add a custom OAuth provider, change a rate limit the platform hardcodes, or run it inside an air-gapped network. You can also pin a version and upgrade on your schedule instead of the provider's.
+
+Cloud backends give you configuration, not modification. That is usually sufficient, but "usually" is doing real work in that sentence. Before committing, list the specific things you need to change about your backend's behavior. If that list is empty, you do not need self-hosting for control. If it has three concrete items on it, you probably do.
+
+# Scalability: which model handles growth better
+
+Cloud backends scale by default. Capacity, replication, and failover are handled upstream, and you find out about a traffic spike from a dashboard rather than a pager.
+
+Self-hosted backends scale as well as you engineer them to. That means horizontal scaling of the API layer, read replicas or sharding for the database, a queue and worker topology that keeps up with your function invocations, and a CDN in front of file delivery. Appwrite documents this path in its [scaling guide](/docs/advanced/self-hosting/production/scaling), and the guidance is real work rather than a config flag.
+
+The distinction that matters:
+
+- **Cloud backend:** scaling is a solved problem you inherit
+- **Self-hosted backend:** scaling is a problem you own, and you can solve it in ways the platform never would
+
+Teams that need unusual scaling characteristics (a single tenant with enormous write volume, a workload pinned to specific hardware, a topology that spans on-prem and cloud) get real value from owning it. Teams with a normal growth curve do not.
+
+# Security and compliance
+
+Both models can be secure. They fail differently.
+
+A cloud backend gives you a provider that patches CVEs quickly, runs security teams, and holds certifications you would otherwise pursue yourself. Your remaining responsibility is application-level: permissions, session handling, and input validation. The [OWASP Top 10](https://owasp.org/www-project-top-ten/) is still yours to answer for.
+
+A self-hosted backend gives you complete control and complete responsibility. Every unpatched dependency, misconfigured firewall rule, and exposed admin console is yours. Appwrite's [production security checklist](/docs/advanced/self-hosting/production/security) covers the baseline, and following it is not optional.
+
+Compliance is where the decision often gets made for you. If you are subject to [GDPR](https://gdpr-info.eu/) data residency obligations, [HIPAA](https://www.hhs.gov/hipaa/index.html), or a customer contract that requires data to stay inside a specific jurisdiction or inside your own infrastructure, self-hosting answers that question definitively. Many cloud backends now offer regional deployments that satisfy residency requirements without self-hosting, so check the provider's [region coverage](/docs/products/network/regions) before assuming you need to run it yourself.
+
+Enterprise sales adds a related pressure. B2B buyers in regulated industries increasingly require the option to run your application in their own cloud account. If that is on your roadmap, a self-hostable backend is a product requirement, not an infrastructure preference.
+
+# When to choose a self-hosted backend
+
+Self-host when at least one of these is true:
+
+- Data residency or compliance requires operational control over where data lives
+- You need source-level customization the platform cannot provide
+- Enterprise customers require deployment into their own environment
+- You have modeled usage and per-request pricing crosses above your infrastructure plus ops cost
+- You already have DevOps capacity and mature incident processes
+- Avoiding vendor dependency is a stated, non-negotiable requirement
+
+# When to choose a cloud backend
+
+Choose managed when:
+
+- You are pre-launch or early-stage and shipping speed is the constraint
+- Your team has no dedicated DevOps capacity
+- Your compliance needs are met by the provider's regions and certifications
+- You want predictable operations rather than predictable infrastructure bills
+- Nobody on the team wants to own a pager for the database
+
+If you are between these lists, default to managed. The cost of switching later is lower than the cost of running infrastructure you did not need.
+
+# Why you should not have to choose permanently
+
+The worst version of this decision is one that locks you in. If you pick a proprietary cloud backend and later need to self-host for compliance, you rewrite. If you pick a self-hosted stack and later want to shed operations, you rewrite. Either way the platform choice, not the requirement, is what costs you the quarter.
+
+The way out is to pick a backend that supports both modes with the same APIs. [Appwrite](/) is open source under BSD 3-Clause and runs either way:
+
+- **Managed:** [Appwrite Cloud](https://cloud.appwrite.io) handles infrastructure, scaling, and patching. Free tier is sufficient for most early-stage apps, and [pricing](/pricing) scales with usage.
+- **Self-hosted:** [deploy Appwrite](/docs/advanced/self-hosting) on any Docker-compatible infrastructure, including your own data center or a customer's cloud account.
+
+The APIs, SDKs, and data models are identical across both. Moving from Cloud to self-hosted, or the reverse, does not change your application code. That turns a platform migration into an infrastructure change, which is a far smaller problem. If you are coming from a closed platform, the [Firebase migration guide](/blog/post/migrate-firebase-projects-to-appwrite) covers what that move actually looks like.
+
+# Choose based on requirements, not ideology
+
+Self-hosted backends offer control. Cloud backends offer velocity. Neither is universally better, and the teams that get this decision right are the ones who write down their actual requirements before comparing prices.
+
+If you have a compliance, customization, or scale requirement that demands ownership, self-host and budget for the operational work honestly. If you do not, use a cloud backend and put those hours into your product. And whichever you pick, pick a platform that lets you change your mind without a rewrite.
+
+# Getting started with Appwrite
+
+You can have a working backend on [Appwrite Cloud](https://cloud.appwrite.io) in a few minutes, with [Auth](/docs/products/auth), [Databases](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), and [Sites](/docs/products/sites) available from the same console. When your requirements change, the [self-hosting guide](/docs/advanced/self-hosting) gets the same stack running on your own infrastructure without touching your application code. Start where your team is today, not where you think you will be in two years.
+
+# Resources
+
+- [Appwrite Docs](/docs)
+- [Self-hosting Appwrite](/docs/advanced/self-hosting)
+- [Production checklist for self-hosted Appwrite](/docs/advanced/self-hosting/production)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite pricing](/pricing)
+- [Self-hosting Appwrite with Coolify](/blog/post/self-hosting-appwrite-with-coolify)
+- [BaaS vs custom backend](/blog/post/baas-vs-custom-backend)
+- [Join our Discord community](https://appwrite.io/discord)
diff --git a/src/routes/blog/post/when-should-you-self-host-your-backend/+page.markdoc b/src/routes/blog/post/when-should-you-self-host-your-backend/+page.markdoc
new file mode 100644
index 0000000000..c1f8d8e148
--- /dev/null
+++ b/src/routes/blog/post/when-should-you-self-host-your-backend/+page.markdoc
@@ -0,0 +1,172 @@
+---
+layout: post
+title: When should you self-host your backend?
+description: Learn when self-hosting your backend makes sense and when a managed cloud backend is the better choice.
+date: 2026-08-03
+cover: /images/blog/when-should-you-self-host-your-backend/cover.avif
+timeToRead: 5
+author: aditya-oberai
+category: self-hosting
+featured: false
+unlisted: true
+---
+
+Most teams decide whether to self-host their backend by looking at a pricing page. They see a metered line item, multiply it by an optimistic traffic projection, and conclude that running it themselves will be cheaper. Six months later they are tuning a Redis eviction policy on a Saturday instead of shipping features.
+
+The opposite mistake is just as common. A team with a hard data residency requirement or an on-premise customer contract stays on a managed platform because self-hosting feels like a step backwards, then spends months negotiating an exception they were never going to get.
+
+Self-hosting is not a philosophy. It is an operational trade: you take on infrastructure work in exchange for control. This post covers when that trade pays off, when it does not, and how to keep the decision reversible.
+
+# The short answer: when should you self-host your backend?
+
+**Self-host your backend when a requirement, not a preference, makes managed hosting unworkable.** In practice that comes down to four situations:
+
+- **Data residency or sovereignty.** Regulation or a customer contract requires data to stay in a specific country, region, or inside your own data center.
+- **On-premise or air-gapped deployment.** You ship your product into customer infrastructure that has restricted or no outbound internet access.
+- **Source-level customization.** You need to patch or extend the backend itself, not just configure it.
+- **Predictable, sustained scale.** Your traffic profile is steady and large enough that infrastructure you operate costs meaningfully less than metered hosting, and you already employ the people who can run it.
+
+If none of those apply, a managed cloud backend is the better default. That covers most teams, most of the time.
+
+# What self-hosting a backend actually involves
+
+The install is the easy part. Any modern open-source backend gets you running with a single Docker command. The work that follows is what teams underestimate:
+
+- **Provisioning and sizing.** Picking instance types, disk, and swap, then resizing when you get it wrong.
+- **TLS and DNS.** Certificate issuance, renewal, and the wildcard domains your functions and previews need.
+- **Backups you have actually restored.** An untested backup is a hypothesis, not a recovery plan.
+- **Upgrades and migrations.** Version bumps, schema migrations, and the maintenance windows around them.
+- **Monitoring and alerting.** Container health, disk pressure, queue depth, and someone whose phone rings when a threshold breaks.
+- **Scaling.** Replicating stateless workers, load balancing them, and clustering the stateful pieces like your database and cache.
+- **Third-party plumbing.** SMTP for transactional email, an SMS provider, an object storage backend, and the credentials for all of it.
+
+None of this is hard in isolation. Together it is a recurring commitment measured in engineer-days per month, and it never reaches zero. That cost is the entire subject of the decision.
+
+# Signs you should self-host your backend
+
+## Compliance and data residency are contractual, not aspirational
+
+If a customer contract, a sector regulation, or a public-sector tender specifies where data physically lives, self-hosting is often the only way to satisfy it cleanly. The [GDPR](https://gdpr-info.eu/) does not ban transfers outside the EU, but it does put the burden of proof on you, and enterprise buyers frequently write stricter residency terms into contracts than the law requires. Health data under [HIPAA](https://www.hhs.gov/hipaa/for-professionals/security/index.html) and payment data under [PCI DSS](https://www.pcisecuritystandards.org/) add their own controls on where and how data is processed.
+
+The useful test: can you name the clause and the counterparty? If yes, self-hosting is a requirement. If the answer is "our data feels sensitive," it is a preference, and a managed platform with published compliance attestations will usually serve you better than an instance you maintain yourself.
+
+## You ship into customer infrastructure
+
+Some products are delivered, not accessed. If your buyer installs your application inside their VPC, their factory network, or a facility with no outbound internet, a managed backend is not an option. Self-hosting is the product requirement.
+
+## You need to change the backend, not just configure it
+
+Configuration covers most needs: environment variables, custom SMTP, storage adapters, rate limits. Occasionally it does not. If you need to patch behavior in the backend itself, add an internal integration, or run a fork with a change your team maintains, you need the source and the ability to build and deploy it.
+
+This is a real reason, but it is rarer than teams assume. Before committing to a fork, check whether serverless functions and webhooks already cover the extension point you need.
+
+## Your scale is predictable and your team already runs infrastructure
+
+Metered pricing is efficient when usage is spiky and unpredictable, because you pay for what you use instead of what you provisioned. It becomes less efficient when load is flat and high, because you are paying a premium for elasticity you do not need.
+
+The condition that matters here is the second half of the sentence. If you already have an SRE function, an on-call rotation, and infrastructure-as-code in place, adding one more service is marginal work. If you do not, self-hosting means hiring or reassigning for it.
+
+## You need a local or ephemeral environment
+
+This is the least controversial reason to self-host, and it does not compete with managed hosting at all. Running the backend locally in Docker gives you a fast development loop, deterministic integration tests in CI, and a throwaway environment per branch. Plenty of teams self-host for development and run production on a managed platform.
+
+# Signs a managed cloud backend is the better choice
+
+## No one owns on-call
+
+Self-hosting creates a pager. If there is no rotation, the pager is one person, and that person becomes a single point of failure for your product's availability. Managed hosting converts that risk into a provider SLA.
+
+## Your growth curve is unknown
+
+Sizing infrastructure for traffic you cannot predict means over-provisioning or getting paged. Early-stage products in particular are better served by elasticity than by control, and by keeping the architecture as simple as the requirements allow. We wrote about this failure mode in more detail in [how to avoid backend overengineering in early-stage products](/blog/post/avoid-backend-overengineering).
+
+## Your differentiator is the product, not the platform
+
+Running a backend well is a genuine engineering skill, and it is almost never the thing your users pay you for. Pre-product-market-fit especially, the cost of infrastructure work is not the hours, it is the delayed feedback. Ship on managed hosting, learn what the product is, and revisit hosting once you have a load profile worth optimizing.
+
+# Self-hosted vs managed cloud backend: a side-by-side comparison
+
+| Dimension | Self-hosted backend | Managed cloud backend |
+|---|---|---|
+| Setup time | Hours to days, plus production hardening | Minutes |
+| Data location | Any region, VPC, or on-premise you choose | Provider regions |
+| Upgrades | You plan the window and run the migration | Handled by the provider |
+| Scaling | You size, replicate, and load balance | Automatic |
+| Backups | You configure, schedule, and test restores | Included, verify retention terms |
+| Incident response | Your on-call rotation | Provider SLA |
+| Cost shape | Fixed infrastructure plus engineer time | Metered, scales with usage |
+| Compliance | You own the full audit scope | Provider attestations plus your app |
+| Customization | Full source access | Configuration and extension points |
+| Best fit | Regulated, on-premise, or steady high scale | Most teams, especially small ones |
+
+# The cost of self-hosting, line by line
+
+The comparison people run is "server bill versus subscription." That comparison is wrong because it counts one column. Here is the fuller picture:
+
+| Cost line | Self-hosted | Managed cloud |
+|---|---|---|
+| Compute, storage, bandwidth | Your cloud or hardware bill | Included in plan and usage |
+| Initial setup and hardening | Engineer days | Near zero |
+| Upgrades and migrations | Recurring engineer time | Provider handles it |
+| Backup configuration and restore drills | Yours | Configure retention, verify |
+| Monitoring, logging, alerting stack | You install and maintain | Provider dashboards |
+| On-call coverage | Salary or opportunity cost | Provider SLA |
+| SMTP, SMS, object storage providers | Bring your own accounts | Often bundled |
+| Compliance evidence and audits | Full scope is yours | Shared with provider |
+
+A useful heuristic: self-hosting starts winning on pure cost when your monthly managed bill exceeds the fully loaded monthly cost of the engineer time you spend operating it. For a small team, that crossover point is higher than most people estimate, because a fraction of an engineer's month is expensive. For a team that already runs infrastructure, the marginal cost is small and the crossover arrives much sooner.
+
+Security cost does not disappear either way. It moves. Which layers you own versus which the platform owns is worth mapping explicitly, and we broke that down in [security responsibilities when using backend platforms](/blog/post/backend-platform-security-responsibilities).
+
+# A decision checklist for self-hosting your backend
+
+| If this is true | Then |
+|---|---|
+| A contract or regulation names a data location | Self-host, or use a provider with that exact region |
+| Customers install your product in their own network | Self-host |
+| You must patch the backend source | Self-host |
+| Load is flat, high, and you already run infrastructure | Self-host and measure the saving |
+| You need fast local dev and CI environments | Self-host for development, managed for production |
+| No one owns on-call | Managed |
+| Traffic is unpredictable or early-stage | Managed |
+| The reason is "self-hosting feels cheaper" | Managed, until you have real numbers |
+
+# Keep the self-hosting decision reversible
+
+The strongest position is not picking correctly on day one. It is picking a platform where the decision can change without a rewrite.
+
+That is the practical argument for building on an open-source backend rather than a proprietary one. If the same APIs, SDKs, and data model run in both places, hosting becomes a deployment detail instead of an architectural commitment. If they do not, switching means rewriting your data access layer, your auth flow, and your permission model. We covered that asymmetry in [Firebase vs open source: the trade-offs developers miss](/blog/post/firebase-vs-open-source-tradeoffs).
+
+Ask any candidate platform two questions before you commit. Can I run this on my own infrastructure if a compliance requirement lands next year? And if I start self-hosted, can I move to managed hosting without changing application code?
+
+# Self-hosting your backend with Appwrite
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes a backend server providing [authentication](/docs/products/auth), [databases](/docs/products/databases), [file storage](/docs/products/storage), [serverless functions](/docs/products/functions), real-time subscriptions, and [messaging](/docs/products/messaging), plus [Sites](/docs/products/sites) for deploying static and server-side rendered frontends. The same platform runs two ways, and the choice is yours rather than the vendor's.
+
+[Self-hosted Appwrite](/docs/advanced/self-hosting) runs on any operating system with a Docker CLI. The minimum footprint is 2 CPU cores, 4GB of RAM, and 2GB of swap, and the [installation](/docs/advanced/self-hosting/installation) is a single command that launches a setup wizard:
+
+```bash
+docker run -it --rm \
+    --publish 20080:20080 \
+    --volume /var/run/docker.sock:/var/run/docker.sock \
+    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
+    --entrypoint="install" \
+    appwrite/appwrite:1.9.6
+```
+
+Getting to production is the part worth planning for. The [production checklist](/docs/advanced/self-hosting/production) covers [security](/docs/advanced/self-hosting/production/security), [scaling](/docs/advanced/self-hosting/production/scaling), [rate limits](/docs/advanced/self-hosting/production/rate-limits), [backups](/docs/advanced/self-hosting/production/backups), and [updates](/docs/advanced/self-hosting/production/updates) explicitly rather than leaving them as exercises. One-click deployments exist for DigitalOcean, AWS Marketplace, and Akamai Compute, and there are guides for [Coolify](/docs/advanced/self-hosting/platforms/coolify) and [Dokploy](/docs/advanced/self-hosting/platforms/dokploy) if you want a PaaS layer over raw Docker Compose. For a full VPS walkthrough, see [self-hosting Appwrite with Coolify](/blog/post/self-hosting-appwrite-with-coolify).
+
+[Appwrite Cloud](https://cloud.appwrite.io) runs the same platform as a managed service, with the same APIs and SDKs. Because the surface is identical, your application code does not change when you move between them, and [migrations](/docs/advanced/migrations) exist for moving projects in either direction. Appwrite is also open source under the BSD 3-Clause license, so reading the code that handles your authentication and permissions is an option rather than a support request.
+
+To be fair about the trade-off: self-hosting Appwrite still means you own backups, upgrades, TLS renewal, and on-call. Appwrite makes the deployment portable, not the operational work optional.
+
+# Getting started with Appwrite self-hosting
+
+If your answer is self-hosting, start with the [installation guide](/docs/advanced/self-hosting/installation) and work through the [production checklist](/docs/advanced/self-hosting/production) before you point real traffic at it. If your answer is managed hosting, start on [Appwrite Cloud](https://cloud.appwrite.io) and keep self-hosting as the exit you never have to negotiate for.
+
+- [Appwrite self-hosting docs](/docs/advanced/self-hosting)
+- [Installation guide](/docs/advanced/self-hosting/installation)
+- [Production checklist](/docs/advanced/self-hosting/production)
+- [Environment variables reference](/docs/advanced/self-hosting/configuration/environment-variables)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Join the Appwrite Discord community](https://appwrite.io/discord)
diff --git a/static/images/blog/best-self-hosted-backend-solutions-for-mobile-apps/cover.avif b/static/images/blog/best-self-hosted-backend-solutions-for-mobile-apps/cover.avif
new file mode 100644
index 0000000000..22d9f0299c
Binary files /dev/null and b/static/images/blog/best-self-hosted-backend-solutions-for-mobile-apps/cover.avif differ
diff --git a/static/images/blog/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/cover.avif b/static/images/blog/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/cover.avif
new file mode 100644
index 0000000000..1b62c88778
Binary files /dev/null and b/static/images/blog/self-hosted-backend-vs-cloud-backend-which-is-better-for-developers/cover.avif differ
diff --git a/static/images/blog/when-should-you-self-host-your-backend/cover.avif b/static/images/blog/when-should-you-self-host-your-backend/cover.avif
new file mode 100644
index 0000000000..ed589b2240
Binary files /dev/null and b/static/images/blog/when-should-you-self-host-your-backend/cover.avif differ