diff --git a/.optimize-cache.json b/.optimize-cache.json index 1248473d60..b7b0842a84 100644 --- a/.optimize-cache.json +++ b/.optimize-cache.json @@ -146,6 +146,7 @@ "images/blog/adding-url-shortener/shortener.png": "170a82455ab8bc95ccfcccab0ce3bc7ae194caa79b03ff42a83ea7a921ed1306", "images/blog/adding-url-shortener/variables.png": "9e5135356992986e0c68f84b75da7f71990d882283693d80ef1461ab209b5a84", "images/blog/agency-backend-standardization/cover.png": "b0f24c2e12e820e8707b1b63dcf11f7181752cd47d4bd142c36bbd29c5018f3a", + "images/blog/agent-native-backend-platforms/cover.png": "441fab2ce0c04df6b6569db19d33bd1cd9051614ea1dd7045db87a55e45d19c0", "images/blog/agentic-ai-vs-generative-ai/cover.png": "fcda7c601879683cc380860c3a9403d8d6868cdc3bbf239cd74077f67df830aa", "images/blog/ai-announcement.png": "255c23234eb3bfa441ec1c15939e360afa2127b7172ee8addbdb6c55c14bea02", "images/blog/ai-crystal-ball/cover.png": "c0cb15a8bd1d0637447abf443145a8465f18b57493783187810bf6bd73eda272", @@ -278,7 +279,13 @@ "images/blog/appwrite-teams-roles/cover.png": "34f333eb8ec3ef92514f67d365850a2054e9c9990671f6647ea575533e2954d1", "images/blog/appwrite-vs-auth0-b2c/appwrite-vs-auth0-chart.png": "bba9245370213f15d1d2066260b22a07fccc054b2847596ad66f57bd968e2d63", "images/blog/appwrite-vs-auth0-b2c/cover.png": "97e405da84a457a567b552dea23f10e2e4cc5894e90c36d386efb414623a1d9e", + "images/blog/appwrite-vs-cloudflare-stateful-ai-agents/cover.png": "a24196757a99639dbc0c825b5be683107effbff5e85947fc15c5201c27258401", "images/blog/appwrite-vs-cloudinary/cover.png": "ce7d9211396f334c7d165458fe07ffa5fa124dd3e1441e8c993fd60126adb04c", + "images/blog/appwrite-vs-convex-ai-agents/cover.png": "78cf998ed3d4e52c68cae3422bee3ded600669e4c5afac0dace39ba647a78824", + "images/blog/appwrite-vs-firebase-ai-development/cover.png": "cd47646f739766371a25b179f85558218efc0d2f3d26d9ce32efc92f72226221", + "images/blog/appwrite-vs-neon-ai-backends/cover.png": "3398e51226eff72303b6b13199bda8a57ff81258d80163b05b1821e53d0959fd", + "images/blog/appwrite-vs-replit-agent-backend/cover.png": "acfecd8d097efb3f59abd867ebfaf5ef9dd757d1e0bda279db070f2116276431", + "images/blog/appwrite-vs-supabase-ai-apps/cover.png": "3f38661cc9041201ca3a5f6dfd58d912584f0c5887003d4b73795b232f7d4e04", "images/blog/appwrite-vs-vercel-vs-netlify/cover.png": "dbe40ef9cd2308555771129b95a6bfd7c7d6aa31fb88dab3a9071ad8a415284b", "images/blog/appwrite-webhooks/cover.png": "3dfed85fb2fbe79c894b9f3808ba95a9533d9c3307879582e1e84d842e3d620f", "images/blog/avif-in-storage/cover.png": "23c26ec1a8f23f5bf6c55b19407d0738aa41cdc502dc3eef14a78f430a14447b", @@ -292,6 +299,7 @@ "images/blog/baas-vs-custom-backend/messaging.png": "54a574317afa9ed22728aa3e10aa1ca1157a29bdfea61909a5260ca1f79d4f4f", "images/blog/baas-vs-custom-backend/storage.png": "6ed39797b1d5f67299c55b1be3944912860811564c38e849adb31a0d4a23ec46", "images/blog/baas.png": "e5353595cc9c6c8037a7b9b3a8ff25552cb39f61a120ecb867c63de46f14aa74", + "images/blog/backend-checklist-vibe-coded-apps/cover.png": "266738e6cc39ad295a0e0a2bc454c5c99770fdf80015b5bdc76cc0d61d8cd170", "images/blog/backend-for-claude-code-apps/cover.png": "d69e29230482959e7019ebce906ea32a3c69e7f9c0a7aa714914bc8d84b0ac4f", "images/blog/backend-mistakes-that-quietly-cost-small-teams-weeks/cover.png": "c804b93ac334b4224c612fc5c177469f30a6a6e548db1c93e90fb95b35544bda", "images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png": "234650617a90c69a898eb456ae2d807f3a1d0f627376ac6481074b24c1712196", @@ -300,6 +308,7 @@ "images/blog/backup-encryption/cover.png": "4a3b2f9f2acc75681669c1dcefa407455e6f7ee29f2dc04bd4e9cae5f9d646c9", "images/blog/badge.png": "2d1852c6f826d55c40cb848cc3813f25a4d3d982a6f56d2738c9e5b3d0ac9694", "images/blog/Behind_the_pull_request_Stories_from_contributors.png": "16d81aff97deaded8b03c33f4498d3bf6f8ec392fee8edff6dc273d0cafbd132", + "images/blog/best-backend-for-lovable-apps/cover.png": "579bcfe22908eee951880652a4075c0a26d34b661ab27e4f2c3708bdf717ceaf", "images/blog/best-free-static-website-hosting/cover.png": "022f31c5c5897d77ccfbfc2149ee81ed6f8a7bbaca91b5c3c09cd2b2e9432450", "images/blog/best-ios-android-app-development-platform/cover.png": "68aa7d27a6c8265fc254663fb470f4ae1a436a34b85a0c06faa0776fedcdb2b5", "images/blog/best-pagination-technique/cover.png": "6c1cdf54285c0c181eb08f888d924e64919113d7d2fa85b24c8b5a44bd47e52a", @@ -732,6 +741,7 @@ "images/blog/kcollect.png": "d044d69e18de7dd4af75213b7f4cf131529f43875352d7db86fe80c274466242", "images/blog/local-development-guide/localdev-cover.png": "07cce5e779991c560d2e8c58b280803ea8ebcfc8775bcc75e959d76b01409fa7", "images/blog/logo.png": "6df582f74767156f37ced895ebeb6b5a656858301dd09539cbc84157a6a54ed3", + "images/blog/lovable-appwrite-backend-pairing/cover.png": "fff78ea4f16953fda8c6e617448bfb0ddde26eb2f5891f9d35b2e53345eba677", "images/blog/majik-kids.png": "8710ac967fd8c60ee387a8f9ec75c27cd7eff25ab70d8ccbcb7ecc7ed7c73f72", "images/blog/make-best-use-appwrite-mcp/cover.png": "a1807e11b41f422028a161742aa5cd94e1e8192d87eab3c7e4f55ae9461f309f", "images/blog/make-best-use-appwrite-mcp/csv-created.png": "d5e4d5f352da6923748ceabb3e0657bb85c9212ca3f468bc0c676fdd84cf4f7c", @@ -799,6 +809,7 @@ "images/blog/offline-first-journal/cover.png": "be142679d30a9144f0623b78dfa2810048b46c5cbdea83d0e2d7f36d61233c5d", "images/blog/offline-first-journal/demo.png": "55e48ac98bc1d8f9add353b034c22c17cc158d951a31e7df4cb23a2e3d7efaf2", "images/blog/open-source-baas-alternatives/cover.png": "1ca9d44ab5faf6199fe782c5c833cd75d54acc7ad5cb18f46dea06b62abec5c4", + "images/blog/open-source-backend-for-ai-apps/cover.png": "c5007bf5f067f9eafbb792909ae3ec9b882a8bd5017d5c4b4fe6182599567c2c", "images/blog/open-source-backend-vs-managed-saas/cover.png": "5046fc4e3f3fa605c22d00ecb4b5156734c7d94000b49cae66a9e3bc49f81984", "images/blog/open-source-firebase-alternative/cover.png": "e0b98679795c00fd6d2d304b17273eaa6847bb1fc5706efa6cc3f3040ec6b4bb", "images/blog/open-source-regulated-environments/cover.png": "bbb57f0f8dc70f31923f34b5007f089a8539bdbca193c6f3a2594502bca551a2", @@ -1035,6 +1046,7 @@ "images/blog/state-of-computer-vision/kernel.png": "e17954c3cd0be5b67061d8989eaa8348cdd99bbc5d6ed4e3cf34d4d045ea08cc", "images/blog/state-of-natural-language-processing/cover.png": "a2884b41746777e3d1aebe5a36e63dd7d66237310237e23d95a21024dc1e249d", "images/blog/storage-previews-vs-ssr-image-optimization/cover.png": "f39343c285b729bbe56b88c1b41b6b9653d2b10a2a56ed137df80cc11b561ff3", + "images/blog/supabase-alternatives-lovable-projects/cover.png": "1ce2b47a11901ea6fe019d8cd41a3e19a4086e748e8d6a3447e3d16e59058bae", "images/blog/sveltekit-starter-sites/add-platform.png": "3b13ba983ea1d2529a1f34a719acef903ec0b58879ed511012280a28ccbde17e", "images/blog/sveltekit-starter-sites/congrats.png": "337bf14abd2050425541426b9f9b982b63e4fda79b66c7af4753587a5f71c877", "images/blog/sveltekit-starter-sites/cover.png": "444e99829fa6f1642a1fe497d10f09d6f00c8a553ea56287fe6644e33b8f3777", @@ -1136,12 +1148,14 @@ "images/blog/vibe-coding-security-best-practices/cover.png": "b0c69c03743fc542ff384da87d2cd733a85d1a057e654dc3bee1f572999a6500", "images/blog/webp-support-for-safari/cover.png": "ea4e965ffe21500f3552073bb7ca325d453020cf095d67164329edbda3f1c799", "images/blog/what-developers-actually-want-from-a-backend-platform/cover.png": "0c540d48b12cd7031e3cadaf4223086ded946b42dc283c641cfa024311b2ec36", + "images/blog/what-is-an-ai-backend/cover.png": "cb36f49035cbdcd97a70ac658783741f275d3a220b7cfd16b39d4fb86a929edd", "images/blog/what-is-cdn/cover.png": "ef77860288e150c6c22f3950a5eae4c88aefefb6db204f10c2a0544e51548703", "images/blog/what-is-ciam/cover.png": "45a5261ae1bb8a38777f60a21ea60426c0832e3d58bf3164100548400d388ce1", "images/blog/what-is-mcp/claude-mcp-chat.png": "26842cfebca3ec2cec89448e1c0d7ddb3f5421cc57acdb8780d48d30a54cad82", "images/blog/what-is-mcp/claude-mcp-tools.png": "3a5ae700867b8671b5c9e3af61b094aeb64611168463db66ff440e0d427ac6bc", "images/blog/what-is-mcp/cover.png": "dc4537990c91d6f1768c5ab8775e5c52239eb901b15e2e74fce8b5a018855c32", "images/blog/when-custom-backend-stops-being-worth-it/cover.png": "d03b13c4e8f3294823a7883cdae89ca18a4030b170c51f597bd139c9ca274793", + "images/blog/why-ai-generated-apps-need-backend/cover.png": "8761878c13c51dd8a720a625606b89b93d9c56651aed636fa1b2bd346bd4fd82", "images/blog/why-developers-choose-appwrite-auth/cover.png": "f56c37ebfc25191e113b928ff3cf144563be740159e46d75a427bdafdd11214b", "images/blog/why-developers-leaving-nextjs-tanstack-start/cover.png": "4581dead0651adab3e28e50610efa900956a0d120f222d991c207a65fbd09f7c", "images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png": "52a9dde70eeefcd7e489305fc30d2d6f6a63142c5bb00ee027a81454eaef4676", diff --git a/src/routes/blog/post/agent-native-backend-platforms/+page.markdoc b/src/routes/blog/post/agent-native-backend-platforms/+page.markdoc new file mode 100644 index 0000000000..bb36d22600 --- /dev/null +++ b/src/routes/blog/post/agent-native-backend-platforms/+page.markdoc @@ -0,0 +1,118 @@ +--- +layout: post +title: "The rise of agent-native backend platforms" +description: "Agent-native backend platforms let AI coding agents inspect, provision, and operate backend resources through MCP, structured APIs, and agent skills." +date: 2026-04-24 +cover: /images/blog/agent-native-backend-platforms/cover.png +timeToRead: 9 +author: aishwari +unlisted: true +category: ai +--- + +Something quiet has shifted in how backends get built. For most of the last decade, a backend platform was evaluated by how easy it was for a human developer to click through a console, read the docs, and wire up an SDK. That is still true, but a second audience has arrived. AI coding agents in Cursor, Claude Code, Windsurf, Antigravity, Lovable, Bolt, and Replit now read your docs, call your APIs, and write the code that ships to production. + +The platforms that win the next cycle will be the ones an agent can pick up on its own. That is the core idea behind the agent native backend: a platform where agents can inspect, provision, and operate backend resources through MCP servers, structured APIs, and agent skills, not just through a human sitting in front of a dashboard. This post walks through what an ai agent backend platform looks like today, where Appwrite fits, and how other platforms are positioning against the category. + +# What agent-native means + +"Agent-native" gets used loosely, so it is worth tightening. A backend platform is agent-native when at least four things are true: + +- **An agent can act on your project.** Not just read blog posts about it. The platform exposes its control plane through MCP or a similar tool-calling protocol, so an agent can create projects, tables, columns, rows, buckets, functions, sites, and users with structured inputs rather than synthesized HTTP requests. +- **An agent can read the docs at call time.** Training cutoffs are always behind. A docs MCP, or something equivalent, lets an agent fetch current reference material when it is about to generate SDK code, instead of hallucinating a method name from six months ago. +- **The SDKs and APIs are shaped to be reasoned about.** Clear primitives, stable endpoints, typed responses, and documented permissions all matter more when the consumer is a language model that has to plan several tool calls in advance. +- **There is a safe path for agents to operate in production.** Scoped API keys, role-based permissions, environment separation, and audit trails let an agent manage infrastructure without giving it a master key to every project. + +Those four traits are what separates an agent-native backend from a backend that happens to have an AI blog post. The rest of this piece uses that definition when comparing platforms. + +# Why the category is forming now + +Three pressures arrived at the same time. + +The first is MCP itself. Model Context Protocol gave coding agents a stable way to call tools. Before MCP, every vendor shipped its own plugin format for each editor. Now a single MCP server is portable across Cursor, Claude Code, Windsurf, VS Code, Antigravity, and anything else that speaks the protocol. That lowered the cost of shipping an ai agent backend platform surface to almost zero. + +The second is the rise of prompt-built apps. Lovable, Bolt, and Replit generate entire frontends from a sentence. Users of those tools are not always backend engineers. When they need auth, tables, file uploads, or scheduled jobs, they want an agent to connect a backend, not a ten-step manual checklist. + +The third is that coding agents now write a meaningful share of the code in new apps. Arena-style benchmarks have made it clear that Appwrite-specific knowledge, not general coding ability, decides whether generated code works the first time. If an agent does not know your platform, the developer using that agent becomes the debugger. + +Put together, these shifts mean backend platforms are being evaluated against a new checklist: does an agent already understand your product, can it act on it safely, and does it stay current? + +# Where Appwrite sits in this category + +Appwrite is designed so that agents can reason about it, manage it, and build on top of it, using the same primitives a human developer uses. + +On the management side, the [API MCP server](/docs/tooling/ai/mcp-servers/api) lets LLMs and coding agents perform operations directly on an Appwrite project: creating users, managing databases, tables, and columns, handling storage, invoking functions, and more. The server works with API keys, supports scoping through flags like `--tablesdb`, `--users`, `--teams`, `--storage`, `--functions`, and `--messaging`, and installs into the same editors as other MCP servers. + +On the knowledge side, the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) gives AI assistants access to Appwrite documentation at call time, so agents can answer questions about APIs, SDKs, and patterns without relying on training data. Together, these two servers cover the "act on your project" and "read the docs at call time" pillars of agent-native. + +Appwrite's agent surface goes further than MCP alone. + +- [Agent Skills](/docs/tooling/ai/skills) are open-source Markdown files that give AI agents language-specific SDK context. Skills cover the Appwrite CLI and every major SDK including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift, and work across Claude Code, Cursor, Windsurf, and other compatible tools. +- [Editor plugins](/docs/tooling/ai/ai-dev-tools/claude-code) for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) bundle the API MCP server, the Docs MCP server, and the agent skills into a single install, so an agent is set up to build with Appwrite in two commands. +- [Appwrite Assistant](/docs/tooling/ai/assistant) is an AI helper inside the Appwrite Console, reachable through the Command Center under the `Ask the AI` tab. It is grounded in Appwrite documentation and helps with inline troubleshooting and code snippet generation. +- [Appwrite Arena](/docs/tooling/ai/arena) is an open-source benchmark that scores how well AI models understand Appwrite, with and without Agent Skills. + +On the build side, the primitives that agents compose against are the same ones used by human developers: + +- [Auth](/docs/products/auth) for identity, sessions, OAuth, MFA, Teams, and roles. +- [Databases](/docs/products/databases) with tables, typed columns, rows, relationships, queries, and transactions. +- [Storage](/docs/products/storage) for buckets, permissions, antivirus, and image transformations. +- [Functions](/docs/products/functions) in Node, Python, Go, PHP, Dart, Ruby, Deno, and more, with CRON and event triggers. +- [Realtime](/docs/apis/realtime) for live updates on rows, events, and custom channels. +- [Sites](/docs/products/sites) for deploying frontends with custom domains, env vars, logs, and rollbacks. + +Because these primitives are small and named, agents plan cleaner tool calls against them. Creating a table with typed columns, setting row permissions, wiring a function to an event trigger, and deploying a site to a custom domain each fit inside a single unit of intent. + +# How alternative platforms are positioning + +Almost every serious backend vendor has staked out some agent-native ground. The shapes are different. + +**Firebase** ships an MCP server through `firebase-tools` that exposes tools like `firebase_init`, `firebase_create_project`, `firestore_query_collection`, `auth_get_users`, `dataconnect_execute`, `storage_get_object_download_url`, `messaging_send_message`, `functions_get_logs`, and Remote Config and Crashlytics helpers. It also ships slash prompts like `/firebase:init` and `/firebase:deploy`. The surface is clearly Firebase-shaped: Firestore, Auth, Data Connect, Storage, Cloud Messaging, Functions, Remote Config, and Crashlytics. + +**Supabase** positions MCP as a first-class way to let an AI tool run SQL on your project. The managed server at `mcp.supabase.com/mcp` offers tools grouped into Database, Debugging, Development, Edge Functions, Account management, Docs, and experimental Branching. Database tools include `list_tables`, `apply_migration`, and `execute_sql`. Edge Functions can be listed, fetched, and deployed. The server uses OAuth, with read-only and project-scoped modes to contain blast radius. + +**Neon** takes the Postgres-for-agents route. The Neon MCP Server lets an agent create and branch projects, run SQL, and perform database migrations through natural language, reachable through OAuth at `mcp.neon.tech/mcp` or API-key-based setups for remote agents. The pitch is that every agent can have its own database branch to try things in, which is a different use of the primitive than a monolithic dev database. + +**Netlify** frames the category explicitly as "agent-native development" and ships an MCP server that lets AI clients like Windsurf, Cursor, VS Code, Claude, Goose, and Sourcegraph Amp create and deploy projects, modify access controls, install extensions, enable form submissions, and manage environment variables and secrets. Hosting platforms are positioning themselves around what an agent does on deploy day. + +**Cloudflare** takes a different angle with the Agents SDK. Instead of mainly exposing its control plane to agents, Cloudflare lets you build agents on top of Durable Objects, each with its own SQL database, WebSocket connections, scheduling, and tool support. It is an agent runtime more than an MCP surface, aimed at teams shipping stateful AI apps on Workers. + +**Convex** leans into an Agent component with threads, message persistence, tool calls, RAG through a dedicated RAG component, workflows, usage tracking, and rate limiting. The focus there is agent application primitives inside a TypeScript-only backend, not letting outside agents manage the platform. + +These are all legitimate interpretations of agent-native. They diverge on one question: should the platform be something an agent builds on, something an agent manages, or both. + +# What a checklist for an agent-native backend looks like + +Pulling the pattern out of the vendors above, an agent native backend platform checklist starts to look like this: + +| Capability | What it means for agents | +|---|---| +| Control-plane MCP server | Agents can create, read, update, and delete project resources through tool calls, not synthesized HTTP. | +| Docs MCP server or equivalent | Agents can fetch current reference material at call time to avoid stale training data. | +| Agent skills or guides | Language-specific SDK context the agent can load once and reuse across tasks. | +| Typed primitives | Clear names for databases, tables, columns, rows, buckets, functions, sites, users, and roles. | +| Scoped API keys and permissions | Agents can be given least privilege for a project, environment, or service. | +| First-party model benchmarks | Some way to measure which models produce correct code for the platform. | +| Console assistant | AI help where human developers still do the oversight work. | +| Observability agents can see | Logs, deploys, and events retrievable as structured data instead of screenshots. | + +Different vendors cover different rows. Firebase, Supabase, Neon, and Netlify concentrate on control-plane MCP. Convex focuses on agent application primitives. Cloudflare builds a runtime for agents themselves. Appwrite covers the full column: MCP for the API, MCP for the docs, Skills for the SDKs, plugins for Claude Code and Cursor that bundle all of it in one install, Arena for model evaluation, Assistant for console help, and a set of primitives small enough for agents to compose cleanly. + +# What this means for teams building AI apps + +Two practical takeaways follow from the category taking shape. + +First, pick a backend the way agents would. If you are going to spend the next year shipping with Cursor, Claude Code, Windsurf, or Lovable in the loop, evaluate backend platforms by running a few tasks through an agent before you commit. Ask an agent to create a project, design a table with typed columns, set row permissions, write a function that inserts a row on a webhook, and deploy a frontend to a custom domain. Watch where the agent stalls, where it hallucinates, and where it needs you to read docs for it. That is a better benchmark than any vendor comparison table. + +Second, treat MCP, skills, and docs quality as product choices, not marketing. A platform that expects its users to paste long prompts explaining how it works every session is one that has not done the agent-native work. A platform that installs into Cursor or Claude Code with one command, keeps its docs available through MCP, and ships an open benchmark to show how models perform on it is one that has. + +The rise of agent-native backend platforms is not a rebrand. It is an admission that two audiences now read your product: the human who decides and the agent who writes the code. Platforms that take that seriously are the ones both audiences will reach for. + +To see what this looks like in practice, start with the [Appwrite AI tooling hub](/docs/tooling/ai), install the [API MCP server](/docs/tooling/ai/mcp-servers/api) and the [Docs MCP server](/docs/tooling/ai/mcp-servers/docs), add [Agent Skills](/docs/tooling/ai/skills) for your SDK, or grab the editor plugin for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) or [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) to install everything in one step. + +- [Appwrite AI tooling](/docs/tooling/ai) +- [API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Docs MCP server](/docs/tooling/ai/mcp-servers/docs) +- [Agent Skills](/docs/tooling/ai/skills) +- [Appwrite Arena](/docs/tooling/ai/arena) +- [Appwrite Assistant](/docs/tooling/ai/assistant) diff --git a/src/routes/blog/post/appwrite-vs-cloudflare-stateful-ai-agents/+page.markdoc b/src/routes/blog/post/appwrite-vs-cloudflare-stateful-ai-agents/+page.markdoc new file mode 100644 index 0000000000..ddc527c4a5 --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-cloudflare-stateful-ai-agents/+page.markdoc @@ -0,0 +1,118 @@ +--- +layout: post +title: "Appwrite vs Cloudflare for stateful AI agents" +description: "Compare Appwrite and Cloudflare as a stateful AI agents backend, from memory and state patterns to Auth, Databases, Storage, Functions, Realtime, and MCP." +date: 2026-04-30 +cover: /images/blog/appwrite-vs-cloudflare-stateful-ai-agents/cover.png +timeToRead: 9 +author: aditya-oberai +unlisted: true +category: comparisons +--- + +The conversation around stateful AI agents has shifted. Teams are no longer just asking "where does my model run?" They are asking where threads live, how tool calls recover after a crash, how files attach to agent sessions, how live updates reach every client, and how coding agents operate on the backend through MCP. + +Two platforms come up in this conversation often. Cloudflare has been marketing stateful agent infrastructure through its Agents SDK, Durable Objects, and Workers. Appwrite takes a different angle as a broader open-source backend that covers Auth, Databases, Storage, Functions, Realtime, Sites, and MCP. This is the comparison for teams evaluating a Cloudflare Agents alternative and for teams deciding where to put the stateful AI agents backend end to end. + +# How Cloudflare positions itself for stateful AI agents + +Cloudflare's Agents SDK is built on Durable Objects and Workers. The docs describe each agent as a TypeScript class that runs on a Durable Object, a stateful micro-server with its own SQL storage, WebSocket connections, and scheduling. The pitch is that state survives restarts, deploys, and hibernation, and that the same code runs across Cloudflare's global network. + +Around that core, Cloudflare layers more: + +- AIChatAgent with streaming, message persistence, and resumable streams for chat agents. +- `@callable()` methods that become typed RPC over WebSocket. +- Scheduling by delay, by specific time, or by cron, so agents can wake themselves up. +- Client tools, server tools, and human-in-the-loop approval flows. +- MCP support so agents can expose tools to other agents and LLMs. +- Integrations with Workers AI, AI Gateway, Workflows, and browser tools. + +If you are committed to the Cloudflare platform and writing agents in TypeScript, the model is cohesive. Each agent is a class, state is co-located with compute in a Durable Object, and Cloudflare handles the placement, hibernation, and scale. + +# Where Cloudflare creates trade-offs for AI teams + +A few things show up once you look past the marketing page. + +- **Stateful compute is the product, not the backend.** Durable Objects and Workers give you compute and storage tied to an agent instance. Auth, a broad database for app data, a file system with permissions, and a hosted frontend for your AI app are not part of the same product. You stitch those in from D1, R2, Workers, and other services. +- **Language surface is narrow.** The Agents SDK is TypeScript-first. If your team writes Python, Go, or anything else on the server, you are back to Workers, D1, and custom glue. +- **State lives per agent.** A Durable Object is scoped to an agent instance with its own SQL. Cross-agent queries, shared user tables, and cross-thread analytics are your job to design and coordinate across objects. +- **Auth is not first-party for agents.** You bring an identity layer separately, usually a third-party provider, then wire sessions and permissions into your agent logic. +- **Lock-in to the edge model.** Your agent's durability assumptions, scheduling, storage, and hibernation are tied to Durable Objects. Moving off Cloudflare means rewriting the stateful part, not just changing a deployment target. + +None of this makes Cloudflare a bad choice for a specific kind of agent. It does mean Cloudflare Agents is an infrastructure layer for stateful compute, not a complete backend for your AI product. + +# How Appwrite positions itself for AI apps and agents + +Appwrite takes a different angle. Instead of shipping a dedicated Agent runtime, Appwrite provides a broad backend where agent workloads sit on top of the same primitives that power any application: + +- **Auth** with email, OAuth, phone, anonymous, and MFA, plus Teams and roles, without a third-party service. +- **Databases** with TablesDB: databases, tables, rows, typed columns, relationships, queries, indexes, and transactions. You model agent state, thread metadata, message history, tool results, and user profiles as rows in tables. +- **Storage** with buckets, permissions, antivirus scanning, and image transformations for files attached to agent sessions, RAG sources, and user uploads. +- **Functions** on Node, Python, Go, Ruby, Deno, PHP, and more, for tool calls, orchestration, LLM integrations, webhooks, and scheduled jobs. +- **Sites** for hosting the frontend of your AI app with source control deploys, custom domains, env vars, and rollbacks. +- **Realtime** channels that subscribe to row changes, user events, and custom events, which is how you push token output, tool call results, and agent status to every connected client. +- **Messaging** for email, SMS, and push, useful for human-in-the-loop approval and async notifications from long-running agents. +- **Appwrite MCP servers**, both the API MCP for acting on Appwrite resources and the Docs MCP for Appwrite context, so coding agents can build and operate against Appwrite directly. +- **Agent Skills** for the Appwrite CLI and every major SDK including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift, so agents generate idiomatic Appwrite code without docs in the prompt. +- **Editor plugins** for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) that bundle the API MCP, Docs MCP, and skills into one install. +- **Self-hosting** under an open-source license, or **Appwrite Cloud** with the same API surface. + +The point is not that Appwrite replaces Durable Objects one-to-one. The point is that once you have identity, structured tables, rows, storage, functions, realtime, and MCP, you already have what a stateful AI agent needs: users, durable state, memory, tool hosting, live updates to clients, and a way for coding agents to act on your backend. + +# Appwrite vs Cloudflare: side by side + +| Capability | Cloudflare | Appwrite | +|---|---|---| +| Agent state | Per-agent Durable Object with SQL storage, hibernation, WebSockets | Rows in TablesDB scoped with Auth, Teams, and permissions, readable across agents | +| Auth | Bring your own provider or custom session logic | First-party Auth with email, OAuth, phone, anonymous, MFA, Teams, roles | +| Database | Durable Object SQL per instance, or D1 for shared SQL | TablesDB with databases, tables, typed columns, rows, relationships, queries, indexes, transactions | +| Storage | R2 object storage, wired into Workers | Storage buckets with permissions, antivirus scanning, and image transformations | +| Functions / compute | Workers and Durable Objects, TypeScript-first Agents SDK | Functions in Node, Python, Go, Ruby, Deno, PHP, and more, with CRON schedules and event triggers | +| Realtime | WebSockets and SSE from Durable Objects and Workers | Realtime channels for row changes, user events, and custom events | +| Hosting | Workers, Pages, and related services | Sites with source control deploys, custom domains, env vars, rollbacks | +| MCP, Skills, and editor plugins | Agents SDK MCP tooling for Cloudflare workloads | Appwrite API MCP, Appwrite Docs MCP, Agent Skills for CLI and 10 SDKs, Claude Code and Cursor plugins | +| Self-hosting | Proprietary, Cloudflare platform only | Open source with unrestricted self-hosting, plus Appwrite Cloud | +| Pricing model | Per-request, per-CPU, per-GB storage across Workers, Durable Objects, R2, D1 | Plan-based Appwrite Cloud with generous free tier, or self-host | + +# State patterns, without overpromising compute behavior + +Stateful AI agents usually need three things from a backend: a place to keep durable state between turns, a way to push updates to clients as they happen, and a way to run logic on schedule or in response to events. + +Cloudflare answers this with Durable Objects. Each agent instance gets a stateful micro-server with its own SQL. The state is co-located with the compute that uses it, and Cloudflare handles placement and hibernation. It is a strong story for agents where everything the agent needs to know fits inside the object. + +Appwrite answers it at a higher level. State lives in tables and rows with typed columns, relationships, and permissions. Any Function, any agent, any authenticated client can read and write that state through the same API. Realtime pushes row changes to subscribed clients without building a custom WebSocket layer. Functions handle scheduled runs through CRON and react to events from other Appwrite services. When an agent needs to read another user's profile row, share a thread between two users, or run analytics across all agents, it is a query against a shared database, not a coordination problem between objects. + +The Appwrite approach does not try to replace stateful edge compute. It treats agent state as application data that should live in the same place as the rest of your product data, protected by the same auth, permissions, and queries. + +# Where Appwrite fits + +Appwrite is the right pick when: + +- You need a broad backend that handles Auth, TablesDB, Storage, Functions, Realtime, Sites, Messaging, and MCP without stitching multiple vendors together. +- You want relational-style tables, typed columns, and queries for thread state, message history, and RAG metadata, with permissions on rows that the platform enforces. +- You want first-party Auth with Teams and roles from day one, not a third-party dependency. +- You want coding agents to act on your backend through a first-party MCP, with the Docs MCP, Agent Skills, and editor plugins available for context inside tools like Cursor, Claude Code, Lovable, and Windsurf. +- You care about self-hosting under a standard open-source license or the option to move between Appwrite Cloud and your own infrastructure. + +Cloudflare's Agents SDK is a tighter fit when the agent itself is the entire product, the team is committed to TypeScript on Workers, and per-agent Durable Objects are the unit of state you want. + +# How teams usually split the decision + +Most AI products that reach users end up looking like a broader app: a CRM with agents, a support product with an AI assistant, a SaaS tool with background agents. The agent is one of many surfaces. You also need user accounts, teams, permissions, file uploads, notifications, scheduled jobs, webhooks, a hosted frontend, and coding agents that can operate on your backend through MCP. That is where Appwrite's breadth pays off. You are not spending the first month wiring up four Cloudflare services and a separate auth vendor before you get to the AI part. + +Pure stateful agents where the compute and the state are the entire product, like a long-running research agent or a multiplayer coordination agent, are the narrower case Cloudflare's Durable Objects model is built for. Even there, Appwrite Functions plus TablesDB cover most of the same ground without the per-instance edge runtime lock-in. + +# Stateful AI agents come down to primitives, not products + +The useful question is not "does this platform sell an Agents SDK?" It is "does this platform give me identity, durable state, event triggers, realtime, storage, tool hosting, and a way for coding agents to act on my backend?" + +Cloudflare answers that with an Agents SDK on top of Durable Objects and Workers, then leaves the rest of the backend to you. Appwrite answers it with a broader open-source backend where Auth, TablesDB, Storage, Functions, Realtime, Sites, and MCP line up with what stateful AI agents need, without making you adopt a per-instance edge runtime before your product shape is clear. + +If you want to explore Appwrite as the backend for your stateful AI agents, start with [Appwrite Cloud](https://cloud.appwrite.io), read the [AI tooling hub](/docs/tooling/ai), and check the [API MCP server](/docs/tooling/ai/mcp-servers/api), [Agent Skills](/docs/tooling/ai/skills), and the editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor). + +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite AI tooling](/docs/tooling/ai) diff --git a/src/routes/blog/post/appwrite-vs-convex-ai-agents/+page.markdoc b/src/routes/blog/post/appwrite-vs-convex-ai-agents/+page.markdoc new file mode 100644 index 0000000000..25fb545389 --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-convex-ai-agents/+page.markdoc @@ -0,0 +1,111 @@ +--- +layout: post +title: "Appwrite vs Convex for AI apps and agent workflows" +description: "Compare Appwrite vs Convex for AI apps and agent workflows, from agent primitives to Auth, TablesDB, Realtime, Storage, Functions, and MCP." +date: 2026-04-28 +cover: /images/blog/appwrite-vs-convex-ai-agents/cover.png +timeToRead: 9 +author: atharva +unlisted: true +category: comparisons +--- + +Picking a backend for AI apps and agent workflows is not the same decision it was two years ago. You are no longer just choosing a database and an auth service. You are choosing where threads live, how tool calls get durably retried, how files attach to chat history, how realtime updates reach every client, and how coding agents talk to your backend through MCP. + +Two platforms come up in this conversation frequently: Convex, which has leaned hard into an Agent component with message persistence, RAG, and workflow primitives, and Appwrite, a broader open-source backend that covers Auth, TablesDB, Storage, Functions, Realtime, Sites, and MCP. This post is the appwrite vs convex breakdown for teams evaluating a Convex alternative for AI agents and for teams deciding where to host their AI product end to end. + +# How Convex positions itself for AI agents + +Convex's agent story is centered on its Agent component. The docs describe it as a building block that manages threads and messages for agents that can cooperate in static or dynamic workflows, with hybrid vector and text search for past messages and automatic context assembly on each LLM call. + +Around that, Convex layers a broader platform: + +- Functions split into queries, mutations, and actions, where only actions can call external APIs. +- HTTP actions for webhook endpoints and custom clients. +- A document-style database with optional schemas, indexes, and paginated queries. +- Realtime that is automatic as long as you read data through query functions and client libraries. +- File Storage with upload, store, serve, and delete, referenced from database documents. +- Scheduled Functions and Cron Jobs for durable scheduling, plus higher-level Workpool, Workflow, and Cron components for larger scale. +- Authentication via Clerk, WorkOS AuthKit, Auth0, Custom OIDC, or the beta Convex Auth library. +- Self-hosting under an FSL Apache 2.0 license that converts to Apache 2.0 after two years. + +Convex has done a good job of giving agent builders a clean mental model. Threads, messages, tools, workflows, and RAG each have their own documented component. If you are already writing your backend in TypeScript and want an opinionated stack, that is attractive. + +# Where Convex creates trade-offs for AI teams + +A few things show up once you look closely at the Convex agent stack: + +- **Auth is mostly delegated.** Convex's own documentation describes Convex Auth as beta and points to Clerk, WorkOS, or Auth0 as the more complete path. If identity, sessions, and organization roles matter in your AI app, you are usually wiring up a separate auth vendor from day one. +- **Agent features are components, not unified products.** Threads, workflows, RAG, rate limiting, and usage tracking each live as installable components. That modularity is the point, but it also means more surfaces to version and configure as your agent stack grows. +- **Function model splits based on what you can do.** Queries and mutations cannot call external APIs. Only actions can call OpenAI, Stripe, or any outside service. That split is fine once you learn it, but it affects how you structure any agent logic that mixes reads, writes, and LLM calls. +- **Single-database-style model.** Convex's database is document-oriented with optional schemas. Teams that want structured tables, typed columns, and relational queries often have to lean on the schema and ID-reference patterns to get there. +- **Self-hosting has license constraints.** The FSL Apache 2.0 license blocks you from running a competing hosted Convex product, with a two-year conversion to Apache 2.0. Not a blocker for most teams, worth flagging for anyone building platforms. + +# How Appwrite positions itself for AI apps and agents + +Appwrite takes a different angle. Instead of treating agents as a dedicated product line, Appwrite ships a broad backend where AI workloads sit naturally on top of the same primitives that power any app: + +- **Auth** with email, OAuth, phone, anonymous, and MFA, plus Teams and roles, without a third-party service. +- **TablesDB** with databases, tables, rows, typed columns, relationships, queries, indexes, and transactions. You model agent state, thread metadata, message history, tool results, and user profiles as rows in tables. +- **Storage** with buckets, permissions, antivirus scanning, and image transformations for files attached to agent sessions, RAG sources, and user uploads. +- **Functions** on Node, Python, Go, Ruby, Deno, PHP, and more, for tool calls, orchestration, LLM integrations, and webhooks. +- **Sites** for hosting the frontend of your AI app with source control deploys, custom domains, env vars, and rollbacks. +- **Realtime** channels that subscribe to row changes, user events, and custom events, which is how you push token updates, tool call results, and agent status to every connected client. +- **Messaging** for email, SMS, and push, useful for human-in-the-loop approval and async notifications from long-running agents. +- **Appwrite MCP servers**, both the API MCP (for acting on Appwrite resources) and the Docs MCP (for Appwrite context), so coding agents can build and operate against Appwrite directly. +- **Agent Skills** for the Appwrite CLI and every major SDK including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift, so agents generate idiomatic Appwrite code without docs in the prompt. +- **Editor plugins** for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) that bundle the API MCP, Docs MCP, and skills into one install. +- **Self-hosting** under an open-source license, or **Appwrite Cloud** with the same API surface. + +The point is not that Appwrite has a dedicated Agent component that matches Convex's one-to-one. The point is that once you have Auth, tables, rows, storage, functions, realtime, and MCP, you already have what an agent needs: identity, durable state, memory, tool hosting, live updates to clients, and a way for coding agents to operate on your backend. + +# Appwrite vs Convex: side by side + +| Capability | Convex | Appwrite | +|---|---|---| +| Agent primitives | Agent component with threads, messages, tools, streaming, playground | Tables, rows, functions, realtime, storage composed into agent workflows | +| Thread and message persistence | Built-in with hybrid vector and text search | Modeled in TablesDB with relationships, indexes, and queries | +| RAG | RAG component with namespaces, chunking, and embeddings | Build on TablesDB plus Functions for chunking and any embedding provider | +| Database model | Document-style with optional schemas | Relational-style TablesDB: databases, tables, typed columns, rows, relationships, transactions | +| Auth | Third-party (Clerk, WorkOS, Auth0) or Convex Auth (beta) | First-party Auth with email, OAuth, phone, anonymous, MFA, Teams, roles | +| Backend logic | Queries, mutations, actions, HTTP actions in TypeScript | Functions in Node, Python, Go, Ruby, Deno, PHP, and more | +| Scheduling | Scheduled Functions, Cron Jobs, Workpool/Workflow/Cron components | Functions with CRON schedules and event triggers | +| Realtime | Automatic through query subscriptions | Realtime channels for rows, events, and custom channels | +| File handling | File Storage with upload, serve, delete, metadata | Storage with buckets, permissions, antivirus, and image transformations | +| Frontend hosting | Not part of the backend platform | Sites with deploys, custom domains, env vars, rollbacks | +| MCP, Skills, and editor plugins | Component-level tool calls from agents | Appwrite API MCP, Appwrite Docs MCP, Agent Skills for CLI and 10 SDKs, Claude Code and Cursor plugins | +| Licensing | FSL Apache 2.0 that converts to Apache 2.0 after two years | Open source with unrestricted self-hosting and Appwrite Cloud | +| Language surface | TypeScript and JavaScript | Multi-language SDKs across web, mobile, and server | + +# Where Appwrite fits + +Appwrite is the right pick when: + +- You need a broad backend that handles Auth, TablesDB, Storage, Functions, Realtime, Sites, Messaging, and MCP without stitching multiple vendors together. +- You want relational-style tables, typed columns, and queries for thread state, message history, and RAG metadata, with permissions on rows that the platform enforces. +- You want first-party auth with Teams and roles from day one, not a third-party dependency. +- You want coding agents to act on your backend through a first-party MCP, with Agent Skills for your SDK and editor plugins for Claude Code and Cursor that install the whole agent surface in one step. +- You care about self-hosting under a standard open-source license or the option to move between Appwrite Cloud and your own infrastructure. + +Convex is the tighter fit for an all-TypeScript team that wants a dedicated Agent component, is happy to add Clerk, WorkOS, or Auth0 for auth, and prefers a document-style data model. + +# How teams usually split the decision + +Most AI products that reach users are broader apps where the agent is one feature among many: a CRM with an AI assistant, an e-commerce product with an AI concierge, a SaaS tool with agents on the side. They also need user accounts, teams, permissions, file uploads, notifications, scheduled jobs, webhooks, a hosted frontend, and the ability for coding agents to operate on your backend through MCP. That is where Appwrite's breadth pays off. You are not spending the first month wiring up four vendors before you get to the AI part. + +The narrower case is a pure TypeScript AI app where the agent itself is the entire product, like a support agent, a coding copilot, or a writing tool. Convex's Agent component is shaped for that. Even there, modeling threads and tool calls as rows in TablesDB and pushing updates over Realtime gives you the same primitives without committing to a TypeScript-only backend. + +# Agent workflows come down to primitives, not labels + +The useful question is not "does this platform have an agent product?" It is "does this platform give me identity, durable state, event triggers, realtime, storage, tool hosting, and a way for coding agents to act on my backend?" + +Convex answers that with an Agent component plus a narrower TypeScript-centric platform. Appwrite answers it with a broader open-source backend where Auth, TablesDB, Storage, Functions, Realtime, Sites, and MCP line up with what agents need, without making you adopt a dedicated agent abstraction before your product shape is clear. + +If you want to explore Appwrite for an AI app or agent workflow, start with [Appwrite Cloud](https://cloud.appwrite.io), read the [AI tooling hub](/docs/tooling/ai), and check the [API MCP server](/docs/tooling/ai/mcp-servers/api), [Agent Skills](/docs/tooling/ai/skills), and the editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor). + +- [Appwrite TablesDB](/docs/products/databases) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite AI tooling](/docs/tooling/ai) diff --git a/src/routes/blog/post/appwrite-vs-firebase-ai-development/+page.markdoc b/src/routes/blog/post/appwrite-vs-firebase-ai-development/+page.markdoc new file mode 100644 index 0000000000..d887c38192 --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-firebase-ai-development/+page.markdoc @@ -0,0 +1,136 @@ +--- +layout: post +title: "Appwrite vs Firebase for AI-assisted development" +description: "Appwrite vs Firebase AI: compare MCP, SDK breadth, Auth, databases, Storage, Functions, Sites, and self-hosting for AI-assisted development." +date: 2026-04-27 +cover: /images/blog/appwrite-vs-firebase-ai-development/cover.png +timeToRead: 9 +author: aishwari +unlisted: true +category: comparisons +--- + +Picking a backend for an app that an AI coding agent will help build is a decision with a long half-life. The agent spends most of its context budget reasoning about identity, data, files, server-side code, and hosting, so the platform underneath has to give it clear primitives, a stable API, and an MCP surface the model can use directly. Appwrite vs Firebase AI is the comparison teams run when they weigh an open-source, self-hostable backend against Google's AI assistance ecosystem. + +This article looks at Appwrite as a Firebase alternative for AI apps, focused on open-source flexibility, MCP coverage, Databases with tables and rows, Functions, Sites, and self-hosting, against Firebase's Gemini in Firebase, Firebase MCP server, Gemini CLI extension, and agent skills. + +# Appwrite vs Firebase AI at a glance + +Firebase is a managed platform on Google Cloud that bundles Authentication, Cloud Firestore, Cloud Storage, Cloud Functions, App Hosting, Cloud Messaging, and a growing AI assistance layer. Its AI assistance story is organized around three surfaces: [Gemini in Firebase](https://firebase.google.com/docs/ai-assistance/gemini-in-firebase) inside Firebase services and the console, the [Firebase MCP server](https://firebase.google.com/docs/ai-assistance/mcp-server) for AI-powered editors, and a [Gemini CLI extension](https://firebase.google.com/docs/ai-assistance/gcli-extension) that wraps the MCP tools with Firebase-specific commands. Firebase also ships [AI Logic](https://firebase.google.com/docs/ai-logic), a client SDK for calling Gemini from Firebase apps. + +Appwrite is an open-source backend you can run on [Appwrite Cloud](/cloud) or host yourself. It presents a single suite covering [Auth](/docs/products/auth), [databases with tables, rows, and columns](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Realtime](/docs/apis/realtime), [Messaging](/docs/products/messaging), and [Sites](/docs/products/sites) for deploying full-stack web apps. Its AI tooling hub covers [MCP servers for the API and the docs](/docs/tooling/ai/mcp-servers/api), [Agent Skills](/docs/tooling/ai), an in-console [Assistant](/docs/tooling/ai), and plugin integrations with editors like [Cursor](/docs/tooling/ai/ai-dev-tools/cursor), [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code), and [Lovable](/docs/tooling/ai/ai-dev-tools/lovable). + +Both platforms expose an MCP server to AI-powered editors. The difference is everything around those servers: data model, permissions, SDK coverage, runtime choice, hosting surface, and whether you can run the whole stack on your own infrastructure. + +# Why AI-assisted development needs a different backend lens + +AI editors are strong at generating UI, API clients, and glue code. They are less reliable at schema design, permission modeling, file upload flows, scheduled jobs, and deployment configuration. When those primitives are typed, consistent, and reachable through an MCP server, the agent has fewer places to invent something that compiles but leaks data or bills the wrong project. + +That is the honest frame for this comparison. It is not about which platform has the better assistant today. It is about which one gives the agent fewer ways to go wrong across the whole lifecycle of a generated app. + +# Feature-by-feature comparison + +| Capability | Appwrite | Firebase | +| --- | --- | --- | +| Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom tokens, OAuth2 with roughly 44 providers | Email and password, phone, anonymous, OAuth with Google, Apple, Facebook, X, GitHub, and others; SAML and OIDC through Identity Platform upgrade | +| Database | Databases with typed tables, rows, and columns, row-level permissions, relationships, queries, and transactions | Cloud Firestore, a NoSQL database with documents and collections, plus Firebase SQL Connect and the legacy Realtime Database | +| Storage | Buckets with row-level permissions, encryption, previews, and transformations | Cloud Storage for Firebase, backed by Google Cloud Storage, with Firebase Security Rules | +| Functions | Node.js, PHP, Ruby, Python, Python ML, Deno, Bun, Dart, .NET, Java, Swift, Kotlin, C++, Go; triggered by HTTP, events, or schedule | Cloud Functions for Firebase in JavaScript, TypeScript, and Python, with experimental Dart; triggered by HTTP, background events, Admin SDK, or Cloud Scheduler | +| Realtime | Channel-based subscriptions across databases, Auth, Storage, and Functions | Firestore realtime listeners and Realtime Database sync | +| Hosting | Sites for deploying Next.js, SvelteKit, Nuxt, Astro, React, Vue, Remix, TanStack Start, Angular, Analog, Vite, and more, with custom domains, env vars, rollbacks, and logs | Firebase Hosting for static assets; Firebase App Hosting for Next.js, Angular, and other frameworks, built on Cloud Run and Cloud Build | +| MCP for AI agents | Official MCP servers for the API and the docs | Official Firebase MCP server exposing Firebase tools and prompts | +| Agent skills | Agent Skills for Appwrite workflows | Firebase agent skills for setup, deploy, and service configuration | +| Self-hosting | Fully self-hostable, Docker-based, open source | Managed only on Google Cloud; no first-party self-hosted option | +| License | Open source | Proprietary managed service | + +# MCP and agent access + +Firebase's MCP server ships as part of the Firebase CLI and runs over stdio. It works with Antigravity, Gemini CLI, Gemini Code Assist, Firebase Studio, Claude Code, Claude Desktop, Cline, Cursor, VS Code Copilot, and Windsurf, and exposes tools for creating and managing Firebase projects, managing Authentication users, reading and writing Cloud Firestore data, retrieving Firebase SQL Connect schemas, inspecting security rules, and sending Cloud Messaging messages. It also offers pre-written prompts like `firebase:init` and `firebase:deploy`. + +Appwrite's API MCP server uses a compact two-tool workflow with automatic service discovery, so an agent can operate across Auth, databases, Storage, Functions, Sites, and Messaging without hand-written glue. A separate Docs MCP server keeps the agent grounded in current Appwrite documentation rather than training-data memories. Both servers are covered in the [AI tooling hub](/docs/tooling/ai). + +The practical difference is scope. Firebase's MCP is rich inside the Firebase surface. Appwrite's MCP reaches the same database, auth, storage, and functions territory and also covers Sites deployments and the full Appwrite API. For an agent that has to generate an app, deploy the frontend, and configure secrets, fewer hops across tools means fewer chances to drift. + +# Data model and permissions + +An AI editor does its best work when your data model is something it can introspect and validate on its own. This is where Appwrite and Firebase take different paths. + +Appwrite Databases expose typed [tables, rows, and columns](/docs/products/databases). Columns use types like text, integer, float, boolean, datetime, enum, and relationship. Permissions attach directly to rows and tables, so the rule an agent writes to protect one user's data lives next to the data it governs. Queries, offset and cursor pagination, transactions, and type generation come through a single SDK surface. + +Firestore is a NoSQL store organized into documents and collections, with nested objects and subcollections. Access is expressed through Firebase Security Rules, a dedicated rules language the agent has to learn in addition to your data shape. Firebase recently introduced Firebase SQL Connect for relational workloads, which the Firebase MCP server can list schemas for. Both paths work, but an AI agent has an easier time reasoning about Appwrite's typed tables and row permissions than about Firestore's document shapes plus a separate rules file. + +# Auth for AI-generated apps + +Auth is where AI-generated code breaks most often, because a missed permission check looks like working code until someone signs in with a different account. + +Appwrite [Auth](/docs/products/auth) covers email and password, magic URL, email OTP, phone, anonymous sessions, JWTs, custom tokens for existing auth systems, and OAuth2 across roughly 44 providers. Teams, labels, and row-level permissions give AI-generated rules a predictable place to live. + +[Firebase Authentication](https://firebase.google.com/docs/auth) supports email and password, phone, anonymous, and popular federated providers including Google, Apple, Facebook, X, and GitHub, with drop-in UI through FirebaseUI. Multi-factor authentication, SAML, OpenID Connect providers, and multi-tenancy require an upgrade to Firebase Authentication with Identity Platform. That upgrade is a normal path for larger apps; it is also an extra tier an agent has to know about when it generates enterprise login flows. + +# Functions, runtimes, and server-side code + +Server-side code is where AI-generated apps touch secrets, call third-party APIs, and mutate data with elevated privileges. Runtime breadth matters because it changes how the agent reaches for libraries. + +Appwrite [Functions](/docs/products/functions) supports Node.js, PHP, Ruby, Python, Python ML, Deno, Bun, Dart, .NET, Java, Swift, Kotlin, C++, and Go, triggered by HTTP, events from Auth, databases, Storage, and other services, or on a schedule. Functions do not stream responses, so token-streaming agent output belongs on the client against an external model provider. + +[Cloud Functions for Firebase](https://firebase.google.com/docs/functions) runs JavaScript, TypeScript, or Python, with experimental support for Dart. Triggers cover HTTP, background events from Firestore, Auth, Storage, and other Firebase services, the Admin SDK, and Cloud Scheduler jobs. + +If your agent is going to reach for Python ML packages, Go, Rust-style performance through C++, or Kotlin for mobile-shared code, Appwrite gives it more room. If your team has standardized on Node or Python, Firebase's narrower surface is fine and comes with tight Google Cloud integration. + +# SDK breadth + +Appwrite ships official SDKs for Web, Node.js, React Native, Flutter, Apple (Swift), Android (Kotlin), .NET, PHP, Python, Ruby, Deno, Dart, Go, Kotlin server, and Swift server, plus a CLI for CI and templates. When an AI editor scaffolds a new project, it can lean on the same vocabulary across client and server. + +Firebase SDKs cover iOS, Android, Web, Flutter, C++, Unity, and Admin SDKs for Node.js, Java, Python, Go, and C#. Firebase's SDKs are deeply integrated with Google's client platforms. For server-side code outside those runtimes, teams usually fall back to REST or Admin SDK wrappers. + +# Hosting your AI-generated frontend + +Appwrite [Sites](/docs/products/sites) is a deployment target for modern frontends. It supports Next.js, SvelteKit, Nuxt, Astro, React, Vue, Remix, TanStack Start, Angular, Analog, Vite, and more, running on source-control deploys with isolated containers, custom domains, environment variables, rollbacks, deploy logs, and traffic served through Appwrite Network. The same platform that stores the data serves the generated UI. Sites does not stream responses. + +Firebase has two hosting products. Firebase Hosting is the long-standing static and CDN layer. [Firebase App Hosting](https://firebase.google.com/docs/app-hosting) adds managed support for Next.js and Angular, with broader framework coverage through buildpacks, backed by Cloud Build, Cloud Run, and Cloud CDN, with GitHub integration for continuous deploys. For agents generating Gemini-powered features in Next.js or Angular, App Hosting is a clean fit. + +Either platform will host what your agent generates. Appwrite keeps backend and frontend under one control plane you can self-host. Firebase gives you Google's global infrastructure, at the cost of running inside Google Cloud's pricing and terms. + +# Vector search, embeddings, and RAG + +Firebase exposes Gemini through [AI Logic](https://firebase.google.com/docs/ai-logic) for client-side generation, and Firestore supports vector fields for semantic search alongside regular queries. Firebase App Hosting highlights streaming Gemini responses for AI-powered features. + +Appwrite stores embeddings as typed columns and serves them through the same query API as the rest of your data. The [AI tooling hub](/docs/tooling/ai) covers vector DB and embeddings patterns, AI in Functions, and persistent agent state backed by Realtime. Mixing application data and embeddings in the same tables cuts down on the number of concepts an AI builder has to track when it wires up retrieval. + +# Self-hosting, open source, and data ownership + +This is where the two platforms diverge most clearly. Appwrite is open source and runs as a single docker-compose deployment that brings up the full stack, including Sites. Self-hosting is a first-class path, not a fallback. For teams with compliance requirements, data residency concerns, or a preference for owning the runtime, that matters more than any feature comparison. + +Firebase is a proprietary managed service on Google Cloud. You can export data, and the client SDKs are open source, but the server side is not something you run yourself. That is a normal tradeoff for a managed platform, and it is a real constraint for regulated workloads or teams that want to avoid lock-in. + +# When to pick Appwrite + +Choose Appwrite if: + +- You want one open-source platform covering Auth, TablesDB, Storage, Functions, Realtime, Messaging, and hosting for your AI-generated frontend, all reachable through an MCP server. +- You prefer typed tables, rows, and columns with platform-enforced permissions over NoSQL documents plus a separate rules language. +- You want broad runtime choice in Functions so your agent can reach for Python ML, Go, Kotlin, or Swift as needed. +- You plan to self-host, keep data in your own infrastructure, or avoid Google Cloud specifically. +- You want your agent to scaffold, deploy, and operate the frontend on Sites through the same API surface it uses for data and auth. + +# When Firebase is the tighter fit + +Firebase is the more natural pick if your team is already inside Google Cloud, wants Gemini, Vertex, and Firestore under one billing relationship, and is happy owning Security Rules generated by an AI editor against Firestore's document model. The trade is that you commit to a managed-only stack with no self-host path and a narrower runtime surface for Functions. + +# Bottom line + +Neither Appwrite nor Firebase does model inference for you; both let your code call Gemini, GPT, Claude, and others. The difference is the shape of the backend an AI agent works against. Firebase gives you Google's managed stack, a Gemini-centric AI assistance layer, and an MCP server focused on Firebase resources. Appwrite gives you an open-source, self-hostable suite with typed tables, broad runtime choice, Sites for hosting, and MCP coverage across the full product surface. + +If your agent is going to ship the next year of your product, pick the platform where it has the fewest places to get lost and the most freedom to operate on. + +# Further reading + +- [Appwrite Auth](/docs/products/auth) +- [Appwrite databases](/docs/products/databases) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [AI tooling on Appwrite](/docs/tooling/ai) +- [MCP server for the Appwrite API](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Claude Code plugin](/blog/post/announcing-appwrite-claude-code-plugin) +- [Appwrite Cursor plugin](/blog/post/announcing-appwrite-cursor-plugin) diff --git a/src/routes/blog/post/appwrite-vs-neon-ai-backends/+page.markdoc b/src/routes/blog/post/appwrite-vs-neon-ai-backends/+page.markdoc new file mode 100644 index 0000000000..dccd1d29c0 --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-neon-ai-backends/+page.markdoc @@ -0,0 +1,117 @@ +--- +layout: post +title: "Appwrite vs Neon for AI app backends" +description: "Compare Appwrite vs Neon for AI app backends. Neon owns Postgres for agents; Appwrite gives you a complete app backend with Auth, storage, MCP, and more." +date: 2026-04-29 +cover: /images/blog/appwrite-vs-neon-ai-backends/cover.png +timeToRead: 9 +author: aishwari +unlisted: true +category: comparisons +--- + +Teams building AI apps in 2026 keep running into the same question: where should the backend live? Neon has become one of the most talked-about answers thanks to its focus on Postgres for agents, instant branching, and a tight MCP story. Appwrite takes a different approach by shipping a broader app backend that covers Auth, TablesDB, Storage, Functions, Realtime, Sites, Messaging, and MCP in one platform. + +This post is the appwrite vs neon comparison for teams picking a backend for AI apps and looking for a Neon alternative for AI apps when the job is a full-stack product, not just a database. The two platforms solve different problems, so the useful framing is not which one is better, but which one fits the shape of what you are building. + +# How Neon positions itself for AI agents + +Neon's AI pitch is focused and clear. The landing page describes Neon as "serverless Postgres built for modern AI workflows" with storage and compute separated, autoscale to zero, and the ability for agents to create databases without friction. + +The pieces Neon emphasizes for agents: + +- **One-second database provisioning.** Agents can spin up fresh Postgres databases in seconds through an API, with quotas and autosuspend. +- **Database branching.** Every Neon branch snapshots the full database state, so agents or developers can roll back, preview, or test against isolated copies. +- **Neon MCP Server.** The Neon MCP server lets coding agents provision projects and branches, run SQL, and run branch-based migrations from inside Cursor, Claude Code, Codex, VS Code, and other MCP clients. +- **Cursor and Copilot integration.** Neon markets itself as "ready for AI-assisted coding" with in-IDE workflows for branches, query plans, and data resets. +- **pgvector for RAG.** Postgres with pgvector and HNSW indexing doubles as a vector store, so teams can keep embeddings next to their relational data. +- **Database-per-tenant.** Neon positions per-user databases as a first-class pattern for B2B SaaS and regulated workloads, with API-first provisioning of thousands of projects. +- **Neon Auth (Beta).** A managed auth service built on Better Auth that stores users, sessions, and auth configuration in the same Neon database and branches with it. + +If your problem is "I need Postgres that an agent can create, modify, and reason about," Neon is a strong answer. Its serverless economics, branching model, and MCP surface are well designed for that job. + +# Where Neon leaves gaps for a full AI app backend + +Neon is a database company. That is a strength when the job is the database, and a gap when the job is the whole backend behind an AI product. + +A few things AI product teams usually still need, which sit outside Neon's core scope: + +- **Identity with Teams, roles, and MFA.** Neon Auth is a helpful addition for branch-aware auth, and it is documented as Beta and built on Better Auth 1.4.18. Teams that want broader provider coverage, organization roles, and a long-stable auth surface often still reach for a dedicated auth vendor or build their own. +- **File storage with permissions.** Neon does not ship an object storage product. AI apps with user uploads, generated images, audio, and RAG source files still need a separate storage layer with permissions and access control. +- **Server-side functions.** Custom backend logic, webhooks, scheduled jobs, tool calls, and LLM orchestration are not part of Neon. Teams typically pair Neon with a functions or edge-runtime product somewhere else. +- **Realtime channels for UI updates.** Neon has strong branching and Data API features, but live pub/sub channels for pushing tool call results, thread updates, and agent status to clients are usually solved with another service. +- **Hosting for the frontend.** Neon is not a hosting platform. You still pick a separate host for your AI app. +- **Messaging.** Email, SMS, and push for transactional flows, approvals, and notifications sit elsewhere in the stack. + +None of this is a knock on Neon. Postgres-for-agents is the lane Neon picked, and it is a good lane. It just means a full AI app on Neon is usually Neon plus four or five other vendors, which is the trade-off Appwrite is designed to remove. + +# How Appwrite positions itself for AI app backends + +Appwrite is built as a backend platform for the whole app, with AI workloads sitting on the same primitives as any other product: + +- **Auth** with email, OAuth, phone, anonymous, and MFA, plus Teams and roles, as a first-party service. No third-party dependency for identity on day one. +- **TablesDB** with databases, tables, rows, typed columns, relationships, queries, indexes, and transactions. You model user profiles, conversation threads, message history, tool call logs, and RAG metadata as rows in tables, with permissions at the row level. +- **Storage** with buckets, permissions, antivirus scanning, and image transformations for user uploads, generated files, and RAG sources. +- **Functions** on Node, Python, Go, Ruby, Deno, PHP, and more, for tool calls, LLM orchestration, webhooks, and scheduled jobs. +- **Realtime** channels that subscribe to row changes and custom events, so clients see tool call results, thread updates, and agent status without polling. +- **Sites** for hosting the frontend of your AI app with source control deploys, custom domains, env vars, rollbacks, and logs. +- **Messaging** for email, SMS, and push notifications, useful for approvals, human-in-the-loop flows, and background agent updates. +- **Appwrite MCP servers.** Both the API MCP, which lets coding agents act on your Appwrite resources, and the Docs MCP, which gives agents Appwrite context inside tools like Cursor, Claude Code, Lovable, and Windsurf. +- **Agent Skills** for the Appwrite CLI and every major SDK including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift, so agents generate idiomatic Appwrite code without docs in the prompt. +- **Editor plugins** for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) that bundle the API MCP, Docs MCP, and skills into one install. +- **Self-hosting** under an open-source license, or Appwrite Cloud with the same API surface. + +The positioning is straightforward. Neon owns the database for agents. Appwrite owns the app backend for AI products. + +# Appwrite vs Neon: side by side + +| Capability | Neon | Appwrite | +|---|---|---| +| Database type | Serverless Postgres with separated storage and compute | TablesDB with databases, tables, typed columns, rows, relationships, queries, transactions | +| Auth | Neon Auth (Beta) built on Better Auth; or third-party | First-party Auth with email, OAuth, phone, anonymous, MFA, Teams, roles | +| Storage | Not included; bring your own object storage | Storage with buckets, permissions, antivirus, image transformations | +| Functions | Not included; bring your own runtime | Functions on Node, Python, Go, Ruby, Deno, PHP, and more, with event and CRON triggers | +| Realtime | Data API and branching; no built-in pub/sub channels | Realtime channels for rows, events, and custom channels | +| Hosting | Not included; bring your own host | Sites with deploys, custom domains, env vars, rollbacks, logs | +| MCP, Skills, and editor plugins | Neon MCP Server for projects, branches, SQL, migrations | Appwrite API MCP, Appwrite Docs MCP, Agent Skills for CLI and 10 SDKs, Claude Code and Cursor plugins | +| Self-hosting | Managed cloud; community-driven self-hosting options | Open-source self-hosting with the same API surface as Appwrite Cloud | +| Open source | Core storage and compute open source; product is a managed service | Open-source backend platform across all products | +| Agent features | Instant provisioning, database branching, database-per-tenant, Cursor and Copilot integrations, pgvector | TablesDB for durable agent state, Functions for tool hosting, Realtime for live UI, Storage for RAG sources, MCP for agent access | + +# Where Appwrite fits + +Appwrite is the right pick when: + +- You are building a full AI app, not just an AI feature on top of a database. You need identity, data, files, server-side logic, live updates, notifications, and hosting. +- You want first-party Auth with Teams, roles, MFA, and OAuth from day one, not a beta layer or a third-party dependency. +- You prefer modeling agent state, thread metadata, message history, and tool results as rows in typed tables with relationships and queries. +- You want Functions for LLM tool calls, webhooks, and scheduled jobs on the same platform as your data. +- You want Realtime channels to push tool outputs, agent progress, and row updates to clients without stitching in another service. +- You want coding agents to operate on your backend through a first-party API MCP, Docs MCP, Agent Skills, and editor plugins for Claude Code and Cursor. +- You want to self-host under a standard open-source license or move between Appwrite Cloud and your own infrastructure. + +Neon is the tighter fit when the database itself is the entire job, especially for database-per-tenant workloads or schema-heavy agent flows where instant Postgres provisioning and branching are the point. + +# How teams usually split the decision + +Most AI products that reach users are broader apps where the agent is one feature among many: an AI CRM, an AI writing tool with user uploads, an AI copilot for a SaaS product, or a consumer chat app with files, notifications, and teams. The backend shopping list grows fast: Auth with Teams, file storage, scheduled jobs, webhooks, realtime updates, messaging, hosting, and an MCP your coding agents can drive. That is where Appwrite's breadth shortens the integration work. You do not spend the first month wiring four vendors together before you get to the AI part. + +Data-heavy AI products where Postgres is the entire star, like analytics agents, SQL copilots, or per-tenant AI workspaces, are the narrower case Neon's branching and database-per-tenant model are built for. Even there, Appwrite TablesDB plus Functions covers most app-side workloads without committing to four extra vendors around the database. + +# Backends for AI products come down to primitives + +The useful question for AI backends is not "does this platform market itself to agents?" It is "does this platform give me identity, durable data, storage, server-side logic, live updates, hosting, and a way for coding agents to act on my backend?" + +Neon answers that with one excellent primitive: serverless Postgres for agents, with branching, pgvector, and an MCP that lets agents manage databases. Appwrite answers it with a broader set of primitives: Auth, TablesDB, Storage, Functions, Realtime, Sites, Messaging, and MCP, all under one open-source platform. + +Pick the one that matches your product. If the product is a database an agent can drive, Neon is built for that. If the product is an AI app with users, files, workflows, and a frontend, Appwrite is built for that. + +If you want to explore Appwrite for an AI app backend, start with [Appwrite Cloud](https://cloud.appwrite.io), read the [AI tooling hub](/docs/tooling/ai), and check the [API MCP server](/docs/tooling/ai/mcp-servers/api), [Agent Skills](/docs/tooling/ai/skills), and the editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor). + +- [Appwrite TablesDB](/docs/products/databases) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite AI tooling](/docs/tooling/ai) diff --git a/src/routes/blog/post/appwrite-vs-replit-agent-backend/+page.markdoc b/src/routes/blog/post/appwrite-vs-replit-agent-backend/+page.markdoc new file mode 100644 index 0000000000..f035d3b013 --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-replit-agent-backend/+page.markdoc @@ -0,0 +1,140 @@ +--- +layout: post +title: "Appwrite vs Replit Agent backend: where should production data live?" +description: "Compare Replit Agent's built-in database and services with Appwrite as a backend for Replit Agent apps graduating to production." +date: 2026-05-01 +cover: /images/blog/appwrite-vs-replit-agent-backend/cover.png +timeToRead: 9 +author: atharva +unlisted: true +category: comparisons +--- + +Replit Agent is one of the fastest ways to go from an idea in chat to a running app. You describe the product, the agent writes the code, and a working version shows up in the workspace minutes later. That first stretch is built in, and for many prototypes it is enough. The question this post answers is different: once a Replit Agent app earns paying users or a compliance ask, where should the backend for Replit Agent apps actually live? + +This is a decision piece, not a tutorial. It compares the Replit Agent database and surrounding services with Appwrite as an outside backend that a Replit-built app can grow into. + +# Appwrite vs Replit Agent at a glance + +Replit Agent is an all-in-one AI app builder. Inside Replit, an app gets a built-in SQL database, App Storage for files, Replit Auth or Clerk Auth, Secrets for environment variables, and Publishing for deployments, all orchestrated by the agent. The pitch is speed and cohesion: one workspace, one chat thread, one bill. + +Appwrite is a backend platform. It gives an app [Auth](/docs/products/auth), [databases with tables, rows, and columns](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Realtime](/docs/apis/realtime), [Messaging](/docs/products/messaging), and [Sites](/docs/products/sites), reachable through SDKs, REST APIs, and [official MCP servers](/docs/tooling/ai/mcp-servers/api). It runs on Appwrite Cloud or self-hosted through Docker. + +These are not direct substitutes. Replit Agent owns the builder experience and ships a backend so the generated app can run on day one. Appwrite owns the backend layer and expects the frontend to come from somewhere else, including a Replit Agent build, a Cursor project, or hand-written code. + +# Why the backend question comes up later + +Teams rarely change backends at the prototype stage. The change is usually triggered by a production event: + +- Auth flows need to be decoupled from the builder's identity provider. +- The schema holds customer data and the row-level permission model matters for audits. +- Files are central to the product and need predictable quotas, previews, and access rules. +- Server-side work has outgrown a single function shape and needs multiple runtimes and event triggers. +- The team wants self-hosting for data residency, or open-source code it can fork. + +At that point, the backend for Replit Agent apps is less about scaffolding and more about boundaries. + +# Feature-by-feature comparison + +| Capability | Appwrite | Replit Agent | +| --- | --- | --- | +| Auth | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom token, and OAuth2 across roughly 40 providers, with teams and labels | Replit Auth (sign in with Replit accounts) and Clerk Auth as an integration for independent user accounts | +| Database | Managed typed layer with tables, rows, columns, relationships, queries, indexes, and row-level permissions | Built-in managed SQL database (PostgreSQL-compatible), separate development and production instances, point-in-time restore | +| Storage | Buckets with permissions, image previews and transformations, encryption at rest, and antivirus scanning | App Storage (formerly Object Storage), powered by Google Cloud Storage, with buckets and access policies | +| Functions and compute | Functions with runtimes for Node.js, Python, Ruby, PHP, Deno, Bun, Go, Dart, Swift, Kotlin, Java, C#, and C++, plus scheduled and event triggers | App code runs on Replit compute through Autoscale, Reserved VM, Static, and Scheduled Deployments | +| Realtime | Channel-based subscriptions across databases, Auth, Storage, and Functions | Provided through whatever your app code implements on Replit compute, not a managed realtime service | +| Hosting | Sites for Next.js, SvelteKit, Nuxt, Astro, React, Vue, Remix, TanStack Start, and more, with custom domains, environment variables, rollbacks, logs, and the Appwrite Network | Publishing covers Autoscale, Reserved VM, Static, and Scheduled Deployments with custom domains, monitoring, and private deployments | +| MCP for AI agents | Official MCP servers for the Appwrite API and for Appwrite docs | Replit MCP Server (beta) that lets external MCP clients create, update, and manage Replit Apps | +| Self-hosting | Fully self-hostable through Docker, open source | Replit is a hosted product; apps run on Replit infrastructure | +| Data portability | Standard export paths, open-source runtime, and schema you own | SQL database exports and app downloads are available; data lives inside the Replit platform | + +# Auth for apps built with an AI builder + +Replit Auth is designed to be added to an app with a single Agent prompt. The login page is Replit-branded and users sign in with their Replit accounts, which is useful for developer tools but unusual for consumer products where users do not already have a Replit account. For a branded sign-up experience, Replit recommends Clerk Auth as an integration, which gives an app its own authentication tenant through Clerk. + +Appwrite [Auth](/docs/products/auth) is independent from any builder. It supports email and password, magic URL, email OTP, phone, anonymous sessions, JWTs, custom tokens for existing auth systems, and OAuth2 across roughly 40 providers. Teams and labels give permission rules a place to live that an AI agent can reason about on each request. + +Putting Auth and the database on the same platform keeps access control in one place, which is part of why many teams graduate to a dedicated backend once their user base leaves Replit's orbit. + +# Databases and the schema you own + +Replit Database gives every Replit App a managed SQL database with 10 GB of free storage, a built-in SQL editor, separate development and production instances, and point-in-time restore. Replit Agent can add it to an app and design the schema from a prompt. The underlying engine is PostgreSQL-compatible. + +Appwrite's database is a typed managed layer exposed through [tables, rows, and columns](/docs/products/databases). An AI agent writing against Appwrite picks column types like text, integer, float, boolean, datetime, enum, and relationships, and attaches permissions directly to rows. Queries, pagination, and transactions are available through a consistent SDK surface. + +Replit Database is tied to your Replit App and lives inside the workspace. Appwrite's database lives in a project that multiple frontends, internal tools, and services can reach, in the cloud or on hardware you control. If the goal is to serve a web app today and a mobile app next quarter, an Appwrite project is easier to reuse without renting more of the builder. + +# File storage and media + +Replit App Storage is backed by Google Cloud Storage. It gives buckets, access policies, and programmatic access through JavaScript and Python SDKs, and it integrates with Replit Agent so the builder can configure uploads during the build. + +Appwrite [Storage](/docs/products/storage) provides buckets with row-level permissions, encryption at rest, antivirus scanning, and image previews and transformations. For apps where avatars, document previews, or media thumbnails are part of the interface, the image API removes a step that an Agent-built app would otherwise need a third party for. Both are durable object storage; the split is whether you want the bucket on the same platform as your auth and database, or on the platform that runs the compute. + +# Compute, Functions, and scheduled work + +Replit runs your app code directly. Publishing splits into Autoscale Deployments for variable traffic, Reserved VM for always-on services, Static Deployments for frontend-only apps, and Scheduled Deployments for cron-style jobs. There is no separate "functions" primitive; the app itself is the unit of deployment. + +Appwrite [Functions](/docs/products/functions) is a separate primitive from hosting. Functions support Node.js, Python, Ruby, PHP, Deno, Bun, Go, Dart, Swift, Kotlin, Java, C#, and C++. They can be triggered by HTTP, by events from Auth, databases, Storage, and other services, or on a schedule. Neither Functions nor Sites stream responses, so token-by-token model outputs belong on the client against the model provider. + +The practical difference: on Replit, a scheduled cleanup job shares a runtime with the app. On Appwrite, it lives in a Function with its own runtime, environment variables, and logs, and runs on its own clock without touching the web tier. + +# Realtime and live updates + +Appwrite [Realtime](/docs/apis/realtime) is a managed channel-based layer that broadcasts changes across databases, Auth, Storage, and Functions. An AI agent subscribing to "new rows in this table" uses the same API shape as "files uploaded in this bucket", which keeps live UI generation predictable. + +Replit does not ship a managed realtime service. Apps that need live updates build their own, typically using WebSockets or Server-Sent Events inside the deployed app. That works, and it is also one more piece of code for the AI builder to generate and keep correct as the schema changes. + +# Hosting your AI-generated frontend + +Replit Publishing handles deployment, custom domains, environment variables, logs, and monitoring for apps running on Replit compute. Autoscale and Reserved VM cover most cases, with Static Deployments for frontend-only builds. + +Appwrite [Sites](/docs/products/sites) is a deployment target for frontends across Next.js, SvelteKit, Nuxt, Astro, React, Vue.js, Remix, TanStack Start, Analog, Angular, Vite, and more, plus native targets like Flutter and React Native. Deployments run on source control pushes, with isolated containers, custom domains, environment variables, rollbacks, logs, and traffic served through Appwrite Network. Sites, databases, Auth, Storage, and Functions all live in the same project. + +If the app was born in Replit and will stay there, Publishing is the path of least resistance. If the plan is to move the frontend onto a dedicated framework and bring the backend with it, Appwrite gives you both halves on one platform. + +# MCP and direct agent access + +Replit ships a beta [MCP Server](https://docs.replit.com/platforms/mcp-server) that lets external MCP clients create Replit Apps from a prompt, open an existing app, and manage it through Replit Agent. It turns Replit into a tool another AI client can drive. + +Appwrite ships [official MCP servers](/docs/tooling/ai/mcp-servers/api), one for the API and one for the docs. The API server gives an agent a compact two-tool workflow with automatic service discovery, so Claude Code, Cursor, Windsurf, and similar tools can operate on an Appwrite project through natural language. The docs server keeps an agent grounded in current documentation. On top of that, [Agent Skills](/docs/tooling/ai/skills) cover the Appwrite CLI and every major SDK including TypeScript, Dart, .NET, Go, Kotlin, PHP, Python, Ruby, Rust, and Swift, so coding agents generate idiomatic Appwrite code without you pasting docs into the prompt. Editor plugins for [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) and [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) bundle the MCP servers and skills into a single install. + +Both platforms lean into MCP in different directions. Replit's MCP is about controlling Replit Agent from outside. Appwrite's MCP, skills, and plugins are about letting any agent operate backend resources directly. For a team whose code lives in a local editor, Appwrite's surface fits the existing loop. + +# Self-hosting, open source, and data portability + +Replit is a hosted product. Apps run on Replit infrastructure, databases live inside Replit, and the workspace is the unit of collaboration. For many teams that is fine. For teams with data residency rules or a preference for open-source runtimes, it is a hard fit. + +Appwrite is open source and runs through Docker on a single host, a Kubernetes cluster, or Appwrite Cloud. The same APIs work across every deployment target, so an app can be developed against Appwrite Cloud and moved to a self-hosted instance without changing client code. + +Data portability follows from the same choice. Replit exposes SQL exports and app downloads, but the runtime around the data belongs to Replit. Appwrite gives you the runtime, the schema, and the data together. + +# When Appwrite is the right answer + +Choose Appwrite, either alongside a Replit Agent build or as a full replacement, when: + +- The app is moving from prototype to production and you want backend boundaries that do not depend on the builder. +- You want one platform for Auth, tables, Storage, Functions, Realtime, and hosting, reachable from any frontend and any agent. +- You need multiple server-side language runtimes and event-driven triggers. +- You plan to self-host or need a backend that can be moved between environments. +- You want AI coding tools to talk to the backend through MCP servers, Agent Skills, and editor plugins for Claude Code and Cursor, rather than a builder's workspace. + +Replit Agent is the tighter fit for the prototype phase: a small side project, an internal tool, or a first version of an app that is happy living on Replit compute long term. + +# Using Appwrite with Replit Agent + +These platforms can coexist. A common pattern is to keep the frontend on Replit during the prototype phase, point the generated code at an Appwrite project for Auth, tables, Storage, and Functions, and later move the frontend itself to [Sites](/docs/products/sites) when the team outgrows Replit's runtime. Replit Agent generates UI and client code, and Appwrite owns the durable surface. The [AI tooling hub](/docs/tooling/ai) covers how agents read from and write to Appwrite through SDKs and MCP. + +# Bottom line + +Replit Agent is a builder that happens to include a backend. Appwrite is a backend that works with any builder. For a prototype that needs to ship this afternoon, Replit's bundled stack is hard to beat. For an app that is going to carry customer data, run for years, and be worked on by more than one agent, the backend question benefits from its own answer. Teams searching for a backend for Replit Agent apps tend to reach that point at a predictable version of the product, and Appwrite fits that moment. + +# Further reading + +- [Appwrite Auth](/docs/products/auth) +- [Appwrite databases](/docs/products/databases) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite Sites](/docs/products/sites) +- [AI tooling on Appwrite](/docs/tooling/ai) +- [MCP server for the Appwrite API](/docs/tooling/ai/mcp-servers/api) diff --git a/src/routes/blog/post/appwrite-vs-supabase-ai-apps/+page.markdoc b/src/routes/blog/post/appwrite-vs-supabase-ai-apps/+page.markdoc new file mode 100644 index 0000000000..054da7fa6d --- /dev/null +++ b/src/routes/blog/post/appwrite-vs-supabase-ai-apps/+page.markdoc @@ -0,0 +1,133 @@ +--- +layout: post +title: "Appwrite vs Supabase for AI app builders" +description: "Appwrite vs Supabase AI: compare Auth, databases, Storage, Functions, Realtime, Sites, MCP, and self-hosting for AI-generated apps." +date: 2026-04-27 +cover: /images/blog/appwrite-vs-supabase-ai-apps/cover.png +timeToRead: 8 +author: aditya-oberai +unlisted: true +category: comparisons +--- + +If you are shipping an application built partly or entirely by an AI coding agent, the backend choice you make in the first hour tends to stick for months. Lovable, Bolt, Cursor, Claude Code, and similar tools produce working UI quickly, but the moment your app needs accounts, durable data, file uploads, scheduled work, and public hosting, the backend becomes the thing your agent talks to on every turn. Appwrite vs Supabase AI is the comparison most teams run when they decide where those backend primitives will live. + +This article looks at Appwrite as a Supabase alternative for AI apps, focused on the primitives that matter when an AI builder generates your code: Auth, structured data, Storage, Functions, Realtime, hosting through Sites, agent access through MCP, and self-hosting. + +# Appwrite vs Supabase AI at a glance + +Both Appwrite and Supabase are open-source backend platforms with managed cloud offerings and supported self-hosting. Both give an AI coding agent a single surface for identity, persistent data, files, server-side code, live updates, and (in Appwrite's case) deployment. The shape of each platform is what differs. + +Appwrite presents a unified suite: [Auth](/docs/products/auth), [databases with tables, rows, and columns](/docs/products/databases), [Storage](/docs/products/storage), [Functions](/docs/products/functions), [Realtime](/docs/apis/realtime), and [Sites](/docs/products/sites) for hosting full-stack frameworks. All of it is reachable through a consistent set of SDKs and through [Appwrite's MCP servers for the API and docs](/docs/tooling/ai/mcp-servers/api). The platform enforces permissions at the row level so AI-generated client code does not have to guess. + +Supabase wraps Postgres with generated REST and GraphQL APIs, Auth, Storage, Realtime, and Edge Functions. It leans into direct SQL access, Row Level Security policies, and pgvector for embeddings. Supabase also ships an official MCP server so AI tools can query and manipulate a project on your behalf. The shape favors developers who want Postgres as the source of truth and are comfortable with SQL and policy code, including when that code comes from an agent. + +# Why the backend matters for AI-generated apps + +AI app builders are good at producing screens, routes, and component logic. They are less consistently good at durable schema design, modeling permissions so a logged-in user cannot read another user's rows, wiring server-side logic, choosing a file storage model with the right access rules, and hosting the finished app. A backend that gives these primitives clear names, predictable APIs, and an MCP interface reduces the surface where an agent can invent something wrong. + +# Feature-by-feature comparison + +| Capability | Appwrite | Supabase | +| --- | --- | --- | +| Data model | Typed tables, rows, and columns with a managed schema | Postgres tables accessed through generated APIs and direct SQL | +| Row-level permissions | Built-in permissions on rows and resources, enforced by the platform | Row Level Security policies authored in SQL | +| Auth methods | Email and password, magic URL, email OTP, phone, anonymous, JWT, custom token, OAuth2 across roughly 40 providers | Email and password, magic link, OTP, phone, anonymous, OAuth, SAML SSO | +| File storage | Buckets with permissions, previews, transformations, and encryption | Object storage with RLS-style policies and image transformations on paid plans | +| Server-side code | Functions with multiple language runtimes and scheduled executions | Edge Functions running on Deno | +| Realtime | Channel-based subscriptions across databases, auth events, files, and functions | Postgres changes, broadcast, and presence channels | +| Hosting frontends | Sites for deploying Next.js, SvelteKit, Nuxt, Astro, React, Vue, Remix, TanStack Start, and other frameworks | Hosting handled outside Supabase, typically on Vercel, Netlify, or similar | +| Vector search and embeddings | Supported through database columns and example patterns in the AI tooling docs | First-class pgvector integration with embedding generation in Edge Functions | +| MCP for AI agents | Official [MCP servers for API and docs](/docs/tooling/ai) | Official MCP server for Supabase projects | +| Self-hosting | Fully self-hostable, Docker-based, open source | Self-hostable via Docker, open source | + +# Auth for AI-generated apps + +Auth is the primitive an AI agent trips over most often. It needs to register users, sign them in, attach identities to data, and respect permissions on every call. + +Appwrite [Auth](/docs/products/auth) covers email and password, magic URL, email OTP, phone, anonymous sessions, JWTs, custom tokens for existing auth systems, and OAuth2 with around 40 providers. Teams and labels give AI-generated permission rules a stable place to live. + +Supabase Auth supports email and password, magic link, OTP, phone, anonymous sign-in, OAuth, and SAML 2.0 for enterprise SSO. Access control is expressed through Row Level Security policies written in SQL. The quality of AI-generated policies depends on how well the agent understands Postgres RLS, which is a reasonable bet for Supabase-trained tools such as Lovable and less so for general-purpose agents. + +The question is whether you want permissions to live as a typed declaration on the row (Appwrite) or as a Postgres policy (Supabase). Both are valid, but the first is easier to verify by reading a single page of generated code. + +# Databases, tables, rows, and columns + +Appwrite's database is a typed layer exposed through tables, rows, and columns. Your AI agent defines the schema, picks column types including text, integer, float, boolean, datetime, enum, and relationships, and attaches permissions directly to rows. Queries, offset and cursor pagination, and transactions are exposed through a consistent SDK surface, which gives an agent fewer ways to go wrong. + +Supabase gives you Postgres: full SQL, joins, extensions, views, triggers, and functions, plus pgvector for embeddings. The auto-generated REST and GraphQL layer lets an agent call the database without writing SQL for simple cases, and drop down to SQL when needed. This is powerful, and it is also where AI-generated code most often strays: agents sometimes write policies that look correct but leak rows, or build queries that ignore indexes. + +If your AI workflow needs a schema the agent can introspect safely and a permission model that does not require reviewing hand-rolled SQL, Appwrite is easier to supervise. If your team wants Postgres as the foundation and has review bandwidth for SQL-heavy output, Supabase fits. + +# Storage and file handling + +Appwrite [Storage](/docs/products/storage) provides buckets with row-level permissions, encryption at rest, antivirus scanning, and built-in image previews and transformations. An AI agent generating an avatar upload flow can request a resized preview URL directly from the SDK. + +Supabase Storage is object storage with policies similar to its database RLS model. Image transformations are available on the Pro plan and above. For AI-generated apps that need previews and thumbnails on the free tier, Appwrite's image API removes a step. + +# Functions, scheduled jobs, and background work + +Server-side code is where AI agents most need guardrails: it touches secrets, third-party APIs, and the database with elevated privileges. + +Appwrite [Functions](/docs/products/functions) supports language runtimes including Node.js, Python, Ruby, PHP, Deno, Bun, Go, Dart, Swift, Kotlin, Java, C#, and C++. Functions can be triggered by HTTP, by events from Auth, databases, Storage, and other services, or on a schedule. Neither Functions nor Sites support streaming responses, so token-streaming agent workflows belong on the client against an external model provider. + +Supabase Edge Functions run on Deno at the edge, triggered by HTTP. Scheduling uses Postgres extensions like pg_cron. Deno is a reasonable runtime, though the single-language constraint can steer an agent away from Python AI libraries it might otherwise reach for. + +# Realtime and live updates + +Appwrite [Realtime](/docs/apis/realtime) broadcasts changes across databases, Auth, Storage, and Functions on a unified channel model, so an agent subscribing to "new rows in this table" uses the same API shape as "files uploaded in this bucket". The docs also describe [persistent agents with Realtime](/docs/tooling/ai) for live agent state. + +Supabase Realtime covers Postgres changes, broadcast, and presence. Postgres Changes is tightly coupled to replication, which is a clean fit when your agent is thinking in tables and rows, and less clean when it wants to react to an auth or storage event. + +# Hosting your AI-generated frontend + +This is where Appwrite and Supabase diverge most. Appwrite [Sites](/docs/products/sites) is a deployment target for frontends across Next.js, SvelteKit, Nuxt, Astro, React, Vue.js, Remix, TanStack Start, Analog, Angular, Vite, and more, plus native targets like Flutter and React Native. Deployments run on source control pushes, with isolated containers, custom domains, environment variables, rollbacks, logs, and traffic served through Appwrite Network. The same platform that stores your data can serve the generated UI, without an extra hosting contract. + +Supabase does not offer frontend hosting. Teams typically pair it with Vercel, Netlify, Cloudflare Pages, or a self-hosted setup. That is a normal split, and it is one more integration for the agent to keep in its head. + +# MCP and direct agent access + +Appwrite ships [official MCP servers](/docs/tooling/ai/mcp-servers/api), one for the API and one for the docs. The API server uses a compact two-tool workflow with automatic service discovery so an agent can operate on your Appwrite project through natural language. The docs server keeps an agent grounded in current Appwrite documentation rather than training-data memories. + +Supabase also ships an official MCP server for projects, with read-only mode, project scoping, and feature-group toggles. For both platforms, the upshot is the same: an AI coding tool can read and change your backend without hand-written glue code. The difference is surface area. Appwrite's MCP touches a wider set of primitives, including Sites and Functions deployments; Supabase's MCP is focused on the database and project operations. + +# Self-hosting and open source + +Both platforms are open source and Docker-friendly. Appwrite is a single docker-compose deployment that brings up the full stack. Supabase self-hosting uses Docker Compose with separate containers for Postgres, Auth, Storage, Realtime, and Edge Functions. + +For AI-generated apps handling regulated data, self-hosting is the honest answer to most compliance questions. If you plan to self-host and also want your hosting layer under the same roof, Appwrite's Sites gives you one fewer service to operate. + +# Vector search for RAG and embeddings + +Supabase leans into pgvector. Its [AI and Vectors guide](https://supabase.com/docs/guides/ai) covers semantic and hybrid search, embedding generation in Edge Functions, and integrations with LangChain, Hugging Face, and LlamaIndex. For retrieval-augmented features, this is a well-trodden path. + +Appwrite handles vectors through Functions. The [AI tooling hub](/docs/tooling/ai) covers documented integrations with Pinecone, Weaviate, Milvus, Qdrant, Chroma, and Upstash Vector, with embedding metadata stored in TablesDB rows that link back to your application data through relationships and queries. + +# When to pick Appwrite + +Choose Appwrite if: + +- You want one platform covering Auth, tables, Storage, Functions, Realtime, and hosting for your AI-generated frontend, all addressable through an MCP server. +- You prefer typed tables, rows, and columns with platform-enforced permissions over hand-written SQL policies. +- You want multiple server-side language runtimes so your agent can reach for Python, Node.js, Go, or others as needed. +- You plan to self-host and want the frontend hosting layer included. +- You need image transformations on the free tier. + +# When Supabase is the tighter fit + +Supabase is the more natural pick when Postgres is a hard requirement and your team is comfortable owning schemas, SQL, and RLS policies generated by an AI agent. pgvector and SQL-first retrieval being central to your AI workload, or needing SAML SSO out of the box, also point that way. Appwrite covers the same backend ground for teams that prefer typed tables, platform-enforced row permissions, broader runtime choice in Functions, and Sites for hosting under one roof. + +# Bottom line + +Neither Appwrite nor Supabase does model inference for you; both plug into OpenAI, Anthropic, Hugging Face, and the rest through HTTP calls from server-side code. The question is which one gives your agent fewer places to get lost. Appwrite's answer is a unified surface with typed primitives and hosting built in. Supabase's answer is Postgres with generated APIs and edge functions. Either can back a successful AI-generated app; the choice is mostly about where you want your agent to spend its context budget. + +# Further reading + +- [Appwrite Auth](/docs/products/auth) +- [Appwrite databases](/docs/products/databases) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite Sites](/docs/products/sites) +- [AI tooling on Appwrite](/docs/tooling/ai) +- [MCP server for the Appwrite API](/docs/tooling/ai/mcp-servers/api) diff --git a/src/routes/blog/post/backend-checklist-vibe-coded-apps/+page.markdoc b/src/routes/blog/post/backend-checklist-vibe-coded-apps/+page.markdoc new file mode 100644 index 0000000000..17d85f0829 --- /dev/null +++ b/src/routes/blog/post/backend-checklist-vibe-coded-apps/+page.markdoc @@ -0,0 +1,158 @@ +--- +layout: post +title: "The backend checklist for vibe-coded apps before launch" +description: "The vibe coding backend checklist: auth, permissions, tables, files, secrets, logs, domains, backups, and AI-generated code review before launch." +date: 2026-04-25 +cover: /images/blog/backend-checklist-vibe-coded-apps/cover.png +timeToRead: 9 +author: atharva +unlisted: true +category: best-practices +--- + +Vibe coding gets you from idea to working prototype faster than any previous workflow. You describe a product, an AI builder assembles the UI, calls an API, and renders something usable on the first preview. The shipping question comes later: what does the backend for a vibe-coded app need before it meets users? + +This is the vibe coding backend checklist. It is a pre-launch review you can run before your app handles a login, a payment, or a file upload. It assumes your frontend works and focuses on the backend primitives that decide whether your launch holds up. + +If you use Appwrite behind a vibe-coded app, the primitives here map to Auth, Databases with tables and rows, Storage, Functions, Sites, and Appwrite Network. The checklist applies regardless of which tool generated your code: Lovable, Bolt, v0, Cursor, Claude Code, Replit, or Windsurf. + +# Why vibe-coded apps need a production checklist + +AI builders are optimized to produce something demo-ready. They generate UI, stub data layers, and reach for the default backend integration the tool ships with. Lovable leans on Lovable Cloud and Supabase. Bolt promotes Bolt Cloud Database with Supabase as another option. Replit assembles apps inside the Replit runtime. v0 outputs React components wired to whatever you ask it to call. + +None of these tools run the production review for you. If you skip it, the cracks show up in predictable places: open table permissions, secrets in the client bundle, missing indexes on hot queries, no logs to debug the first incident, and a custom domain still pointing at a preview URL. + +The vibe coded app production checklist that follows is structured around the primitives that matter at launch. + +# Auth + +Auth is where most vibe-coded apps leak first. The UI looks finished and the signup flow works on the demo account, so the assumption is that the rest will follow. + +- Decide which identity methods you support (email and password, magic URL, email OTP, OAuth, phone OTP, anonymous) and remove every flow you do not. +- Turn on email verification if your app stores anything tied to identity. +- Require a minimum password length and block common passwords at signup. +- Configure session length and make sure you can revoke a session if a user asks. +- Offer multi-factor authentication for accounts that reach admin or billing functionality. Appwrite supports TOTP-based MFA on the account. +- Test the password recovery flow end to end on a working inbox, not the AI builder's preview mailer. +- If you use OAuth, register production callback URLs and remove any dev URLs from the provider config. +- Rate limit signup, login, and password reset endpoints so nobody can brute force them. +- Remove any test accounts your AI tool created during prototyping. + +# Permissions + +Permissions are the single biggest failure mode in AI-generated backends. Generated code often writes to a table from the client with whatever role the signed-in user has, without narrowing to the row the user owns. + +- Review every table and confirm read and write permissions are scoped to the right roles. Default deny, then add the minimum. +- Check row-level permissions for any table that stores per-user data (profiles, orders, messages, uploads). +- Confirm that file buckets do not allow public uploads unless the product requires them. +- For collaboration features, use Appwrite Teams or roles rather than broadening table access. +- If an AI builder inserted a shared admin key into the client code, remove it. Admin calls belong in a server-side Function. +- Run a spot check: sign in as user A, try to read and mutate user B's rows. You should fail. + +# Tables, rows, and columns + +Schema quality decides how painful the next six months will be. Vibe-coded apps tend to over-index on speed. + +- Review every table your app uses and delete the ones your code no longer touches. +- Confirm column types match what the app writes. Use integer, float, boolean, datetime, enum, email, URL, IP, or relationship types where they apply, not a freeform text column for everything. +- Add required flags to columns the app needs. +- Add defaults for columns that should never be null. +- Create indexes on the columns you filter, sort, or paginate on. One missing index can turn a snappy list view into a timeout once traffic hits. +- Enforce uniqueness where the product demands it (handle, slug, invoice number). +- Review relationships between tables and confirm the on-delete behavior you want, not the default the generator chose. +- If the AI tool introduced soft-delete or status columns, document what each value means so future you and future agents can reason about them. + +# Files + +File handling is the second most common source of production surprises. Uploads look fine until a user sends a 50 MB image from a phone, or a script pushes an executable. + +- Limit allowed file extensions per bucket to the types your product needs. +- Set a sensible maximum file size per bucket. The default is usually too permissive. +- Turn on antivirus scanning on buckets that accept user uploads. Appwrite buckets expose this as a per-bucket flag. +- Enforce encryption for buckets holding sensitive documents. Appwrite buckets expose this as a per-bucket flag. +- Decide who can preview, download, and delete. File read permissions are separate from table read permissions. +- If your app shows user avatars or covers, confirm the preview transformations you rely on work with the formats you accept. +- Audit any signed URLs your code issues and keep their lifetime as short as your UX allows. + +# Secrets + +AI code generation is risky with secrets because the model has no strong prior against pasting a key into a component file. + +- Search your repo for hard-coded API keys, project secrets, database URLs, and webhook signing keys. Move all of them to server-side environment variables. +- Confirm that provider keys for your LLM, payments, email, and SMS vendors live on a server-side Function, not in the browser bundle. +- Rotate any key that was ever pasted into a chat with a cloud-hosted AI tool. +- Use separate keys for development, staging, and production. +- Scope your backend API keys to the minimum set of permissions the calling code needs. +- If your AI builder committed `.env` to git at any point, assume every key in it is compromised. + +# Server-side logic + +Anything that touches money, third-party APIs, or sensitive data belongs on the server. Vibe-coded apps often inline this logic into the client because the generator did not push back. + +- Move payment initiation, LLM calls, webhook handling, and admin actions into server-side Functions. +- Validate every input a Function receives. Never trust data because it came from your own UI. +- Set execution timeouts that match the work the Function does. A webhook handler does not need ten minutes. +- Configure the runtime version explicitly. Do not rely on the default drifting under you. +- Review every event trigger and confirm you want the Function to fire on it. +- Handle errors and return useful status codes. Silent failures in generated code are common. + +# Logs and observability + +You cannot debug what you cannot see, and the first time you need logs is always worse than any later one. + +- Enable execution logs for every Function that runs in production. +- Decide on a log retention window that matches your compliance needs. +- Add at least one log line per meaningful branch: success, validation error, downstream error. +- Confirm auth audit events are accessible so you can investigate suspicious sign-ins. +- If you run on Appwrite Sites, check that deployment logs and request logs are reachable from your console. +- Set up a basic alert for error spikes. A weekly email is better than no alert at all. + +# Custom domains and hosting + +Vibe-coded apps often launch on the generator's preview domain. That is fine for sharing, not for production. + +- Register the production domain you want users to remember. +- Attach the custom domain to your site and confirm SSL is issued. +- Redirect the preview domain to the custom domain so old links keep working. +- Configure environment variables per environment (production, staging, preview). Do not reuse production keys in preview. +- Confirm rollbacks are one click away. The first production incident is not the time to learn your rollback story. Appwrite Sites lets you activate a previous deployment as the current one. +- If you use Appwrite Sites, verify your site is reaching users through Appwrite Network so latency is acceptable globally. + +# Backups and data recovery + +Backups are where vibe-coded apps feel the biggest gap between prototype and product. The moment your UI lets a user delete something, you need a story for getting it back. + +- Understand your backend's backup cadence and retention period. Write it down where your team can see it. +- Test restoring from a backup into a staging project at least once before launch. +- For tables holding irreplaceable data (orders, messages, contracts), add a soft-delete pattern so a misclick does not require a restore. +- Export a snapshot of critical tables before any schema migration generated by an AI tool. +- Keep a runbook for the three most likely data incidents: accidental mass delete, bad migration, compromised admin key. + +# AI-generated code review + +Code an AI builder generates is a first draft that needs the same review you would give a teammate. + +- Read every server-side Function the generator produced. If you would not merge it from a teammate, do not ship it. +- Look for inputs that go straight from request body to database without validation. +- Look for authentication checks that are missing, commented out, or stubbed with a TODO. +- Look for SQL-like queries built with string concatenation where your backend expects structured query objects. +- Look for secrets that ended up in client code, config files, or example payloads. +- Look for unused endpoints and delete them. Dead code the agent generated is an attack surface. +- If you used a docs MCP server during generation, re-run the agent with the updated checklist above and ask it to flag anything it missed. + +# The pre-launch review, in order + +If you only have one hour before launch, run the list in this order: + +1. Secrets out of the client. +2. Table, row, and file permissions closed down to owner-only where applicable. +3. Custom domain attached with SSL. +4. Auth flows tested on a working email inbox. +5. Logs enabled on every production Function. +6. Backup cadence confirmed and one restore tested in staging. +7. Rollback path confirmed. +8. AI-generated Functions read end to end. + +Vibe coding is the fastest way from prompt to product, and the backend is where the leverage to keep that speed lives. Appwrite covers the primitives this checklist cares about: Auth with OAuth, sessions, MFA, and Teams; Databases with tables, rows, relationships, and indexes; Storage with per-bucket limits, encryption, and antivirus; Functions for server-side logic; Sites with custom domains, env vars, rollbacks, and logs; and MCP so coding agents can operate your project safely. + +Run this checklist before your next launch. The one after is the one you can sleep through. diff --git a/src/routes/blog/post/best-backend-for-lovable-apps/+page.markdoc b/src/routes/blog/post/best-backend-for-lovable-apps/+page.markdoc new file mode 100644 index 0000000000..ea60f6aa66 --- /dev/null +++ b/src/routes/blog/post/best-backend-for-lovable-apps/+page.markdoc @@ -0,0 +1,161 @@ +--- +layout: post +title: "The best backend for Lovable apps: what to look for beyond the default integration" +description: "Picking the best backend for Lovable apps means looking past the default integration. Here is what to evaluate for auth, data, storage, functions, and hosting." +date: 2026-04-25 +cover: /images/blog/best-backend-for-lovable-apps/cover.png +timeToRead: 9 +author: aishwari +unlisted: true +category: ai +--- + +Lovable is one of the easiest ways to get a working app out of an AI chat. You describe what you want, it scaffolds the UI, and when you reach for a backend the obvious path is the native Supabase integration. That path works, and Lovable's own docs walk you through it in a few clicks. The question this article tries to answer is different: if you care about what runs behind your Lovable app once users show up, what is the best backend for Lovable apps, and how do you look at it beyond whatever the default integration hands you? + +This is a decision guide, not a setup tutorial. It is written for founders, agencies, and developers who either picked Lovable for speed and now want to be deliberate about the backend, or who are evaluating Lovable and want to understand the backend options before they commit. + +**What you'll learn:** + +- Why the default backend for Lovable apps is not the only answer +- A checklist of what to evaluate in a lovable backend before launch +- How Appwrite fits as a backend for Lovable apps through docs MCP, SDKs, and APIs +- What to consider if you self-host or want to own your data + +# Why "the default" is a starting point, not a decision + +Lovable's Supabase integration is well-designed. Connect an account, pick a project, and Lovable can scaffold tables, auth screens, file uploads, realtime, and Edge Functions through chat. For a weekend build or a first prototype, that is enough. + +Treating that integration as the backend decision, however, skips several questions that matter once the app is not a prototype: + +- Do you want the backend and the app builder owned by separate vendors, so you can change one without rewriting the other? +- Do you want the option to self-host the backend later, or keep your data in a managed service that you do not operate? +- Do you want the backend to expose primitives your team already understands, rather than ones your AI editor defaults to? +- Do you want a backend you can drive from other tools, SDKs, and agents, not only from inside Lovable's chat? + +None of these are arguments against Supabase. They are arguments for evaluating the backend on its own merits instead of inheriting it because it was the easy button in a different product. + +# The checklist: what to look for in a lovable backend + +Use this as a worksheet. Each item is a question to ask of any backend you are considering for a Lovable app, including the default. + +## 1. Authentication that covers your sign-in flows + +A Lovable backend needs more than a demo sign-in screen. Look for: + +- Email and password sign-up with confirmation flows you can enable or disable per environment +- Social logins for the providers your users actually use +- Sessions, tokens, and logout flows that do not force you to hand-roll security +- Multi-factor options, team or organization membership, and the ability to model roles + +If the backend treats auth as a first-class product rather than a library you assemble, you save weeks of work once you move past the prototype. + +## 2. A data model you can reason about + +Lovable's chat will happily generate a schema for you. The question is what that schema lives on. For structured app data you want: + +- Clear primitives for tables, columns, rows, and relationships +- Row-level access rules you can inspect, not just trust +- Indexes and queries that scale past a hundred rows +- A way to review and change the schema without going through a chat prompt every time + +If the only way to reason about your data is inside an AI builder, you will hit the ceiling of that builder every time something unusual happens. + +## 3. File storage with permissions, not just a bucket + +Most apps end up uploading something. Profile photos, documents, generated images, invoices. A lovable backend should give you: + +- File uploads with size and MIME limits +- Permissions attached to files or buckets, not only to the table row that references them +- CDN-backed delivery or signed URLs so uploads stay fast as traffic grows + +A bucket on its own is not enough. You want rules that outlive the first developer on the project. + +## 4. Server-side logic you control + +AI-generated client code will not cover everything. You will eventually need server-side logic for things like verifying webhooks, calling a payment provider, or talking to a model with a private key. Look for: + +- A functions product with a language and runtime your team is comfortable with +- Secrets and environment variables that live on the server, not in the client bundle +- Logs and execution history you can read without attaching a debugger +- The ability to run scheduled jobs and respond to events from the rest of the platform + +Note that most serverless function products, including Appwrite Functions, return complete HTTP responses rather than streamed output. If you are building something that needs token-by-token streaming from a model, plan for that at the client or proxy layer. + +## 5. Realtime that the rest of the app can lean on + +Live dashboards, chat UIs, presence indicators, and collaborative editors all rely on realtime updates. A lovable backend should let the client subscribe to data changes without you standing up a separate message bus. + +## 6. Hosting with the knobs you need in production + +If your Lovable frontend has to live somewhere, the hosting layer is part of the backend decision. Check for: + +- Source control deploys +- Custom domains and HTTPS +- Environment variables per environment +- Rollbacks, logs, and a way to see what a deploy changed +- A network that places your app close to users + +If the backend and the hosting surface are separate vendors, that is fine, but you should know what you are signing up for on both sides. + +## 7. Agent access through MCP + +This is the item most checklists miss. If your team uses Lovable, there is a good chance you use other AI tools too, and those tools work better when they can read accurate context about your backend. Look for: + +- A docs MCP server so agents can reason about the backend from current documentation +- An API MCP server so agents can inspect and act on your project resources when you want them to +- Clear scopes and keys so you can decide what an agent is allowed to touch + +An agent that can read your backend's docs live will produce better code than one guessing from a training snapshot. + +## 8. Ownership and exit path + +Finally, the boring question that decides a lot of later decisions: if in a year you want to move, can you? A lovable backend worth choosing should give you: + +- Data you can export in a useful format +- A self-hostable option, or at least a documented path off the managed service +- Open-source components that do not disappear if the vendor pivots + +This is not about distrusting any particular provider. It is about making sure your app's backend is not a one-way door. + +# How Appwrite fits as a backend for Lovable apps + +Appwrite is an open-source backend platform that covers the categories above, and it can be used as a backend for Lovable apps without being the default integration inside Lovable's chat. Instead of an in-chat connector, the integration happens through docs context, SDKs, and APIs. + +Here is how the pieces line up against the checklist. + +**Auth.** Appwrite Auth handles email and password, OAuth providers, sessions, MFA, and teams for roles and membership. You get tested flows instead of generated scaffolding. + +**Databases.** Appwrite Databases use databases, tables, rows, and columns, with relationships, queries, and permissions at the table and row level. Schemas are explicit resources you can inspect and change outside of any chat. + +**Storage.** Appwrite Storage provides buckets with permissions, file-level rules, and CDN-backed delivery. + +**Functions.** Appwrite Functions run server-side code in multiple languages, with environment variables, logs, executions, and schedules. They do not stream responses, so plan for a proxy if you need streaming. + +**Realtime.** Appwrite Realtime lets clients subscribe to changes in tables, files, functions, and other resources so live features do not need a separate service. + +**Sites.** Appwrite Sites gives you source-control deploys, custom domains, environment variables, rollbacks, logs, and delivery through the Appwrite Network. + +**MCP.** Appwrite ships two MCP servers that matter for Lovable users. The docs MCP server connects to Lovable as a custom chat connector, via Connectors, Chat connectors, and New MCP server, pointing at `https://mcp-for-docs.appwrite.io`. The API MCP server lets other AI tools act on Appwrite resources with a project ID and API key. + +**Ownership.** Appwrite is open source. You can use Appwrite Cloud or self-host, which keeps the exit path open. + +In practice, a Lovable team using Appwrite as their backend works like this: build the UI in Lovable, connect the Appwrite docs MCP server inside Lovable's personal connectors so the chat has accurate Appwrite context, and wire the generated frontend to Appwrite through the web SDK. Heavier work such as schema changes, server-side logic, and deploys happen through the Appwrite console, SDKs, CLI, or other AI tools configured with the Appwrite MCP servers. + +# A pragmatic way to choose + +If you already shipped a Lovable app on Supabase and it is working, you do not need to rip it out. Use the checklist to audit what you have: are your permissions explicit, are your secrets on the server, do you have a deploy surface with logs and rollbacks, can your AI tools read your backend's docs through MCP? + +If you are starting a new Lovable app and you want the backend to outlive any one AI builder, evaluate Appwrite against the same checklist. You get auth, databases, storage, functions, realtime, and hosting from one platform, two MCP servers that make your backend legible to AI tools, and an open-source foundation you can self-host if you ever need to. + +Either way, the best backend for Lovable apps is the one you chose on purpose, not the one a chat prompt picked for you. + +# Further reading + +- [Appwrite AI tooling overview](/docs/tooling/ai) +- [Appwrite docs MCP server in Lovable](/docs/tooling/ai/ai-dev-tools/lovable) +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [Appwrite Realtime](/docs/apis/realtime) diff --git a/src/routes/blog/post/lovable-appwrite-backend-pairing/+page.markdoc b/src/routes/blog/post/lovable-appwrite-backend-pairing/+page.markdoc new file mode 100644 index 0000000000..3767341267 --- /dev/null +++ b/src/routes/blog/post/lovable-appwrite-backend-pairing/+page.markdoc @@ -0,0 +1,141 @@ +--- +layout: post +title: "Lovable and Appwrite: a practical backend pairing for AI-generated apps" +description: "How Lovable users can pair Appwrite as the backend for AI-generated apps, with Auth, tables, permissions, Storage, and Functions." +date: 2026-04-26 +cover: /images/blog/lovable-appwrite-backend-pairing/cover.png +timeToRead: 8 +author: aditya-oberai +unlisted: true +category: ai +--- + +Lovable turns a prompt into a working UI in minutes. The front end is the easy part. The part that decides whether an AI-generated app ships is the backend: where user accounts live, how rows get stored and permissioned, where files land, and which server-side logic runs on a schedule or on demand. This post looks at pairing Lovable with Appwrite, so the speed of AI generation sits on top of a backend platform you can host, audit, and grow into. + +The Lovable documentation frames backend as a connected service. The Supabase integration page describes a "hosted PostgreSQL database with real-time capabilities, user authentication, file storage, and serverless functions" that gets attached to your Lovable project. That framing is the right mental model. Swap the default for a different backend, and the generation workflow still works. Appwrite fits this pattern as an open-source option that brings Auth, Databases with tables and rows, Storage, Functions, Realtime, Messaging, and Sites under one roof. + +## Why pair Lovable and Appwrite + +The Lovable and Appwrite combination is worth considering when any of these matter to your project: + +- You want an open-source backend you can self-host or run on Appwrite Cloud. +- You want Auth, data, files, permissions, server-side logic, and hosting in one platform instead of stitching several services together. +- You want your AI coding tools, including Lovable, to have accurate context on your backend through docs and MCP. +- You want to keep production data portable, with clear APIs and SDKs you can reach from any frontend Lovable generates. + +Appwrite already publishes a Lovable integration page in its docs. It covers connecting the Appwrite docs MCP server to Lovable, so the assistant can answer Appwrite questions with current documentation context. The setup lives under Lovable's personal connectors: server name `Appwrite Docs`, server URL `https://mcp-for-docs.appwrite.io`, no authentication. Once it is added, Lovable can respond to prompts like "how do I set up real-time subscriptions in Appwrite" or "show me an example of using Appwrite Functions" with accurate, documentation-grounded answers instead of guesses. + +## What Appwrite gives a Lovable app + +Lovable handles the generation loop: prompts, pages, components, state, and styling. Appwrite covers the backend side of the same app. The mapping below is useful when planning what to build in Lovable and what to stand up in Appwrite. + +| App need | Appwrite product | What it does | +| ------------------------- | ---------------- | ---------------------------------------------------------------------------- | +| Identity and sessions | Auth | Email and password, OAuth providers, MFA, sessions, teams, roles | +| Structured data | Databases | Tables, columns, rows, relationships, queries, indexes, transactions | +| Files and media | Storage | Buckets, file uploads, image transforms, signed URLs, permissions | +| Server-side logic | Functions | Scheduled and event-triggered code with secrets and logs | +| Live updates | Realtime | Subscriptions to changes on rows, files, and account events | +| User messaging | Messaging | Email, SMS, and push providers with topics and targets | +| Deployment | Sites | Source control deploys, isolated containers, domains, env vars, rollbacks | +| Agent access | MCP | API MCP for live project actions and docs MCP for knowledge context | + +The point of this table is not to claim feature parity with any other backend, but to show that Appwrite covers the services a generated app needs after the first prompt. + +## Designing the backend before you prompt + +Lovable is happy to invent backend shapes on the fly. That is fine for prototypes. It becomes expensive when you want to deploy to users, because the generated schema, permission rules, and storage assumptions tend to drift. Treating Appwrite as the source of truth reverses the flow: you define the backend, then Lovable generates UI against it. + +A minimal, non-code plan looks like this: + +1. In Appwrite, create a project and the tables your app needs. Use columns that match the data type you expect, such as text for names, integer or float for numeric fields, datetime for timestamps, boolean for flags, and relationships for parent and child rows. Avoid the deprecated `string` type. +2. Set row-level and column-level permissions based on roles. Appwrite supports roles like `users`, `teams`, and specific user IDs, which maps cleanly to the access patterns a typical Lovable app needs. +3. Create a Storage bucket for any user uploads, with permissions that match the table that references the files. +4. If the app needs secrets such as a payments key or a model provider key, keep them on a Function and expose only the endpoints the UI needs. Never store those keys in the generated client. +5. Decide whether the frontend runs on Appwrite Sites or on another host. Sites gives you source control deploys, isolated containers, custom domains, env vars, rollbacks, logs, and the Appwrite Network for global delivery. + +Once those pieces exist in Appwrite, Lovable's job is simpler. It generates screens and flows that call the backend you already defined, which is easier for any AI tool to reason about than inventing a backend in the same loop. + +## Using Lovable with the Appwrite docs MCP + +Connecting Lovable to the Appwrite docs MCP server is the lowest-effort way to make generated code match Appwrite's actual APIs. In Lovable, open Settings, go to Connectors, open Personal connectors, click New MCP server, and add the Appwrite Docs server listed earlier. After the connector is added, Lovable's assistant can pull from Appwrite documentation when answering questions, writing code, or explaining a flow. + +This matters for two reasons. First, it reduces the class of mistakes where the assistant invents outdated method names or parameter shapes. Second, it lets you ask high-level questions inside Lovable and get answers that reference Appwrite concepts correctly, such as how permissions compose on a row, how queries work across relationships, or how to trigger a Function on a row creation event. + +## Authentication, the way Lovable users need it + +Auth is where most AI-generated apps first run into trouble. Lovable can generate login screens, sign-up forms, and protected routes quickly, but those flows only work in production if the backend handles sessions, password resets, OAuth callbacks, MFA, and account recovery correctly. + +Appwrite Auth handles that side end to end: + +- Email and password accounts with server-issued sessions. +- OAuth providers with a consistent callback pattern. +- MFA with multiple factor options. +- Teams and roles for grouping users and driving permissions. +- Account recovery flows for email verification and password reset. + +From Lovable's perspective, this is a set of SDK calls against Appwrite. Once Auth is wired, the rest of the generated UI can rely on the current user and their team memberships to decide what to show. + +## Tables, rows, and permissions + +Appwrite Databases use tables, columns, and rows. Each row can carry its own permissions, and columns have types that keep the schema honest. This is the layer where AI-generated code benefits most from a clear backend, because permission rules are easy to get wrong when they are generated inside the same loop as the UI. + +A practical pattern for a Lovable app is to keep permissions on the row rather than relying purely on client-side checks. A `projects` table can let the owner read and write, and team members read. A `tasks` table can inherit from its parent project. The generated frontend then just reads and writes rows, and Appwrite enforces who sees what. + +Relationships, queries with filters and ordering, and indexes for common lookups all live in Appwrite's database product. Type generation and AI suggestions on schemas are available as part of the Databases experience, which helps keep generated client code aligned with the tables it talks to. + +## Storage and Functions for everything Lovable will not generate + +Two pieces of a production app almost never live in Lovable itself. File handling and server-side logic both belong in the backend. + +Appwrite Storage covers user uploads with buckets, permissions, file size limits, allowed extensions, and image transforms. A Lovable-generated UI can upload to Storage, then reference the resulting file ID in a row. Signed URLs and Appwrite's permission model keep private files private without asking the generated client to be clever. + +Appwrite Functions run on the server with secrets, logs, and scheduled or event triggers. Common uses for a Lovable app: + +- Calling a model provider with a server-held API key, then writing the result back to a row. +- Webhook handlers for payments, email events, or third-party integrations. +- Scheduled jobs for digests, cleanups, and data rollups. +- Event-triggered logic that runs when a row is created or a file is uploaded. + +Keeping these on Functions means the generated client never sees the secrets, and the same logic runs whether a human or an agent triggered the event. + +## Hosting and observability with Appwrite Sites + +If you want the Lovable app, its backend, and its deployment to sit in one place, Appwrite Sites is worth including in the pairing. Sites handles source control deploys, isolated containers, custom domains, env vars, rollbacks, and logs, with the Appwrite Network delivering the site to users. Pair this with Functions and Databases, and the whole stack has a single operational surface. + +Observability in Appwrite covers logs for Sites and Functions, request history, and the usual backend-side metrics. For an app where the UI was generated quickly, this is often the first place you look when something unexpected happens in production. + +## When Lovable and Appwrite is the right pairing + +This pairing makes the most sense when you want: + +- An open-source backend under an AI builder. +- A single platform for Auth, tables, permissions, Storage, Functions, Messaging, and Sites. +- Lovable's assistant grounded in Appwrite's actual documentation through MCP. +- A path from prompt-built prototype to production app without rebuilding the backend later. + +It is less interesting if you are committed to a specific Postgres stack or if your app is a throwaway demo that will never talk to end users. For most Lovable projects that are heading toward launch, treating Appwrite as the backend foundation is a pragmatic default. + +## Next steps + +If you want to try the pairing: + +1. Create an Appwrite project on Appwrite Cloud or self-host it. +2. Add the Appwrite Docs MCP server to Lovable's personal connectors using the values in the Appwrite Lovable docs. +3. Define the tables, Auth flows, and Storage buckets your app needs in Appwrite. +4. Build the UI in Lovable, pointing it at your Appwrite project. +5. Deploy the frontend on Appwrite Sites if you want the full stack in one place. + +The goal is not to replace Lovable's speed. It is to give the generated app a backend it can keep growing into. + +## More resources + +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite Lovable integration docs](/docs/tooling/ai/ai-dev-tools/lovable) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Docs MCP server](/docs/tooling/ai/mcp-servers/docs) diff --git a/src/routes/blog/post/open-source-backend-for-ai-apps/+page.markdoc b/src/routes/blog/post/open-source-backend-for-ai-apps/+page.markdoc new file mode 100644 index 0000000000..2c5518623a --- /dev/null +++ b/src/routes/blog/post/open-source-backend-for-ai-apps/+page.markdoc @@ -0,0 +1,114 @@ +--- +layout: post +title: "Open-source backend for AI apps: why ownership matters" +description: "Why the open-source backend for AI apps matters in 2026. Compare licenses and self-hosting across Appwrite, Supabase, Convex, Neon, Cloudflare, and Firebase." +date: 2026-04-24 +cover: /images/blog/open-source-backend-for-ai-apps/cover.png +timeToRead: 9 +author: aditya-oberai +unlisted: true +category: open-source +--- + +Every week, another team ships an AI product on top of a closed builder or a hosted backend they have never inspected. The app works, the demo lands, and then someone asks the hard questions. Who owns the user data. What happens if the vendor pivots. Can the team move off if prices change. Can they audit the server code when an AI agent starts writing to production. Can they run the stack offline, behind a VPC, or in a region the vendor does not cover. + +These are ownership questions, and they are exactly the questions an open-source backend for AI apps is designed to answer. This piece makes the case for treating open source as a first-class filter when you pick a backend for AI apps, with a simple license and self-hosting comparison across the platforms teams evaluate most. + +# Why ownership matters more for AI apps than for normal SaaS + +AI apps push more of the app logic into places that used to be small. Prompt templates sit next to business logic. Tool calls reach into customer data. Embeddings and RAG sources move across buckets and tables. Background agents schedule work without a human in the loop. Every one of those paths needs to be inspected, logged, and controlled. + +A closed AI builder or proprietary backend hides those paths behind a dashboard and a terms page. That works fine for a prototype. It becomes a liability for a production app that handles user data, regulated workloads, or anything your legal team wants to review. + +Ownership for AI apps comes down to a few concrete things: + +- **Source you can read.** When an agent writes a new Function or a new column, you need to read the surrounding code and see the surface area that agent can touch. +- **Data you can move.** If the vendor raises prices or shuts down, you need a path to export everything, including tables, files, auth users, and logs. +- **A self-host path that works.** Not a promise. A documented install that teams actually run in production. +- **A license that allows commercial use.** Source-available is not the same as open source. Some licenses block competing use. Others flip to a permissive license after a delay. These details matter when you plan a multi-year product. +- **A community you can contribute to.** Open issues, public roadmaps, and accepted pull requests are a signal that the project is not a single-vendor black box. + +# What counts as an open-source backend for AI apps + +The phrase "open source" gets stretched in backend marketing. Here is a tighter working definition for the AI app context: + +- The **server** code is published under a recognized open-source license. +- You can **self-host the same server** you would use on the vendor's cloud, not a stripped-down local tool. +- **Core AI-adjacent primitives** (Auth, Databases, Storage, server-side logic, Realtime) live in the same open repository. +- There is a **documented install path** for production, not just a developer sandbox. + +Under that definition, the landscape thins out quickly. Client SDKs being MIT licensed is not enough. A CLI being MIT licensed is not enough. The server that stores your users and your rows has to be the open part. + +# License and self-hosting snapshot + +This is the concrete comparison. Licenses and self-host claims are pulled from each project's own repo and docs as of April 2026. Check the links before you commit to any of them. + +| Platform | Server license | Self-host the same server | Notes | +| --- | --- | --- | --- | +| Appwrite | BSD-3-Clause | Yes, Docker Compose install | Full backend platform (Auth, TablesDB, Storage, Functions, Sites, Realtime, Messaging, MCP) in one open repo. | +| Supabase | Apache 2.0 | Yes, Docker-based self-host | Postgres-centric stack with Auth, Storage, Edge Functions, Realtime, and Studio. | +| Convex | FSL-1.1-Apache-2.0 | Limited, non-competing use; converts to Apache 2.0 after 2 years | Functional Source License blocks competing use until the delayed Apache grant kicks in. | +| Neon | Apache 2.0 (core) | Possible for the storage and compute core; most teams use Neon Cloud | Database-only scope. Auth, Storage, Functions, and hosting sit outside. | +| Cloudflare Workers | workerd runtime Apache 2.0 | Runtime only; platform is proprietary | Durable Objects, D1, R2, Queues, and the hosted edge are not open source. | +| Firebase | Proprietary server | No | Hosted only on Google Cloud. Some client SDKs and the CLI are open source, but the backend services are not. | + +The table is the short version. Each platform has nuance, and the right choice depends on what you are building. The pattern is still useful: if ownership and self-hosting are hard requirements, the list of options is short. + +# Where closed AI-builder lock-in shows up + +"Vibe coding" tools and all-in-one AI builders are fast to start with and easy to love in week one. The lock-in shows up later, in a few predictable places. + +- **Generated backend code you cannot move.** When the builder writes server logic into its own proprietary runtime, you cannot lift it out. +- **Data models you cannot version.** If the schema lives in a hidden admin panel, your team cannot review it in pull requests, or replay it in a staging environment. +- **Auth that does not travel.** User accounts, sessions, MFA factors, and organization membership are hard to export cleanly from a closed identity product. +- **Files that belong to the vendor.** Generated images, audio, uploads, and RAG sources often live in a vendor bucket you do not fully control. +- **Agent actions with no audit trail you can host.** If the platform does not expose a log surface you can pipe into your own observability stack, you are trusting a dashboard you do not own. + +The fix is not to avoid AI builders. Teams ship fast with them, and that matters. The fix is to keep the durable parts of the app, the backend that outlives any one UI generator, in a platform you own. + +# Why Appwrite is positioned as the open-source backend for AI apps + +Appwrite is an open-source backend platform under BSD-3-Clause, with a self-host path that runs on Docker and the same API surface on Appwrite Cloud. For AI app teams, the relevant pieces are: + +- **Auth** with email, OAuth, phone, anonymous sign-in, MFA, Teams, and roles. +- **TablesDB** with databases, tables, rows, typed columns, relationships, queries, indexes, and transactions. You model user profiles, conversation threads, message history, tool call logs, and RAG metadata as rows in tables, with permissions at the row level. +- **Storage** with buckets, permissions, antivirus scanning, and image transformations for user uploads, generated assets, and RAG sources. +- **Functions** on Node, Python, Go, Ruby, Deno, PHP, and more, for tool calls, LLM orchestration, webhooks, and scheduled jobs. You read the function code in your repo, not in a dashboard. +- **Realtime** channels that subscribe to row changes and custom events, so clients see tool call results, thread updates, and agent status without polling. +- **Sites** for hosting your AI app frontend with source control deploys, custom domains, env vars, rollbacks, and logs. +- **Messaging** for email, SMS, and push notifications, useful for approvals, human-in-the-loop flows, and background agent updates. +- **MCP servers.** The Appwrite API MCP lets coding agents act on your Appwrite resources through natural language. The Appwrite Docs MCP gives agents accurate product context inside Cursor, Claude Code, Lovable, and Windsurf. + +Because the whole backend is one open repo, you get the same audit path for every layer. You can run it on your laptop, in a VPC, in a regulated environment, or on Appwrite Cloud. The API surface does not change. + +# A practical ownership checklist for AI backends + +Before you commit to a backend for an AI app, walk this list. It maps to the ownership questions at the top of the post and gives you something concrete to ask each vendor. + +- **Server license.** Is the server you will rely on published under a recognized open-source license. Is it source-available with restrictions, or permissive. +- **Self-host parity.** Can you run the same server the vendor hosts, with the same API surface, the same auth flows, and the same file handling. +- **Data export.** Is there a documented path to export tables, rows, files, auth users, and logs in open formats. +- **Code you can read.** When an AI agent writes a Function or a migration, can you review the generated code and its surface area in your repo. +- **Access model.** Are row-level and file-level permissions first-class, so an agent only touches what it is authorized to touch. +- **Observability.** Can you pipe logs, audit events, and usage metrics into the observability stack you already run. +- **License for generated content.** If the platform stores embeddings, vectors, or generated media, do the terms let you keep and move them. +- **Community signals.** Public issues, public roadmap, accepted pull requests, and a contributor base outside the vendor. + +No vendor will score a clean pass on every line. The point is to make the trade-offs visible before you pick, not after. + +# Self-host in minutes, not weeks + +Open source only matters if you can actually run it. For Appwrite, the install path is a single Docker Compose command on a host you control, following the [self-hosting docs](/docs/advanced/self-hosting). The same Functions, TablesDB, Storage, and Auth APIs work against your local instance, your staging instance, and Appwrite Cloud. + +That is the model an open-source backend for AI apps should offer. Read the code, run the code, move when you want to, and pick the hosting story that matches your stage. + +# Next steps + +If you are choosing an open-source AI backend in 2026 and you want a platform that owns the whole backend layer, not just one piece, start with these docs. + +- [Appwrite Databases](/docs/products/databases) for tables, rows, columns, relationships, and queries +- [Appwrite Auth](/docs/products/auth) for email, OAuth, phone, MFA, Teams, and roles +- [Appwrite Functions](/docs/products/functions) for tool calls, LLM orchestration, webhooks, and scheduled jobs +- [Appwrite Sites](/docs/products/sites) for hosting AI apps with source control deploys, env vars, and rollbacks +- [Appwrite AI tooling](/docs/tooling/ai) for MCP, Assistant, Skills, and AI in Functions +- [Self-hosting Appwrite](/docs/advanced/self-hosting) to run the same server the cloud runs diff --git a/src/routes/blog/post/supabase-alternatives-lovable-projects/+page.markdoc b/src/routes/blog/post/supabase-alternatives-lovable-projects/+page.markdoc new file mode 100644 index 0000000000..e86e19f35f --- /dev/null +++ b/src/routes/blog/post/supabase-alternatives-lovable-projects/+page.markdoc @@ -0,0 +1,113 @@ +--- +layout: post +title: "Supabase alternatives for Lovable projects" +description: "Compare Supabase alternatives for Lovable projects across Appwrite, Firebase, Convex, Neon, and Lovable Cloud, and pick the right backend fit." +date: 2026-04-26 +cover: /images/blog/supabase-alternatives-lovable-projects/cover.png +timeToRead: 9 +author: atharva +unlisted: true +category: ai +--- + +Lovable ships with a native Supabase integration. Click a button, authorize your account, and Lovable will scaffold a Postgres backend, auth, storage, Edge Functions, and realtime for whatever the chat produces. For a lot of projects that is the fastest path from prompt to working app, which is why the integration is the default story across Lovable's docs, templates, and community content. + +It is also why "Supabase alternatives for Lovable projects" is a fair search to run. Supabase is great at what it does, but it is one option, not the only one. The moment your Lovable app needs something Supabase is not positioned for, or the moment you want to own more of the stack yourself, the default integration stops being the obvious choice. This page walks through the credible alternatives, what each one is good at, and where Appwrite fits as the broader backend platform. + +# Why look past the default Supabase integration + +The Lovable + Supabase path is well documented. Supabase itself markets as an open-source alternative to Firebase, centered on a hosted Postgres database with realtime, auth, storage, and Edge Functions. Inside Lovable, those same pieces are reachable through chat, which is the whole point. + +That does not mean every Lovable project fits neatly on top of Supabase. A few reasons you might look elsewhere: + +- You want a broader backend platform with hosting, messaging, and agent-facing MCP tooling alongside the usual database and auth. +- You want an open-source backend you can self-host, not a managed Postgres tenant. +- You want a Postgres that can be provisioned and branched on demand for agent workflows, without running the rest of a backend inside it. +- You want a backend designed around live, reactive data rather than a traditional database plus websockets. +- You want to avoid adding a second vendor entirely and use whatever comes with Lovable out of the box. + +Each of those leads to a different pick, and the trade-offs only become obvious once you lay them side by side. + +# Appwrite as the primary recommended alternative + +Appwrite is an open-source backend platform that covers Auth, Databases, Storage, Functions, Sites, Realtime, and Messaging, plus an MCP server and docs MCP server for AI tools. The Lovable side of that story is documented: the Appwrite docs MCP server is a first-class integration with Lovable, so the chat interface can pull live, accurate Appwrite context into code it generates instead of guessing. + +What Appwrite brings to a Lovable project: + +- **Auth** with email, OAuth, magic URL, phone, MFA, teams, and labels, ready to wire into Lovable-generated UI. +- **Databases** organized as tables, rows, columns, relationships, queries, transactions, indexes, and AI schema suggestions. No documents or collections to learn. +- **Storage** for user uploads, media, and generated assets, with per-file permissions. +- **Functions** for server-side logic, background jobs, and secret handling that should never live in the browser. +- **Sites** for hosting the Lovable-built frontend with source-controlled deploys, isolated containers, custom domains, env vars, rollbacks, logs, and Appwrite Network as the delivery layer. +- **Realtime** for live updates on rows, files, and events without you writing a socket server. +- **Messaging** for email, SMS, and push, so Lovable apps that care about notifications do not need a third vendor. +- **MCP** servers that let Claude Code, Cursor, and other agents work against your project and docs as part of the Lovable-to-developer handoff. +- **Self-hosting** when you want the backend on your own infrastructure instead of a managed tenant. + +The positioning is simple: Supabase makes one slice of the Lovable backend easy through a native integration, Appwrite makes the full backend platform available to a Lovable project through docs-aware AI tooling, MCP, SDKs, and hosted services. The integration is less automatic than Supabase's one-click flow, and that is a trade-off worth naming. You get it back in breadth, ownership, and a single vendor covering more of the stack. + +Relevant reading if you want to go deeper: + +- [Appwrite AI tooling hub](/docs/tooling/ai) +- [Appwrite Docs MCP server in Lovable](/docs/tooling/ai/ai-dev-tools/lovable) +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Sites](/docs/products/sites) + +# Other credible alternatives + +Not every Lovable project needs a broad backend platform. Sometimes the right answer is "replace Supabase with a different single-purpose backend," and sometimes it is "use a different integration inside Lovable." The options below are worth considering. + +## Firebase + +Firebase is the classic managed BaaS: Authentication, Firestore, Cloud Storage, Cloud Functions, Hosting, and AI assistance features covering Gemini in Firebase, Firebase MCP, and agentive tools. For a Lovable app that wants a mature managed stack from a single cloud vendor, Firebase is an obvious pick. It is not open source and not self-hostable, which matters if ownership is one of your reasons for leaving Supabase in the first place. + +## Convex + +Convex positions itself as a backend platform that keeps your app in sync, with a specific agent-era story: persisted LLM message history, live updates, workflows, RAG, file storage, usage tracking, and rate limiting. If your Lovable project is an AI agent or chat product where the data model is mostly "conversations and their state," Convex can feel more purpose-built than a general Postgres. It is more opinionated than Supabase, so it is a sharper tool for a narrower job. + +## Neon + +Neon is serverless Postgres, marketed as "Postgres for AI" with one-second provisioning, scale-to-zero, database branching, built-in Neon Auth, Cursor integration, and an MCP server for agent-driven workflows. Neon is a database-first alternative, not a backend platform. It fits Lovable projects where you mostly want to swap "Supabase Postgres" for "a Postgres that provisions instantly and branches well," and are happy to assemble the rest (auth, storage, functions, hosting) around it. For agent-native apps where each tenant might want its own database, that is an advantage. + +## Rolling your own + +The final option is to skip integrations entirely and let Lovable generate a frontend that talks to a backend you already run. This maximizes ownership and flexibility and loses most of the reason you picked Lovable in the first place. It is worth mentioning for completeness, not as a default. + +# Supabase alternatives for Lovable projects at a glance + +Here is a side-by-side view of the alternatives covered above. + +| Option | Shape | Auth | Database | Storage | Server-side logic | Hosting | Realtime | Agent/MCP story | Self-host | +| ------------- | ---------------------------------------- | ------------ | ---------------------------------------- | ------- | --------------------------- | ---------------- | -------- | ------------------------------------ | --------- | +| Supabase | Open-source Postgres BaaS | Yes | Postgres (tables, SQL) | Yes | Edge Functions | No | Yes | AI and vectors guides, pgvector | Yes | +| Appwrite | Open-source backend platform | Yes | Tables, rows, columns, relationships | Yes | Functions | Sites | Yes | API MCP, Docs MCP, Lovable guide | Yes | +| Firebase | Managed BaaS | Yes | Firestore | Yes | Cloud Functions | Firebase Hosting | Yes | Gemini in Firebase, Firebase MCP | No | +| Convex | Reactive backend platform | Yes | Document and relational tables | Yes | Convex functions, workflows | No | Yes | Convex Agent components | Yes | +| Neon | Serverless Postgres | Neon Auth | Postgres with branching | No | No | No | No | Neon MCP, Cursor integration | No | + +A few things to keep in mind when reading the table. Realtime, auth, and storage are not identical across these products even when a row says "yes"; the shape of the primitive and the permission model are what matter once you start building. Hosting listed as "no" means the product does not ship a hosting surface of its own, not that you cannot deploy a Lovable app somewhere. + +# How to choose + +The useful way to pick a Supabase alternative for a Lovable project is to start from what the project needs and work backward. + +**Pick Appwrite when** you want one backend platform covering Auth, Databases (tables and rows), Storage, Functions, Sites, Realtime, and Messaging, with MCP support, Agent Skills, and editor plugins for the AI tools you already use, and the option to self-host. This is the strongest fit for Lovable projects that will outgrow a single-purpose backend, because the pieces are already in one product and one permission model. + +The narrower picks: **Firebase** if you are committed to Google Cloud and Firestore's document model, **Convex** if the app is purely a TypeScript chat or agent product, **Neon** if the database itself is the entire job and instant Postgres branching is the point, and **Supabase** if the default integration covers what you need. + +# Working with Appwrite from Lovable + +If Appwrite is the pick, the connection into Lovable is light. The [Appwrite Docs MCP server integration for Lovable](/docs/tooling/ai/ai-dev-tools/lovable) gives the chat interface grounded Appwrite context, so generated code uses the right APIs, SDKs, and patterns instead of guessing. From there, the usual flow is: + +1. Build the frontend in Lovable with Appwrite as the backend target in mind. +2. Let Appwrite cover Auth, Databases, Storage, Realtime, and Functions through SDKs and the API. +3. Deploy the finished app on Appwrite Sites, or hand it to Claude Code or Cursor through the Appwrite MCP servers for further iteration. + +That covers the gap between "Lovable's default Supabase integration" and "a backend platform that keeps working as the project grows." The rest is project-specific, and the right starting point is the Appwrite docs you will already be pulling into the builder. + +Further reading: + +- [Appwrite AI tooling overview](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Appwrite Docs MCP server in Lovable](/docs/tooling/ai/ai-dev-tools/lovable) +- [Announcing the Appwrite MCP server](/blog/post/announcing-appwrite-mcp-server-2) diff --git a/src/routes/blog/post/what-is-an-ai-backend/+page.markdoc b/src/routes/blog/post/what-is-an-ai-backend/+page.markdoc new file mode 100644 index 0000000000..e30b603ea8 --- /dev/null +++ b/src/routes/blog/post/what-is-an-ai-backend/+page.markdoc @@ -0,0 +1,149 @@ +--- +layout: post +title: "What is an AI backend?" +description: "An AI backend is the durable layer behind AI-native apps. Here is what it contains, how it differs from a traditional backend, and how to evaluate one." +date: 2026-04-23 +cover: /images/blog/what-is-an-ai-backend/cover.png +timeToRead: 9 +author: aditya-oberai +unlisted: true +category: ai +--- + +AI-native apps look new on the surface and familiar underneath. A chat interface, a copilot panel, or an agent that edits a document still needs a place to store users, data, files, server-side code, and a deployed UI. What changes is the set of jobs that layer has to do. It now holds conversation history, embeddings metadata, tool call records, long-running workflows, and permissions that cover both human users and agents acting on their behalf. + +This is what people mean by an AI backend. It is the same primitives, evaluated against a new workload. + +This page defines the term, maps the capabilities an AI backend needs to cover, compares it to a traditional backend, and gives a checklist for evaluating one. + +# What is an AI backend? + +An AI backend is the server-side layer that holds durable state, identity, permissions, server-side logic, files, hosting, and observability for an application that uses AI models or agents. It is the part of the system that survives between prompts, sessions, model swaps, and UI regenerations. + +A useful way to picture it: the model is a function you call, the UI is how a user sees the result, and the AI backend is everything that still has to be true after the function returns and the user closes the tab. That includes who the user is, what they are allowed to see, which conversation a message belongs to, where the uploaded file lives, which tools the agent is permitted to call, and what happened the last time a model call failed. + +The term covers backends for AI chat apps, copilots, agents with memory, RAG systems, AI SaaS products, and apps generated by AI builders. The workloads differ; the layer underneath has the same shape. + +# What an AI backend contains + +An AI backend maps to a specific set of concerns. Each one is familiar from traditional apps and takes on extra weight in AI workloads. + +## Identity and sessions + +AI apps still have users. A chat history has to belong to someone, and an agent acting on a user's behalf has to prove that connection on every request. Sessions, OAuth providers, magic URLs, OTPs, MFA, teams, and account recovery all matter before the model is called. + +The AI-specific twist is that agents need identity too. An automated workflow that reads a user's data should run under a scoped credential, not the user's session. Good AI backends separate user sessions from server-side keys so tool calls and scheduled jobs cannot be replayed from a browser. + +## Durable data + +AI apps generate a lot of structured records: messages, threads, tool calls, runs, evaluations, user preferences, model choices, and usage counters. These are rows in tables, queried with filters. + +A useful AI backend database gives you typed columns, relationships between tables, indexes, queries, and transactions. It does not need to be a new kind of database. It needs to treat AI state as first-class records instead of blobs. A `messages` table with columns for role, content, token count, timestamp, and a relationship to a `threads` table is more useful to both humans and agents than a single JSON column called `state`. + +## Files + +Files in AI apps come from many directions: uploaded documents for retrieval, user avatars, generated images, audio clips, and message attachments. Each needs size limits, MIME rules, permissions that match the row they belong to, and a way to serve them back with transforms. + +A file store with per-bucket and per-file permissions, preview generation, and encryption at rest is the baseline. Without it, the app either overexposes user data or reinvents file handling inside a model call. + +## Server-side logic + +Model calls, payment webhooks, email sending, embedding generation, vector upserts, agent tool execution, and scheduled jobs cannot live in the browser. They touch secrets, hit rate limits, and need retry logic. + +An AI backend runs this work in server-side functions with environment variables for secrets, HTTP triggers for synchronous work, event triggers for reactions to data changes, and schedules for recurring jobs. This is where the untrusted work moves, and where tool calls from an agent actually execute. The client can call a function. It should not hold the OpenAI key. + +## Jobs and workflows + +AI work is often long-running. A retrieval pipeline ingests a document, chunks it, embeds each chunk, and upserts into a vector store. A scheduled job re-computes a user's recommendations overnight. A webhook confirms a payment, then enqueues a welcome email and a usage record. + +An AI backend handles these with scheduled functions, event-driven functions, and tables that track run status. Most apps do not need a bespoke job engine. They need clean primitives for scheduling, events, idempotency, and logs so workflows can be observed and retried. + +## Permissions + +Permissions are where AI apps most often leak. A user should only see their own threads. A team admin should only see their team's data. An agent running as a service account should only touch resources its scope allows. + +Row-level and file-level permissions belong on the server, bound to the authenticated identity, and evaluated on every request. Client checks are a usability feature; server checks are the security boundary. An AI backend treats permissions as data, defined on tables, rows, buckets, and files, and enforces them regardless of what the client sends. + +## Vector-ready integrations + +RAG, semantic search, and recommendation features need a vector store. Two shapes are common: a specialized vector database like Pinecone, Weaviate, Milvus, Qdrant, Chroma, or Upstash Vector called from server-side functions, or a Postgres database with the pgvector extension queried directly. + +An AI backend does not have to include a vector database. It does have to make it easy to call one from server-side logic, keep embeddings metadata in ordinary tables, and maintain the link between the vector record and the row or file it came from. Without that link, retrieval results cannot be filtered by user, team, or permission. + +## Hosting + +AI-generated UIs still need a home. Custom domains, TLS, environment separation between staging and production, deploy logs, rollbacks, and environment variables are the same requirements a traditional app has, and they are often skipped in AI prototypes because the builder preview feels like a deployment. + +An AI backend that includes hosting keeps the generated UI, the backend APIs, and server-side functions inside one permission and observability model. The alternative is a stitched stack where auth lives in one place, data in another, and deploys in a third, which is the configuration AI code generators get wrong most often. + +## Observability + +When an AI feature misbehaves in production, the questions are concrete. Which request failed, for which user, at which step of the agent loop, with which model, and with which payload? A preview does not answer any of these. + +Observability means execution logs for server-side functions, deploy and runtime logs for hosting, and activity records on backend resources. For AI workloads it also means recording model calls, tool calls, and token usage so cost and quality can be tracked over time. + +# How an AI backend differs from a traditional backend + +At the primitive level, an AI backend is a traditional backend. Auth, data, files, functions, hosting, and logs are the same building blocks. What changes is the workload pattern. + +| Area | Traditional backend focus | AI backend focus | +| ----------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------- | +| Data shape | CRUD over domain entities | CRUD over domain entities plus messages, threads, runs, tool calls, embeddings | +| Identity | Users and sessions | Users, sessions, and scoped service credentials for agents | +| Server-side work | API endpoints and background jobs | API endpoints, background jobs, model calls, embeddings, and agent tool execution | +| Files | User uploads and media | User uploads, media, and retrieval corpora | +| Integrations | Payments, email, analytics | Payments, email, analytics, model providers, and vector stores | +| Observability | Request logs, error tracking | Request logs, error tracking, model and tool call history, token and cost records | +| Audience | Humans through a UI | Humans through a UI and agents through APIs and MCP | + +The important shift is the last row. A traditional backend is read and written by humans using a UI. An AI backend is also read and written by agents acting on behalf of users. That is why documentation quality, SDK accuracy, MCP servers, and clear primitives now matter at the platform level. If an agent cannot reason about the backend, the generated code will be wrong in expensive ways. + +# How Appwrite fits + +[Appwrite](/) is built around exactly these primitives and exposes them to both humans and agents. The mapping is direct. + +- [Appwrite Auth](/docs/products/auth) handles email and password sessions, OAuth providers, phone and email OTPs, magic URLs, MFA, teams, and server-side session verification. +- [Appwrite Databases](/docs/products/databases) uses tables, rows, columns, relationships, indexes, queries, and transactions. Columns support typed values including text, integer, float, boolean, datetime, email, enum, IP, URL, and relationships. +- [Appwrite Storage](/docs/products/storage) provides buckets with file-level permissions, size and MIME limits, image previews, and encryption. +- [Appwrite Functions](/docs/products/functions) runs server-side code in isolated containers with environment variables, HTTP triggers, server events, webhooks, and scheduled executions. +- [Appwrite Sites](/docs/products/sites) deploys from source control with custom domains, environment variables, rollbacks, and deploy logs, served through Appwrite Network. +- [Appwrite Realtime](/docs/apis/realtime) pushes changes to connected clients so chat UIs and agent dashboards stay in sync without polling. +- [Appwrite Messaging](/docs/products/messaging) sends email, SMS, and push notifications from the same permission and identity model. + +For AI workloads specifically, Appwrite exposes an agent-facing surface alongside the developer-facing one. The [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) lets coding agents inspect and act on project resources through a compact two-tool workflow. [Agent Skills](/docs/tooling/ai/skills) give AI tools grounded documentation context. [Appwrite Assistant](/docs/tooling/ai/assistant) answers questions against your project. [Appwrite Arena](/docs/tooling/ai/arena) benchmarks how well models understand Appwrite. Vector workloads plug in through [Functions](/docs/tooling/ai/vector-db-and-embeddings), with documented integrations for Pinecone, Weaviate, Milvus, Qdrant, Chroma, and Upstash Vector. + +The result is one backend that stores users, data, files, and server-side logic for both the human side of the app and the agent side. + +# What to evaluate when choosing an AI backend + +When comparing options, the questions are the same ones a production team would ask about any backend, with AI-specific extensions. + +- **Identity**: Sessions, OAuth, MFA, teams, server-side verification, and scoped credentials for agents? +- **Data**: Tables, columns, rows, relationships, indexes, queries, and transactions, with per-row permissions? +- **Files**: Buckets, per-file permissions, size and MIME limits, previews, and encryption, tied back to the rows they belong to? +- **Server-side logic**: Secrets, HTTP triggers, event triggers, and schedules, with inspectable logs? +- **Permissions**: Evaluated on the server for every request, on both data and files, and defined declaratively? +- **Vector integrations**: Can server-side code call a vector database and keep metadata in tables, with a documented path for common providers? +- **Hosting**: Generated UI deployable with custom domains, environment separation, rollbacks, and deploy logs in the same platform? +- **Observability**: Execution logs, deploy logs, activity records, and model and tool call history? +- **Agent access**: MCP server, accurate agent-readable docs, and SDK coverage? +- **Ownership**: Self-hostable with a license that allows it? + +A backend that answers yes to most of these, and exposes them through a consistent permission and identity model, is a reasonable AI backend. The ones that answer no on permissions, server-side logic, or agent access are the ones AI-generated apps tend to fail on first. + +# Summary + +An AI backend is the durable server-side layer behind AI-native apps. It holds identity, data, files, server-side logic, jobs, permissions, vector integrations, hosting, and observability, and it serves both human users and agents acting on their behalf. Picking one is about checking that each primitive is present, that permissions are evaluated on the server, and that agents can read the backend as clearly as people can. + +# Further reading + +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [Appwrite Realtime](/docs/apis/realtime) +- [Appwrite Messaging](/docs/products/messaging) +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) +- [Vector DB and embeddings](/docs/tooling/ai/vector-db-and-embeddings) diff --git a/src/routes/blog/post/why-ai-generated-apps-need-backend/+page.markdoc b/src/routes/blog/post/why-ai-generated-apps-need-backend/+page.markdoc new file mode 100644 index 0000000000..78fc2e02d7 --- /dev/null +++ b/src/routes/blog/post/why-ai-generated-apps-need-backend/+page.markdoc @@ -0,0 +1,128 @@ +--- +layout: post +title: "Why AI-generated apps still need a real backend" +description: "AI builders can scaffold a UI in minutes, but durable data, identity, access control, and server-side logic still decide whether the app survives launch." +date: 2026-04-23 +cover: /images/blog/why-ai-generated-apps-need-backend/cover.png +timeToRead: 8 +author: atharva +unlisted: true +category: ai +--- + +AI app builders have changed the first hour of development. You describe an idea, an agent scaffolds a working interface, and you are clicking around a prototype before you have written a line of code. The gap between idea and something you can show a friend has collapsed. + +The gap between prototype and something you can charge money for has not collapsed. It has moved. An AI-generated app backend is still the thing that decides whether the demo becomes a product or quietly dies the first time a paying user tries to log in from a different device. + +This article explains why the AI app backend question matters more than the UI question, and what the durable backend layer needs to cover when the front end was generated by a model. + +# What AI builders are actually generating + +Most AI app builders today are excellent at one thing: producing a front end from a prompt. Lovable, Bolt, v0, and Replit Agent each take a natural-language description and return a working React, Next.js, or similar project that runs in a preview. + +Underneath, they all reach for the same pattern when state needs to survive a page refresh. Lovable integrates with Supabase and ships a first-party Lovable Cloud backend. Bolt promotes Bolt Cloud Database as the default with Supabase as an option. Replit Agent offers a built-in database and auth alongside integrations with third-party services. The agents generate the UI; the data, identity, and permissions come from a backend platform behind it. + +This is the right split. A generated UI does not replace a backend, and anyone who has tried to ship an AI-generated app to users has hit the same wall at roughly the same moment. + +# The moment generated apps break + +The break is always the same shape. The prototype works for the developer who prompted it. Then someone else signs in. Then two people try to edit the same row. Then a file upload fails silently. Then a model key ends up in a browser bundle. Then the database schema drifts because the next prompt regenerated half of it. + +None of these problems are caused by the AI. They are caused by the absence of the things a backend platform usually provides: durable identity, access control that survives regeneration, file handling with permissions, server-side logic, deployment with environment separation, and observability when something goes wrong. + +A generated UI is a snapshot. A backend is the part that has to stay consistent while the UI, the prompts, and the team around it keep changing. + +# Why AI-generated apps still need a backend + +The full AI-generated app backend story breaks down into seven concerns. Each one is something an AI builder cannot solve on its own, because it lives outside the bundle the agent ships. + +## Durable data + +A generated app might start with everything in component state or local storage. The first time a user closes the tab and reopens it on another device, that model stops working. + +Durable data means a database that persists across sessions, supports queries, enforces types, and can be migrated as the schema changes. It also means a schema the team can reason about, not one that is rewritten every time an agent regenerates a screen. + +Appwrite Databases gives you tables, rows, columns, relationships, indexes, queries, and transactions as backend primitives. You can define a column as text, integer, float, boolean, datetime, email, enum, IP, URL, or a relationship, and have the database enforce the type instead of trusting generated client code. Schema changes happen in one place and survive the next UI regeneration. + +## Identity + +Authentication is where AI-generated apps most visibly fail. A generated sign-in form is easy. A session that works across devices, an OAuth flow that handles provider errors, a password reset that uses signed tokens, MFA, team membership, and account recovery are not things you want an agent to invent from scratch on each project. + +A durable backend gives you tested auth flows as primitives. Appwrite Auth covers email and password sessions, OAuth providers, phone and email OTPs, magic URLs, MFA, teams, and server-side session verification. The generated UI can call these flows. It should not try to reimplement them. + +## Access control + +Access control is where generated apps leak data. Rules like "a user can read their own rows but not anyone else's" or "only team admins can delete files" are easy to describe in a prompt and extremely easy to get wrong in generated code, especially when the checks run only in the client. + +Row-level and file-level permissions belong on the server, bound to the authenticated user. Appwrite permissions are defined on tables, rows, buckets, and files, and are evaluated on every request regardless of what the client sends. That is the layer that has to hold when the UI changes. + +## File handling + +Most non-trivial apps eventually need to store files: avatars, attachments, exports, user-generated media. Doing this well involves signed uploads, size limits, allowed MIME types, virus scanning, transformations, and permissions that match your data model. + +Appwrite Storage provides buckets with file-level permissions, image previews, compression, and encryption. It is the file side of the same permission model that protects your rows, which means the mental model stays consistent as the app grows. + +## Server-side logic + +AI model calls, payment webhooks, scheduled jobs, email sending, and anything that touches a secret do not belong in the browser. A generated client cannot safely hold an OpenAI key, a Stripe secret, or an email provider token, and the moment a generated app tries, the credential is exposed. + +Appwrite Functions runs server-side code in isolated containers, with environment variables for secrets, events and schedules for triggers, and logs for debugging. This is where the untrusted work moves: model calls, payment confirmation, data transformations, background jobs. The generated client can call a function; it should not do the work itself. + +## Deployment + +A preview in an AI builder is not a deployment. Shipping to users means a custom domain, TLS, environment separation between staging and production, rollbacks when a change breaks something, and a hosting surface that can run both static assets and server rendering. + +Appwrite Sites deploys from source control with per-branch environments, custom domains, environment variables, rollbacks, and deploy logs, served through Appwrite Network. The UI the agent generated becomes a site with the same permissions and services as the rest of the backend, instead of a preview URL that dies when the builder tab closes. + +## Observability + +When a generated app breaks in production, the useful question is which request failed, for which user, with which payload. A preview does not answer this. Observability means logs for server-side code, execution history for scheduled work, request records you can query, and a way to reproduce an issue without guessing. + +Appwrite exposes execution logs for Functions, deploy and runtime logs for Sites, and an activity record on backend resources. That is the layer that lets a team debug a live issue instead of regenerating the UI and hoping the bug goes away. + +# The shape of a sensible AI app backend stack + +Put those seven concerns together and the shape of a durable AI app backend is specific: + +| Concern | What it holds | +| ---------------------- | -------------------------------------------------------------------------------- | +| Durable data | Tables, rows, columns, relationships, indexes, queries | +| Identity | Sessions, OAuth, MFA, teams, password reset, server-side verification | +| Access control | Table, row, bucket, and file permissions bound to the authenticated user | +| File handling | Buckets with permissions, size and MIME limits, previews, encryption | +| Server-side logic | Functions with env vars, events, schedules, and logs | +| Deployment | Hosted sites with domains, environment variables, rollbacks, and deploy logs | +| Observability | Execution logs, deploy logs, activity records across services | + +Appwrite is organized around exactly these primitives: Auth, Databases, Storage, Functions, Sites, Realtime, and Messaging, with MCP and Agent Skills on top so AI tools can act against the same surface. That is the backend layer the generated UI plugs into. + +# How AI builders and a durable backend fit together + +This is not an argument against AI app builders. The fastest path to a working prototype in 2026 is still to let an agent scaffold the UI, iterate on layout in natural language, and focus human attention on the parts of the app that matter. + +It is an argument about where the boundary sits. The agent owns the generated UI and the glue that connects it to your backend APIs. The backend owns data, identity, permissions, files, server-side work, deployment, and observability. When the boundary is clear, regenerating a screen does not wipe out the schema, and changing the schema does not force a full UI rewrite. + +Appwrite's [AI tooling](/docs/tooling/ai) supports this split from the agent side. The [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) lets agents inspect and act on your backend through a small, documented tool surface. The [Lovable integration](/docs/tooling/ai/ai-dev-tools/lovable) and similar bridges for [Cursor](/docs/tooling/ai/ai-dev-tools/cursor) and [Claude Code](/docs/tooling/ai/ai-dev-tools/claude-code) give those agents docs-grounded context so the generated code calls your backend correctly instead of inventing a new shape each time. + +# What to check before shipping an AI-generated app + +If you are about to push a prompt-built app in front of users, the backend questions worth answering first are concrete: + +- Does every row, file, and function call have a permission rule that does not trust the client? +- Are sessions, password resets, and OAuth flows handled by tested auth primitives, not generated code? +- Are all model, payment, and email secrets held in server-side environment variables, not the client bundle? +- Is your schema defined in one place, with typed columns, indexes, and relationships you can reason about? +- Can you deploy to a custom domain with proper environment separation between staging and production? +- Can you find the failed request, the user, and the payload when something breaks, without regenerating the UI? + +If the honest answer to any of these is "the builder handled it somehow," that is the gap a durable backend is for. + +# Further reading + +- [Appwrite Databases](/docs/products/databases) +- [Appwrite Auth](/docs/products/auth) +- [Appwrite Storage](/docs/products/storage) +- [Appwrite Functions](/docs/products/functions) +- [Appwrite Sites](/docs/products/sites) +- [Appwrite AI tooling](/docs/tooling/ai) +- [Appwrite API MCP server](/docs/tooling/ai/mcp-servers/api) diff --git a/static/images/blog/agent-native-backend-platforms/cover.png b/static/images/blog/agent-native-backend-platforms/cover.png new file mode 100644 index 0000000000..58856ad19a Binary files /dev/null and b/static/images/blog/agent-native-backend-platforms/cover.png differ diff --git a/static/images/blog/appwrite-vs-cloudflare-stateful-ai-agents/cover.png b/static/images/blog/appwrite-vs-cloudflare-stateful-ai-agents/cover.png new file mode 100644 index 0000000000..b4b106dc78 Binary files /dev/null and b/static/images/blog/appwrite-vs-cloudflare-stateful-ai-agents/cover.png differ diff --git a/static/images/blog/appwrite-vs-convex-ai-agents/cover.png b/static/images/blog/appwrite-vs-convex-ai-agents/cover.png new file mode 100644 index 0000000000..c18c97899e Binary files /dev/null and b/static/images/blog/appwrite-vs-convex-ai-agents/cover.png differ diff --git a/static/images/blog/appwrite-vs-firebase-ai-development/cover.png b/static/images/blog/appwrite-vs-firebase-ai-development/cover.png new file mode 100644 index 0000000000..ec9b71bd50 Binary files /dev/null and b/static/images/blog/appwrite-vs-firebase-ai-development/cover.png differ diff --git a/static/images/blog/appwrite-vs-neon-ai-backends/cover.png b/static/images/blog/appwrite-vs-neon-ai-backends/cover.png new file mode 100644 index 0000000000..d1d6a25648 Binary files /dev/null and b/static/images/blog/appwrite-vs-neon-ai-backends/cover.png differ diff --git a/static/images/blog/appwrite-vs-replit-agent-backend/cover.png b/static/images/blog/appwrite-vs-replit-agent-backend/cover.png new file mode 100644 index 0000000000..290815fdbb Binary files /dev/null and b/static/images/blog/appwrite-vs-replit-agent-backend/cover.png differ diff --git a/static/images/blog/appwrite-vs-supabase-ai-apps/cover.png b/static/images/blog/appwrite-vs-supabase-ai-apps/cover.png new file mode 100644 index 0000000000..41c2e1727f Binary files /dev/null and b/static/images/blog/appwrite-vs-supabase-ai-apps/cover.png differ diff --git a/static/images/blog/backend-checklist-vibe-coded-apps/cover.png b/static/images/blog/backend-checklist-vibe-coded-apps/cover.png new file mode 100644 index 0000000000..f9b4e80bf2 Binary files /dev/null and b/static/images/blog/backend-checklist-vibe-coded-apps/cover.png differ diff --git a/static/images/blog/best-backend-for-lovable-apps/cover.png b/static/images/blog/best-backend-for-lovable-apps/cover.png new file mode 100644 index 0000000000..ec589a212c Binary files /dev/null and b/static/images/blog/best-backend-for-lovable-apps/cover.png differ diff --git a/static/images/blog/lovable-appwrite-backend-pairing/cover.png b/static/images/blog/lovable-appwrite-backend-pairing/cover.png new file mode 100644 index 0000000000..facffa4ed4 Binary files /dev/null and b/static/images/blog/lovable-appwrite-backend-pairing/cover.png differ diff --git a/static/images/blog/open-source-backend-for-ai-apps/cover.png b/static/images/blog/open-source-backend-for-ai-apps/cover.png new file mode 100644 index 0000000000..cacbc552a6 Binary files /dev/null and b/static/images/blog/open-source-backend-for-ai-apps/cover.png differ diff --git a/static/images/blog/supabase-alternatives-lovable-projects/cover.png b/static/images/blog/supabase-alternatives-lovable-projects/cover.png new file mode 100644 index 0000000000..28298a22a3 Binary files /dev/null and b/static/images/blog/supabase-alternatives-lovable-projects/cover.png differ diff --git a/static/images/blog/what-is-an-ai-backend/cover.png b/static/images/blog/what-is-an-ai-backend/cover.png new file mode 100644 index 0000000000..9a04e21c41 Binary files /dev/null and b/static/images/blog/what-is-an-ai-backend/cover.png differ diff --git a/static/images/blog/why-ai-generated-apps-need-backend/cover.png b/static/images/blog/why-ai-generated-apps-need-backend/cover.png new file mode 100644 index 0000000000..166c5dceb4 Binary files /dev/null and b/static/images/blog/why-ai-generated-apps-need-backend/cover.png differ