2026 年 BookStack 自建 wiki/文档站：5 美元 VPS 替代 Notion（避坑实测）

延伸阅读

更多相关攻略推荐：【10刀以内VPS系列 01】年付不到70块钱的便宜VPS，到底能用、【隐私分析 01】GA4 隐私替代方案 2026：Plausible、【IP 地址 06】IPv4 枯竭之后：CGNAT / NAT64 、【IP 地址 05】IPv6-Only VPS + Cloudfla、512MB/1GB 小内存 VPS 优化实战：1 美元机器能跑什么 。

为什么用 BookStack 替代 Notion / Confluence

团队知识库这件事，大多数人一开始都图省事用 Notion。用着用着就发现：人一多，账单就按席位疯涨；内容越堆越多，想完整导出却处处受限；更别说数据全躺在别人的服务器上。BookStack 是 GitHub 上最火的 PHP wiki 之一，2026 年仍稳定在 v26.x、16k+ stars，MIT 协议，零许可费，你部署在哪台机器上，数据就归你。

它和 Notion 最大的不同是层级结构开箱即用：书架（Shelf）→ 书（Book）→ 章节（Chapter）→ 页（Page）。新人第一天不用自己发明一套文件夹分类，直接往里塞就行。编辑器同时支持所见即所得（WYSIWYG）和 Markdown，老用户写文档、新人看文档都不费劲。对拒绝按席位付费的团队和站长来说，这是很现实的 Notion / Confluence 替代品。

还有一个常被低估的点：BookStack 是单应用、单数据库，没有一堆微服务要养，维护心智负担极低。你不用操心消息队列、缓存集群那一套，一台小 VPS 就能长期稳定运行好几年。对于本来就在付钱的 VPS 用户来说，知识库几乎是白送的附加价值。当你哪天不想用了，整站导出成 HTML 或 PDF 打包带走，没有任何出口壁垒，这一点正是商业 SaaS 最不愿给你的。

配置与资源规划：5 美元 VPS 到底够不够

先说结论：够，但得会选机型。官方核心要求是 PHP ≥ 8.2、MariaDB ≥ 10.6（或 MySQL ≥ 8.0），纯 PHP 应用本身常驻约 150–250MB 内存，MariaDB 再吃 100–200MB，整机空闲约 350–500MB。所以标称 512MB 的小鸡能跑，但几乎没余量；真正舒服的底线是 1GB 内存。

• CPU：1 核即可，文档站读多写少，瓶颈从来不在 CPU。
• 内存：至少 1GB，512MB 仅建议做个人笔记站并关闭 MariaDB 多余缓存。
• 硬盘：系统加数据库 5–10GB 起步，图片、附件多了再扩；优先 SSD。
• 系统：Ubuntu 22.04 / 24.04 最稳，Docker 部署与文档最贴合。

像 RackNerd、CloudCone 这类常年有 1GB 内存、年付几美元机型的活动款，拿来当知识库主机非常合适；如果团队在欧盟，Virtono 的欧洲节点延迟更低。记住：小机跑 BookStack 的关键不是性能，而是把数据库和 PHP 的内存参数压住。具体做法是在 MariaDB 配置里把 innodb_buffer_pool_size 调到 128MB 左右、关掉 performance schema，PHP 侧用默认 FPM 通常足够；512MB 机器还可以在 compose 里给容器加 mem_limit 上限，防止单服务失控拖垮整机。与其抠参数，不如直接上 1GB，省下的调试时间远贵于差价。

Docker 一键部署：docker-compose 实战

最省心的方案是用 LinuxServer 的 lscr.io/linuxserver/bookstack 镜像配一个 MariaDB。先建目录并生成 Laravel 的 APP_KEY（丢了或改了会解密失败、锁死账号，所以只生成一次，当密码一样保管）：

docker run --rm --entrypoint /generate-key.sh lscr.io/linuxserver/bookstack:latest

把输出的整串（含 base64: 前缀）记下来，写进下面的 compose。最小可用配置如下：

version: '3'
services:
bookstack:
image: lscr.io/linuxserver/bookstack:latest
environment:
- APP_URL=http://你的IP:8080
- APP_KEY=base64:你的密钥
- DB_HOST=bookstack_db
- DB_DATABASE=bookstack
- DB_USERNAME=bookstack
- DB_PASSWORD=强密码
ports:
- 8080:80
depends_on:
- bookstack_db
restart: unless-stopped
bookstack_db:
image: lscr.io/linuxserver/mariadb:latest
environment:
- MYSQL_DATABASE=bookstack
- MYSQL_USER=bookstack
- MYSQL_PASSWORD=强密码
- MYSQL_ROOT_PASSWORD=更强密码
volumes:
- ./db:/config
restart: unless-stopped

然后 docker compose up -d，等半分钟初始化，浏览器打开 http://你的IP:8080。默认账号 admin@admin.com、密码 password——第一时间改掉，别等上线被扫库。数据都在本目录的 ./db 卷里，备份这一个目录加一次数据库导出即可整站迁移。

书架 / 书 / 章节 / 页：内容层级怎么用

BookStack 的四级结构不是花架子，而是为了贴合人脑整理知识的直觉：

• 书架（Shelf）：最大的归类，比如「研发部」「产品部」，可放多本书，方便按团队授权。
• 书（Book）：一个完整主题，比如「上线手册」或「API 文档」，是导出 PDF / HTML 的最小单位。
• 章节（Chapter）：书里的分卷，如「部署」「故障排查」，纯逻辑分组，不增加 URL 层级。
• 页（Page）：真正写内容的地方，支持版本历史、评论、标签。

实操建议：先按部门建书架，再按项目建书，章节别太多（三到五层足够），页才是主力。每页都能一键导出 Markdown / HTML / PDF，配合整站或单书导出，离开平台零成本。搜索是全局全文检索，但中文用户要注意下一个坑。

WYSIWYG + Markdown、权限、LDAP/SAML 与 REST API

编辑器方面，BookStack 同时给小白和程序员留了后路：普通同事用所见即所得界面排版，工程师直接在 Markdown 模式敲字，两边都存成同一套内容。权限模型是角色（Role）制的，可以给某本书、某个书架单独授权，实现「研发看得到、外包只给某一本」的隔离。

• LDAP / SAML：支持接入公司目录或企业微信 / 飞书 / Okta 之类的 SSO，全员用统一账号登录，免维护密码。
• REST API：每个站点生成一个 API Token，可程序化读取、创建、更新页面，做自动化文档、定时同步 CI 产物都很顺手。
• 审计与历史：页面有完整修订记录和活动日志，误删能回滚。

对一个小团队来说，这些能力加起来基本覆盖了 Confluence 八成以上的日常场景，而成本只是那台 VPS 的电费。

三个必踩的坑：默认密码、CJK 全文搜索、S3 存储

下面这三个坑，中文圈教程十有八九漏讲，踩了才知道疼。

• 坑一：默认密码不改成灾。admin@admin.com / password 是公开秘密，公网暴露当天就可能被爬。部署完第一件事就是改密码、改管理员邮箱，最好再加反向代理强制 HTTPS。
• 坑二：CJK 全文搜索失效。MariaDB / MySQL 的默认全文索引对中日韩文字几乎不分词，中文搜「部署手册」可能一个结果都搜不到。正解是给数据库开启 ngram 全文分词器（在 my.cnf 设 ngram_token_size=2 并重建索引），BookStack 后端才会对中文正常检索。这一步不做，知识库越大越难用。
• 坑三：S3 存储配错丢附件。想用对象存储（如 S3 / 兼容 S3 的网关）存上传文件，要在 .env 配 STORAGE_TYPE=s3 及 AWS_* 系列变量。常见失误是 region / endpoint 填错、桶没开公开读却引用外链、或迁移后旧附件没同步过去导致图片裂图。上线前务必用一张图实测上传与访问。

从 Notion / Confluence 迁移过来的实操建议

很多团队不是从零开始，而是要先把旧平台的内容搬过来。BookStack 没有官方的 Notion 一键导入器，但路线很清晰：先把 Notion 页面导出成 Markdown 或 HTML 压缩包，再用 BookStack 的页面导入功能逐本重建。目录结构建议一对一映射——Notion 的顶级页对应 Book，子页对应 Chapter 或 Page，标签顺手带上，方便日后检索。

• 图片与附件：Notion 导出时图片常是外链，导入后要手动重新上传到 BookStack，否则换平台就裂图；提前把图片下载到本地再传最稳。
• 表格与数据库视图：Notion 的 database 视图在 BookStack 里没有对应物，只能落成一个普通表格或列表页，团队要接受这种信息密度的下降。
• 权限重做：迁移不是复制，而是借机梳理谁能看什么。借这个机会按书架重新授权，反而能让知识库更干净。

迁移别追求一步到位，先搬最核心的十本书跑起来，团队用熟了再慢慢补。比起被 SaaS 账单绑架，这种可控的过渡反而更踏实。

备份、升级与日常维护

自托管最容易被忽视的就是备份。最小可行方案：每天 mysqldump 导出 bookstack 库，加打包 ./db 里的上传目录，异地存一份（哪怕丢到另一台机器或对象存储）。BookStack 升级用 LinuxServer 镜像时只需 docker compose pull && docker compose up -d，但升级前一定先备份，APP_KEY 切勿改动。小机建议设个定时任务，凌晨低峰期自动拉新镜像重启，基本无感。

如果哪天流量起来、1GB 内存吃紧，优先加 Swap 或原地升到 2GB 机型，BookStack 本身几乎不用改配置。备份到位，迁移就是拷贝目录加导库两步走。最后提醒一句：知识库的价值不在部署那一晚，而在之后半年有没有人愿意持续写。把第一次部署当成引子，配好邮件通知、定好谁来维护目录，比纠结用哪款 VPS 重要得多。一台 RackNerd、CloudCone 或 Virtono 的小机跑上三五年稳如老狗，团队省下的 SaaS 订阅费早就回本了。