Instatic：开源自托管可视化 CMS，干净 HTML 输出与三层缓存发布管线

GitHub Trending 本周出现了一个增长极快的项目：Instatic，一个自托管的可视化 CMS，定位是 Webflow、Framer 和 WordPress 的开源替代品。5600+ star，日增近 900，MIT 协议，用 TypeScript 写成，跑在 Bun 运行时上。

这不是一个又一个「拖拽建站工具」。Instatic 的核心赌注在于：可视化编辑器产出的页面是干净的语义 HTML 和精简 CSS，不带任何框架运行时、不带编辑器残留标记、不带 div 套娃。发布后的页面本质上就是一个静态文件，加载速度接近即时。

架构：一个 Bun 进程搞定一切

Instatic 的架构理念极其克制。一个 Bun 进程同时承载公共网站服务、管理后台编辑器、CMS API、已发布页面和上传媒体。没有消息队列，没有独立的微服务，没有需要单独部署的渲染引擎。

数据库层支持 SQLite 和 Postgres 双引擎，通过 DATABASE_URL 环境变量切换。所有仓储层代码使用纯 ANSI SQL，Postgres 特有语法（::int、::jsonb、any($N::...)、distinct on）在整个代码库中被禁止使用。这意味着同一套业务逻辑可以无缝运行在轻量 SQLite 和生产级 Postgres 上。

Bun 进程内有两个 Worker 线程家族负责重 CPU 任务：

• 插件服务器代码运行在 QuickJS-WASM 沙箱中，每个活跃插件一个独立 Worker。沙箱内没有文件系统访问、没有环境变量、没有网络权限（除非站点所有者显式授予）。一个插件崩溃不会影响主进程，且会被自动重启。
• 图片变体生成（sharp 缩放 + WebP 编码 + BlurHash）运行在独立 Worker 池中。一张 400 万像素 JPEG 的处理耗时约 200-500ms，放到 Worker 中避免阻塞主线程上的访客请求和 API 调用。

对于 Postgres 多实例部署，两个调度器（插件 tick 和定时发布）通过 pg_try_advisory_lock 实现领导者选举，确保多个容器在负载均衡器后不会重复触发定时任务。SQLite 模式则直接跳过这一层。

发布管线：三层缓存架构

Instatic 最值得关注的技术设计是它的三层发布管线。这是它能输出「像静态文件一样快」的页面的根本原因。

Layer A：静态页面烘焙。当点击发布时，完全静态的页面和动态页面的静态外壳被直接烘焙到磁盘上（uploads/published/current/<route>.html），通过双槽符号链接原子交换完成。访客请求直接命中磁盘文件，不经过任何渲染路径。

Layer B：内存 LRU 缓存。对于需要实时渲染的路由，系统使用版本化的内存 LRU 缓存，键为 (urlPath, canonicalQuery)。每次发布时版本号递增，旧缓存条目在下次访问时惰性失效。更关键的是，版本号在渲染开始时就捕获，如果发布发生在渲染过程中，渲染结果会被丢弃而非缓存，避免访客看到过期内容。

Layer C：Server Islands 自动检测。系统自动检测页面中的动态节点（标记为 dynamic: true 的模块、请求依赖/访客级别的绑定、包含动态内容的循环源等），在静态 HTML 中插入 <instatic-hole> 占位符，由一个约 1.1KB 的 IntersectionObserver 运行时按需懒加载。开发者不需要手动标记动态区域，findDynamicNodeIds 函数在发布时自动分类。

这个设计的结果是：大多数页面就是磁盘上的一个文件，没有框架启动、没有水合（hydration）步骤、没有数据库查询。浏览器拿到语义 HTML 和精简 CSS 就完事了。

内容模型：统一数据表

Instatic 没有传统的 pages 表、posts 表、versions 表这种分表设计。所有内容形态都存在两个表里：data_tables（集合定义）和 data_rows（数据行）。

data_tables 的 kind 字段区分用途：

这个设计意味着：创建一个新的「文章类型」只需要往 data_tables 插入一行，定义好 cells schema 就行。表单提交数据、产品目录、轻量 CRM、推荐语列表都可以是自定义数据表，且每个表都可以作为循环渲染的数据源。在 About 页面上定义一个「Team」表，循环渲染上去，就完成了。

AI Agent：真正编辑页面的 AI

Instatic 内置的 AI Agent 是其差异化能力之一。大多数 CMS 的 AI 功能停留在「生成文本」或「生成截图」层面，而 Instatic 的 AI Agent 可以直接在画布上构建真实可编辑的节点。

Agent 拥有两个工具范围：35 个工具的 Site scope 用于构建页面，15 个工具的 Content scope 用于编辑内容条目。它通过和用户相同的导入管线工作：编写语义 HTML 做结构，CSS 做样式。导入管线支持粘贴原始 HTML 转换为可编辑节点，也支持将整个静态站点（HTML、CSS、图片、字体）转换为页面、样式规则、设计令牌和媒体资源。

模型不锁定供应商：Claude、OpenAI、OpenRouter 或本地 Ollama 均可接入，使用用户自己的 API Key 和模型。AI 驱动层通过原始 HTTP/SSE 直接与各供应商通信，不依赖任何厂商 SDK。

设计令牌引擎：Core Framework

Instatic 内嵌了 Core Framework 作为核心系统。这是一个设计令牌引擎，原本是数千名 WordPress 专业用户日常使用的工具，在 Instatic 中被提升为底层基础设施。

它的能力包括：

• 颜色令牌自动生成色阶：定义一个品牌色，自动生成完整的色调和明度梯度。
• 流体排版比例：一个随视口缩放的字号阶梯，而非四十个需要手动同步的字号值。间距比例使用数学比率（如 Major Third 1.25、Augmented Fourth 1.414）。
• 工具类生成器：输出锁定到一个小型 framework.css 中的生成类，没有冗余、没有重复规则。

整个设计系统以数据形式存在。修改一个令牌，所有使用该令牌的页面同步更新。

安全与权限

权限系统不是装饰品。角色由 38 个能力项构建，会话使用 Token 认证，TOTP 双因素认证的密钥加密存储。重复登录失败后触发账户锁定和退避策略，删除用户或登出所有设备等危险操作需要二次确认。

审计日志是只追加的（append-only）：登录、内容变更、角色编辑、插件生命周期等所有有意义的管理操作都会写入一行。这提供了一份真实的操作记录，任何人都无法静默篡改。

插件的安全模型尤为值得注意。插件服务器代码运行在 QuickJS-WASM 沙箱中，默认没有文件系统、环境变量和网络访问。宿主进程从不直接 import 插件代码。画布模块包在服务端通过 QuickJS VM 评估，在浏览器编辑器中以 ESM 运行。编辑器扩展和应用类管理页面需要显式的 editor.code 权限才能安装。

部署与开发体验

一键部署支持 Railway（SQLite 和 Postgres 模板）、Render、Docker/VPS。更新就是重新部署最新镜像，数据库和上传文件保留在持久卷上。

开发环境只需要 Bun：

git clone https://github.com/corebunch/instatic.git
cd instatic
bun install
bun run dev

首次访问 http://localhost:5173 会引导创建站点和管理员账户。

技术栈一览：

代码库有架构约束测试（src/__tests__/architecture/），将架构规则编码为实际测试用例。这些测试确保：zod 在整个仓库中被禁用，Postgres 特有语法不会渗入仓储层，JSON 列命名遵循 _json 后缀约定，数据库迁移在两种方言间保持一致。

项目现状

Instatic 目前是 0.0.x 版本，团队明确表示这是有意为之。所有已有功能（画布编辑器、Core Framework、统一内容模型、沙箱化插件、AI Agent、表单、循环、模板、媒体管理、MFA、审计日志、一键部署、纯净发布器）是起跑线而非终点线。

路线图包括第一方隐私分析、更大的模块和插件生态、更强的 AI Agent。API 和工作流在 1.0 之前可能变动。

团队背景值得留意：他们是 Motion.page 和 Core Framework 背后的团队，这两个工具主要在 WordPress 生态中被数千名用户使用。Instatic 可以理解为他们在 WordPress 世界积累了多年经验后，决定从头构建一个没有历史包袱的 CMS。

项目地址：github.com/CoreBunch/Instatic