Appwrite：一款可以替代 Firebase 的开源自托管 BaaS

Appwrite 是一个开源的全栈开发平台，把后端基础设施和 Web 托管整合到同一套系统里，开发者可以自托管在自有服务器，也可以直接用官方托管的 Appwrite Cloud。它试图解决一个很普遍的问题：搭一个现代产品，往往需要在 Auth、数据库、文件存储、对象存储、函数计算、消息推送、实时通信之间拼凑七八个服务，每个都有自己的密钥、SDK 和部署方式。Appwrite 想把这些收敛到一个面板、一套 API、一组 SDK。

截至本文基于的官方 README，主线特性是 BSD 协议开源、自带可视控制台、支持 Docker / Docker Compose / Kubernetes 等容器编排部署，托管版在公开测试期间免费使用且无需信用卡。

终端运行 install 命令并生成 docker-compose.yml 的过程截图-2
📷 Rubaitul Azad / Unsplash License / 来源

核心模块：Appwrite 都内置了哪些服务

Appwrite 把后端拆成几个相对独立的产品，每个都有自己的文档、API 和权限模型，但共享同一套项目组织和密钥管理。

  • Appwrite Auth：用户认证是 Appwrite 的招牌模块。支持邮箱密码、短信、OAuth、匿名会话、魔法链接等登录方式，附带头像、会话管理、MFA（多因素认证）和邮件验证流。换句话说，注册、登录、找回密码这些样板代码可以大幅压缩。
  • Appwrite Databases：结构化数据存储，按 Database / Table / Row 组织，提供查询、分页、索引和关联关系建模。底层存储引擎是 MariaDB（这一信息在标题中已点明，也与 README 的”containerized”自托管方式一致——MariaDB 是其中一个容器组件）。涉及具体版本和兼容性建议以官方环境变量文档为准。
  • Appwrite Storage：文件存储，覆盖上传、下载、加密、压缩以及图片变换（缩略图、裁剪、格式转换等）。通常用于头像、用户上传内容、媒体资产。
  • Appwrite Functions：Serverless 函数运行时，事件触发或定时任务触发，README 提到已支持 15 种 runtime，可用于跑自定义后端逻辑、对接第三方 API、做异步任务。
  • Appwrite Messaging：多通道消息发送，覆盖 Email、SMS、Push 通知，可用于事务邮件、营销推送、告警。
  • Appwrite Sites：把前端 Web 应用直接部署到 Appwrite 上，支持自定义域名、SSR（服务端渲染）和 Git 集成，配合 GitHub 之类的代码托管可以直接做预览环境。

这六个模块在控制台里是并列的入口，但数据是关联的，例如 Storage 里的文件可以在 Databases 中保存引用 ID，Auth 的用户 ID 可以是其他表的外键。

自托管部署：一条命令启动

Appwrite 设计为容器化运行，本地安装只需要 Docker（macOS / Windows 装 Docker Desktop，Linux 装 docker-ce）。README 给出的 Unix 命令是：

docker run -it --rm \
    --publish 20080:20080 \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="install" \
    appwrite/appwrite:1.9.0
  • --publish 20080:20080 把容器内的 20080 端口映射到主机，Appwrite 控制台默认走这个端口。
  • 两个 --volume 分别是 Docker socket 和 Appwrite 配置目录的持久化映射，不映射前者 Appwrite 没法在容器里调度其他容器，不映射后者重启后配置会丢。
  • --entrypoint="install" 临时用 install 入口把 .env 和 docker-compose.yml 写到挂载目录，初始化完成后正常用 docker compose up -d 起服务。

Windows 上的差别主要在路径与换行符，CMD 用 ^ 续行和 %cd%，PowerShell 用 ` 续行和 ${pwd}，README 都列出了可直接复制运行的版本。

安装完成后浏览器访问 http://localhost，首次会进入创建管理员账号的引导页。README 提示：在非 Linux 原生主机上，服务器初次启动可能要几分钟时间，耐心等即可。

> 对于生产环境或自定义配置，可参考官方的环境变量文档，也可以直接拉取公开的 docker-compose.yml 和 .env 文件手动维护。

从旧版本升级时，官方建议在升级完成后跑一次迁移工具，具体步骤以安装文档为准。

Appwrite 在 Web 端初始化项目并创建一个 Auth 用户列表的代码编辑器界面-3
📷 Ferenc Almasi / Unsplash License / 来源

不愿意折腾 Docker？一键部署和托管云

如果不想本地装 Docker 也没问题，Appwrite 在几个主流云市场提供一键镜像：

  • DigitalOcean Marketplace：直接在控制台选 Appwrite 镜像创建 Droplet。
  • Akamai Compute（原 Linode Marketplace）：通过 Akamai 的 marketplace 部署。
  • AWS Marketplace：在 EC2 或相关服务里通过镜像启动。

这对于想买一台 VPS 直接跑、不愿意碰 Docker Compose 的人很方便。而如果完全不想运维，Appwrite Cloud 是托管版，beta 期间功能完整、不收钱、不要求信用卡，对个人开发者和小型项目足够用了。

SDK 覆盖：前后端都有官方库

Appwrite 的 SDK 分两类：

Client SDK（运行在最终用户的设备或浏览器里）：

  • Web、Flutter、Apple（iOS/macOS）、Android、React Native

Server SDK（运行在你的服务端或可信后端）：

  • Node.js、Python、Dart、PHP、Ruby、.NET、Go、Swift、Kotlin、Rust
分类 支持平台
Web Web / React / Next.js / Vue / Nuxt / SvelteKit / Refine / Angular
移动 React Native / Flutter / Apple / Android
服务端 Node.js / Python / .NET / Dart / Ruby / Deno / PHP / Kotlin / Swift / Go / Rust

README 强调，如果你的目标平台不在列表里，可以通过 SDK Generator 项目贡献新的语言绑定。

{{图：Appwrite 在 Web 端初始化项目并创建一个 Auth 用户列表的代码编辑器界面}}

适合什么样的项目

根据 README 列出的产品矩阵和定位，以下场景 Appwrite 通常比较顺手：

  • 前后端分离的 Web 项目：前端用任意框架，后端完全用 Appwrite，省掉自己写 Express/Flask 这些 CRUD 样板。
  • 移动应用后端：iOS、Android、Flutter、React Native 都有成熟的 Client SDK，离线缓存和实时订阅也覆盖到了。
  • 快速 MVP 和内部工具：产品 demo、Hackathon 项目、企业内部系统，自托管一个实例就能用。
  • 需要统一认证 + 文件 + 数据库 + 定时任务的中型项目：比一个个集成 Firebase Auth + S3 + Cloud Functions 更省事。

不太适合的场景：极大规模、对延迟和地域合规有严格要求、需要专用数据库特性（例如 Postgres 的复杂 SQL、地理空间查询等）的项目——这些场景更适合专用数据库加少量业务代码。

Appwrite 与 Supabase：定位上的差异

两者常被拿来比较，都自称”开源 Firebase 替代”，但侧重点不同。

| 维度 | Appwrite | Supabase |
| — | — |
| 底层数据库 | MariaDB | PostgreSQL |
| 主打平台 | 移动 / 全端（iOS、Android、Flutter 优先） | Web / Postgres SQL 优先 |
| API 风格 | 自己的 REST + 实时订阅 | REST + GraphQL + 直接 SQL + RPC |
| 函数 | 内置 Functions，多 runtime | Edge Functions（Deno） |
| 实时 | Realtime 订阅（数据库与消息） | Realtime 订阅 + Postgres 触发器 |
| 部署 | 自托管 + Cloud + 多家云市场 | 自托管 + Cloud |
| 鉴权集成 | 邮箱 / SMS / OAuth / MFA / 魔法链接 / 匿名 | 邮箱 / OAuth / 魔法链接 / SAML 等 |

简单来说：如果你的团队对 SQL、视图、Postgres 生态熟悉，需要复杂查询或 BI 集成，Supabase 用起来更顺；如果团队更关注移动端 SDK 体验、跨平台一致性、不想写 SQL 而偏向 RESTful 调用、希望内置 SMS/Push 之类消息通道，Appwrite 是个更直接的选择。 这只是定位上的差异，不是说谁绝对更好。

上手路线建议

第一次接触 Appwrite，建议这样安排：

  1. 先试托管版：去 cloud.appwrite.io 注册一个项目，跑一遍 Auth + Database 的创建流程，5 分钟就能体验到完整链路。
  2. 再决定是否自托管：如果对数据合规、成本、独立部署有要求，再回到 Docker 那条命令本地跑一份，长期使用记得做数据备份和升级路径规划。
  3. 按平台走 Quick Start：README 给出了每个平台（Web、Next.js、React、Vue、Flutter 等）的快速入门文档，按你用的框架点进去照着抄一遍初始化代码即可。
  4. 权限和密钥：浏览器端用 Web SDK 是公开密钥，敏感操作（写库、改文件、管理用户）走 Server SDK 配 API Key，分清这条边界再上线。

Appwrite 并不是要替代所有后端，它适合”想要一套能撑住 80% 通用需求的开箱即用后端、同时又要可控可改”的团队。对于想从 Firebase 迁出但又不想自己拼一套 Postgres + Auth0 + S3 的开发者来说，它是值得认真看一眼的选项。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。