Appwrite Sites and the BaaS Land Grab: When Your Backend Vendor Wants to Host Your App Too

Appwrite spent a decade being the thing that sat behind your app: a self-hostable, open-source alternative to Firebase covering auth, databases, storage, and serverless Functions. In May 2025 it crossed the line that used to separate backend vendors from hosting platforms — it shipped Appwrite Sites, pitched bluntly as "the open source Vercel alternative." And with the 1.9.5 release for self-hosted deployments on June 30, 2026, it filled in the unglamorous plumbing that separates a demo feature from a production deploy pipeline: Git deployment triggers with branch and path filters, Rust as a first-class Functions runtime, and per-Site build-runtime switching between Bun and Deno.

Here's the short version of what that means, before the detail: letting your BaaS host your app is a genuine convenience win — for a single-project team, one console holding your auth, your data, and your git-push deploys removes real moving parts. The price is that your deploy pipeline is now owned by your database vendor: its framework list, its runtime matrix, its upgrade path.

And the ceiling is structural, not cosmetic. Self-hosted Appwrite is a single-project-scoped Docker Compose stack, and the moment a team's app outgrows one box (or one project), the things it suddenly needs — multi-node scheduling, tenant isolation, a failure domain smaller than "the server" — are exactly the things a Compose stack cannot grow into. That crossover point, not brand loyalty, is where the PaaS layer actually sits.

What Appwrite actually shipped​

It's tempting to file "BaaS adds hosting" under checkbox features. The specifics say otherwise — this is a real deploy pipeline.

Sites, at launch (May 2025):

• Static and server-side-rendered hosting, with framework presets for Next.js, Nuxt, SvelteKit, React, and Astro — not just a static file bucket
• Deploy by connecting a GitHub repo: pick the framework, confirm install/build commands, add environment variables, and every push to the selected branch builds and deploys
• Pull requests automatically get preview deployments — the Vercel workflow, reproduced
• A global CDN and DDoS protection in front of hosted sites
• The whole thing ships inside the open-source Appwrite server, so self-hosters get Sites too, not just cloud customers

1.9.5, for self-hosted (June 30, 2026): this is the release that turns "we deploy on push" into "we control what deploys when," which is the actual job of a CI/CD layer:

• Branch filters — deploy production from main, staging from staging, previews from preview/**, each Site or Function subscribing to its own pattern
• Path filters — in a monorepo, apps/web/** changes rebuild the web Site only; functions/api/** changes rebuild the API Function only; a ! prefix excludes matching branches or paths outright
• Skip-deployment commit patterns — docs-only commits stop triggering builds
• Rust as a first-class Functions runtime, aimed at performance-sensitive work like webhook verification and image processing
• Per-Site build runtimes — switch an individual Site's build between Bun and Deno
• Build caching via node_modules cache keys, plus parallel chunk uploads for deployment reliability

Branch and path filters with exclusion patterns are not a feature you add for a demo. They're a feature you add because real teams with real monorepos are using the thing in anger. Appwrite is serious about owning the git push.

Why every backend vendor is climbing the stack​

Appwrite isn't acting alone; it's following a gradient every platform vendor feels. Google gave Firebase its own App Hosting for full-stack frameworks and, with Data Connect, a managed PostgreSQL offering — a BaaS reaching both up into hosting and sideways into relational data. Vercel, meanwhile, has spent the last two years moving down the stack from hosting into storage and databases through its marketplace. The layers are converging from both directions, and the meeting point is always the same: the git push.

The reason is simple: whoever owns the deploy owns the defaults. If your app deploys through Appwrite, then Appwrite Auth is one toggle away, Appwrite Databases is the path of least resistance, and every adjacent product the vendor ships inherits a distribution channel. The deploy pipeline isn't a feature — it's the control point from which everything else gets cross-sold. That's precisely why a backend vendor will spend engineering effort on branch-filter syntax: not because hosting is lucrative, but because not owning the push means someone else (Vercel, a PaaS, your CI system) owns the defaults instead.

Once you see the git push as the control point, "should my BaaS host my app?" stops being a feature-comparison question and becomes an ownership question.

The real trade: one platform vs. deploy ownership​

Be fair to the convenience case, because it's real:

• One console, one auth boundary, one billing relationship. For a solo developer or a two-person team running one product, "the database and the app on one self-hosted platform" collapses three vendor relationships into one docker compose up.
• Data next to the app. Functions and Sites talk to Appwrite's database, auth, and storage over the internal network with SDKs designed for exactly that pairing. No CORS gymnastics, no cross-cloud egress on every query.
• Fewer moving parts. No separate CI config, no webhook wiring between a git host, a build system, and a runtime. The 1.9.5 trigger filters replace a chunk of what teams otherwise write in GitHub Actions YAML.

Now the cost, stated concretely rather than as vibes:

• The vendor's framework list is your build pipeline. Sites supports the frameworks Appwrite ships presets for and the build runtimes it offers (Bun or Deno, as of 1.9.5). Your Rails app, your Phoenix app, your plain Dockerfile — those aren't Sites workloads. A platform whose job is hosting detects a runtime from whatever repo you push; a platform whose job is backend hosts the app shapes that showcase its backend.
• The upgrade path is coupled. When your deploy pipeline lives inside your BaaS, the BaaS's migration bugs are your deploy pipeline's outages. This isn't hypothetical: self-hosters upgrading to 1.9.5 hit a migration that left the functions schema half-migrated — the providerBranches and providerPaths columns (the very fields the new trigger filters depend on) missing even after re-running the migration. A database vendor's upgrade hiccup became a deploy-pipeline regression, because they're now the same system.
• Leaving costs double. If the app outgrows the platform but the data doesn't (or vice versa), you unwind a coupling you chose for convenience: rewrite deploy config and re-point SDKs, re-issue auth, and re-home data — where separated layers would have let you swap one without touching the other.

None of this makes the trade wrong. It makes it a trade — one that looks best exactly where Appwrite's marketing aims: one project, one team, one box.

Where the ceiling is: a single-project Compose stack vs. a scheduled fleet​

Self-hosted Appwrite is a Docker Compose deployment — and not a small one. The standard setup runs roughly 19 containers (including ClamAV for antivirus and Telegraf for metrics) and idles around 4 GB of RAM before your first user shows up. That's fine on a dedicated box. The structural question is what happens when one box stops being enough.

Appwrite's own scaling documentation is honest about the answer: the worker containers are stateless, so you can replicate them across machines behind a load balancer you provide, and externalize the database and Redis to infrastructure you manage. In other words — past one box, you become the scheduler. You decide which workers run where, you build the load balancing, you handle what happens when a node dies, and you do it per project, because an Appwrite stack is scoped to serve its own applications, not to be a general substrate for many teams' many apps.

Contrast that with what a Cluster API-managed fleet gives a self-hosted PaaS by construction:

• Multi-node scheduling — apps are placed across nodes by a scheduler, not by a human editing Compose files; capacity is fleet-wide, not box-by-box
• Tenant isolation — different teams' apps get real resource boundaries (namespaces, quotas, network policies), so one team's runaway build doesn't starve another team's production service
• A failure domain smaller than the platform — a node dying reschedules workloads; a single-box Compose stack dying takes auth, data, and every hosted site down together
• Declarative machine lifecycle — nodes themselves are created, upgraded, and replaced through the same reconciliation loop as the apps, instead of being hand-fed servers

The triggers for crossing this line are mundane and arrive earlier than teams expect: a second product, a second team, a batch workload that competes with the web tier, a compliance requirement to isolate a customer, or simply the first 3 a.m. single-node outage. None of those are solved by adding a replica of a stateless worker. They're solved by a layer whose entire job is scheduling and isolating workloads across machines — which is the layer a BaaS-with-Sites, by design, is not.

Where the PaaS layer actually sits​

The tidy old diagram — BaaS below, PaaS above, IaaS beneath everything — is gone. What remains is a competition for one event: the git push. And the market is settling into three homes for it:

1. A hosted platform (Vercel, or Appwrite Cloud with Sites) — maximum convenience, someone else's machines, someone else's pricing curve.
2. A single-box self-hosted stack (self-hosted Appwrite, and the Coolify/Dokploy generation) — your machines, one project's blast radius, you are the scheduler when you outgrow it.
3. A fleet-grade self-hosted PaaS — your machines under an actual control plane, where multi-node scheduling, tenant isolation, and node lifecycle are the platform's job rather than your weekend's.

Appwrite Sites is a genuinely good move up the stack, and 1.9.5's trigger filters show the team understands what production deploy pipelines need. For one team with one project on one box, letting the backend host the app is a rational, even elegant, consolidation. But the question the title of "open source Vercel alternative" doesn't answer is the one that decides where your PaaS layer sits: how many apps, how many teams, how many boxes? The moment those numbers exceed one, the deploy layer wants to be a platform of its own — one that treats your backend as just another service it runs, not the other way around.

Backend vendors will keep climbing toward the push. Hosting vendors will keep digging toward the data. The durable position is owning the layer where those ambitions meet — on machines you control.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Cluster API-managed fleet underneath instead of a single Compose stack. Star the repo on GitHub or deploy your first app today.