一个周末搭完App后端：Firebase开源平替，认证/数据库/存储/函数全包了

做过独立开发的朋友应该都有过这种经历：脑子里有一个 App 的雏形，界面想得很清楚，功能也列得明明白白，结果一动工就卡在后端。用户登录要自己写一套认证，数据要存起来就得搭数据库，头像和文件上传要弄个对象存储，再来个支付回调、定时任务，还得自己上云函数。这些活儿每一件单拎出来都不算难，但堆在一起，独立开发者一人分饰五六个角色，没两个月根本收不了尾。更要命的是，等你把这些基础设施搭完，做产品的热情也消耗得差不多了。

我之前推荐过 Supabase，那条路线适合那些「以 Postgres 为核心、想要把数据库握在自己手里」的人。但还有另一类需求——你不只想解决数据库，你想要的是一整套开箱即用的后端：认证、存储、函数、实时推送、甚至前端托管，最好一个面板全搞定，能自托管，数据完全在自己服务器上。这种「全功能 BaaS」的诉求，正是 Appwrite 这次要出场的原因。一个 Docker 命令拉起来，浏览器打开就是一个完整的后端控制台，认证、数据库、存储、函数、消息、站点托管全在里面。今天就把它掰开揉碎讲一遍，独立开发者和小团队真的值得收藏。关注「Ghub龙珠雷达」，每天挖一个能让你少写两万行代码的开源神器。

▲ Appwrite

先说它是什么

Appwrite 是一个开源的、一体式开发平台，定位是把后端基础设施和 Web 托管整合在一个地方，让团队不用再东拼西凑一堆碎片化的服务。官方一句话定义很直接：「build, ship, and scale without stitching together a fragmented stack」——别再缝合一个四分五裂的技术栈了。

项目地址：appwrite/appwrite，目前 GitHub 上 5.6 万 Star，主语言是 TypeScript。它既提供托管的 Appwrite Cloud（公测期免费、不要信用卡），也完全可以自托管在你自己的服务器上，数据 100% 自己掌控。这是它和那些纯 SaaS BaaS 最大的不同——Cloud 和自托管用的是同一套代码，你今天用 Cloud 跑通，明天想搬到自家机房，平滑迁移，没有「厂商绑架」那一说。

它为什么火？本质上是它把 Firebase 那套模式做成了开源、可自托管的版本。Firebase 用起来确实爽，认证、数据库、存储、函数一应俱全，但它锁死在 Google 云上，数据拿不出来，免费额度一过账单就开始飙。Appwrite 把同样的能力搬到你自己服务器上：认证、数据库、存储、函数、消息、实时、站点托管，全部开源、全部本地化。对国内开发者还有一层利好——自托管意味着访问不再受限于网络，体验比 Firebase 顺畅太多。

怎么装

Appwrite 的部署方式相当干净——Docker 一条命令搞定，这也是它设计上的核心思路：整个平台跑在容器里，docker-compose 一拉就起来，也能部署到 Kubernetes、Docker Swarm、Rancher 上。前置条件只有一个：机器上先装好 Docker。

Unix/macOS 下是这样：

# 1. 确认 Docker 已安装并运行
docker --version

# 2. 一条命令安装 Appwrite（当前版本 1.9.0）
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

Windows 下对应有 CMD 和 PowerShell 两套写法，区别只是续行符（CMD 用 ^，PowerShell 用反引号）。安装完之后，浏览器打开 http://localhost（注意端口是 20080，根据上面 publish 的映射来），就能看到 Appwrite 控制台了。非 Linux 原生主机上，服务起来可能要等几分钟，耐心一下。

常见坑一：Docker Desktop 没启动就跑命令。 Windows 和 Mac 用户经常犯这个错，命令报错「Cannot connect to the Docker daemon」。先把 Docker Desktop 打开，等小鲸鱼图标变绿再执行。

常见坑二：老版本升级直接覆盖。 官方明确说了，从老版本升级要用 Appwrite 的迁移工具（migration tool），不要直接覆盖装，否则数据库容易出乱子。

不想自己装 Docker？README 里还列了一键云部署：DigitalOcean、Akamai Compute、AWS Marketplace 都有现成的镜像，点几下就能起一个实例，适合纯小白或者想快速试水的人。

核心功能详解

一、Appwrite Auth：认证开箱即用

认证是几乎所有 App 的第一道门槛，也是独立开发者最容易耗时间的地方。Appwrite Auth 把这套东西全打包了：邮箱密码、手机短信、OAuth（Google、GitHub、Apple 等一大票）、匿名会话、Magic Link 邮箱登录——这些登录方式你不用自己实现任何一个，SDK 一调就通。

更关键的是它带了会话管理、多因素认证（MFA）、用户验证流程这些「企业级」功能。比如你做个金融类 App，监管要求强制开 MFA，Appwrite 后台一个开关就开启；用户注册完要邮箱验证，也是配置一下就行。我自己用过几次，从「想加个登录」到「登录跑通」，真的就是一两个小时的事。

二、Appwrite Databases：结构化数据存储

Appwrite 的数据库是「数据库 → 表 → 行」的三层结构，支持查询、分页、索引、关系（relationships）。这意味着你可以用它建模相对复杂的应用数据，不是那种只能存 JSON 文档的玩具数据库。

实际用法上，你在控制台里建库、建表、定义字段、加索引，然后通过 SDK 增删改查。它支持关联关系这一点很实用——比如「用户」表关联「订单」表，查用户的时候能带出他的所有订单，不用自己写 join 逻辑。配合下面要说的实时功能，数据一变动，前端立刻就能收到推送。

值得说一下它和 Supabase 的区别：Supabase 的核心是直接给你一个完整的 Postgres，你能写原生 SQL，能接任何 Postgres 工具；Appwrite 的数据库则是封装好的结构化存储，不暴露 SQL，所有操作走它的 API。前者灵活、可控、对 SQL 老手友好；后者上手快、统一管理、跨端 SDK 一致。选哪个看你更在意「直接掌控数据库」还是「后端整体省心」。

三、Appwrite Storage：文件存储带压缩和转换

文件上传下载这种活儿，看着简单，自己实现就一堆边角问题：大文件分片、图片压缩、加密、CDN 加速、权限控制。Appwrite Storage 把这些全收了——支持上传、下载、加密、压缩，以及对媒体文件的转换（比如图片缩放、格式转换）。

我个人的体会是，做 App 的时候头像、附件、用户上传的图片，直接丢给 Storage 处理，前端拿 SDK 上传，后端自动压缩归档，省下不少时间。权限粒度也能精确到文件级别，谁能读、谁能写，配置清楚就行。

四、Appwrite Functions：15 种运行时的 Serverless

光有数据存取还不够，后端总有些自定义逻辑要跑——发个邮件、做个定时任务、处理 Webhook。Appwrite Functions 是一个 Serverless 计算平台，让你在隔离的运行时里跑自定义后端代码，可以由事件触发，也能定时调度。

它目前支持 15 种运行时，Node.js、Python、PHP、Ruby、Deno、Dart、Java、Kotlin、Swift、C++、.NET、Bun、Go 等主流语言都在里面，几乎你能想到的后端语言都覆盖了。这点对独立开发者很友好——你熟悉啥语言就用啥写函数，不用为了迁就某个平台去学新东西。

举个具体场景：用户下单后自动发一封确认邮件、每周一凌晨统计上周活跃用户数推到企业微信、GitHub 有新 issue 自动同步到你的项目管理工具——这些都能用 Functions 写成几十行代码的小任务，定时或事件触发，自动跑。

五、Messaging 和 Sites：消息推送 + 站点托管

这两个能力是 Appwrite 区别于一般「自托管后端」的地方。Messaging 是多通道消息系统，能发邮件、短信、推送通知（push），做用户运营、报警、交易通知都很合适。Sites 则是它内置的站点托管平台，支持自定义域名、SSR、Git 集成、预览部署——换句话说，前端代码也能直接托管在 Appwrite 上，前后端一体化。

这一点对独立开发者意义很大：你不用再前端丢 Vercel、后端丢自家服务器、数据库又另找一家，东拼西凑。一个 Appwrite 实例，前端代码、后端 API、数据库、认证、存储全在一起，Git push 一下自动部署，预览环境自动生成。真·一个人当一个团队用。

实际用下来最好的场景

独立开发者快速做 App 后端

这是 Appwrite 最经典的用法。你做一个移动 App 或者 Web 应用，不想为了后端搭一套技术栈，用 Appwrite 一晚上就能把认证、数据库、存储、推送全部跑通。配合它齐全的多端 SDK（Web、iOS、Android、Flutter、React Native、Apple、Android Native 都有），前端用什么技术栈都能无缝对接。我自己见过几个独立开发者的产品，后端就是 Appwrite 单实例撑起来的，月活几千完全不压力。

企业内部工具自托管，数据不出公司

不少公司对外部 SaaS 有合规限制，客户数据、员工数据不能扔到第三方云上。Appwrite 自托管完美解决这个矛盾——能力对标 Firebase，但数据 100% 在自家服务器，过等保、过内部审计都没问题。内部用的工单系统、审批系统、知识库，用 Appwrite 做后端，开发周期比从零搭短一半。

替代 Firebase 做成本控制

Firebase 一旦用户量上来，账单涨得飞快——尤其是实时数据库和存储，按操作计费很容易爆。把同样的业务搬到自托管的 Appwrite 上，成本基本就是你那台服务器的固定开销。能力没缩水，账单从「不可预测」变成「可控的固定支出」，这是很多团队迁移的核心动机。

给 AI 应用当后端

Appwrite 在新版定位里也明确提到了支持构建 AI 应用。AI 应用需要的用户体系、对话记录存储、文件上传（用户传图传文档）、函数调用（接 LLM API）、消息推送（任务完成通知），Appwrite 全都有。你写个 AI 应用，前端调 Appwrite 的 SDK 存数据，后端用 Functions 调 OpenAI、Anthropic 的 API，整套链路一条龙。

适合谁

• • 独立开发者、个人开发者，想一个人快速做出带完整后端的 App
• • 小团队创业，不想花几个月搭后端基础设施，先把 MVP 跑起来
• • 对数据合规有要求、必须自托管的企业内部项目
• • 想从 Firebase 迁移出来做成本控制、或摆脱厂商绑架的团队
• • 做 AI 应用、需要一个能存数据、跑函数、发推送的全栈后端

不适合谁：深度依赖原生 SQL、需要复杂数据库运算（比如大量存储过程、复杂 join）的人——Appwrite 的数据库是封装好的结构化存储，不暴露 SQL，这种场景 Supabase 更合适；以及完全不想碰命令行、要纯图形化一键管理的人，自托管这条路对你来说门槛略高。

写在最后

Appwrite 让我最感慨的一点是，它把「做一个完整产品需要的所有后端能力」打包成了一个开源、可自托管的整体。以前独立开发者要当全栈工程师，认证、数据库、存储、函数样样自己来，一转眼两三个月过去了，产品还没影；现在 Docker 一拉，控制台一开，专注写业务逻辑就行。它和 Supabase 各有侧重——一个走「全功能 BaaS」路线，一个走「以 Postgres 为核心」路线，看你的需求挑就行。如果你下一个项目正好缺后端，这次别再从零开始搭了，给 Appwrite 一个晚上的时间试试。

关注「Ghub龙珠雷达」，每天一个能让你少走弯路的开源工具，咱们下篇见。

雷达持续扫描中，有想了解的工具随时留言。

— 龙珠雷达持续扫描中 —