CoreBunch/Instatic：开源、自托管的可视化 CMS，支持 AI Agent 构建静态网站

拥有你的网站，享受构建的过程。

一个自托管 CMS：可视化编辑器、内容引擎和发布器全部运行在同一个 Bun 服务器中——而它输出的页面足够干净，甚至可以直接在查看源代码时阅读。

一键部署 · 快速开始 · 文档 · 插件 · 路线图

在 YouTube 上观看 Instatic 介绍视频。

现代网站通常意味着要拼装一套技术栈：无头 CMS、框架、托管服务、表单服务、分析供应商、图片 CDN——每一项都有自己的账单、控制面板，以及凌晨 2 点可能发生的故障。Instatic 的赌注恰恰相反。一个 Bun 服务器承载全部内容——画布编辑器、内容引擎、媒体、认证、表单、插件和发布器——你可以在任意位置运行它，并由 SQLite 或 Postgres 提供数据支持。

最终输出的内容，是大多数网站构建者暗中妥协的部分：纯粹的语义化 HTML 和紧凑 CSS，页面中不留下任何编辑器机制。没有框架运行时，没有构建器属性，没有 div 堆砌。网站加载起来像一个静态文件，因为大多数时候它确实就是静态文件。

MIT。自托管。属于你。

Railway 是让 Instatic 快速上线的最快方式。选择一个模板，点击按钮，等待约两分钟，就完成了。它会自行生成密钥、挂载存储卷并配置健康检查。你无需打开终端。

一分钟上线。未经剪辑。

提供商	数据库	最适合的场景	部署
Railway · 推荐	SQLite	单个网站——博客、作品集、小型企业网站	部署 →
Railway	Postgres	多位作者、托管备份、未来扩展空间	部署 →
Render	SQLite 或 Postgres	偏好 Render 服务、磁盘和托管 Postgres 的团队	指南 →
Docker / VPS	SQLite 或 Postgres	使用自有服务器、Caddy TLS 和自定义备份策略	指南 →

对于大多数网站，SQLite 是正确的默认选择。当你拥有一个作者团队，或希望使用托管数据库备份时，再选择 Postgres。

更新只需重新部署

当有新版本的 Instatic 可用时，通过重新部署最新镜像即可更新。你的数据库和上传文件会保留在已挂载的存储中，因此可以替换应用容器，而无需从头重建网站。

更倾向于使用自己的硬件？Instatic 是一个单独的 Docker 镜像：

INSTATIC_IMAGE=ghcr.io/corebunch/instatic:latest docker compose -f compose.prod.yml -f compose.sqlite.yml up -d

完整的 VPS、Postgres、使用 Caddy 配置 HTTPS、Render 和备份指南见 docs/deployment。

一个工具，覆盖网站的整个生命周期

大多数工具只完成一项工作，然后将其余工作交给你。你在一个地方设计，在另一个地方构建，把内容放在别处，再从第四个地方接入分析工具。Instatic 则把这些全都包含在内。以下是它实际提供的功能。

编辑器是一个真正的画布，而不是在表单上勉强附加一个预览窗格。你可以将多个断点框架并排放置并同时编辑。修改桌面端时，移动端框架会在同一视图中作出响应。当你更愿意直接处理真实页面时，可以切换至实时模式，在原位编辑单个全尺寸页面。

没有其他产品具备的部分是：内置 Core Framework。 这是数千名 WordPress 专业人士每天都在使用的设计令牌引擎；在这里，它是核心系统，而非一个安装后只能祈祷正常运行的插件。

• 可自行生成色阶的颜色令牌。 定义一个品牌色，即可自动获得完整的一组调校过的浅色和深色色阶。
• 流式且基于数学规则的字体比例。 使用一条随视口变化而缩放的比例曲线，取代 40 个需要持续保持同步的手动字号。
• 间距比例，让每个页面和每个断点维持同样的节奏。
• 实用类生成器，将锁定的生成类输出到一个小型 framework.css 文件中。没有臃肿，没有重复规则，也不会生成你未要求的内容。

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

• **模块（Modules）**是基础构件：容器、文本、图片、按钮、视频、列表、链接、SVG、表单。将它们拖入画布，并按需要任意嵌套。
• Visual Components 是具有类型化参数和命名插槽的可复用单元。参数可以是字符串、数字、布尔值、颜色、图片、URL、富文本、枚举值，或完整的内容插槽。编辑一次组件，站点中的每个实例都会更新。可能自我引用的组件会在发生前被阻止，因此不会出现自我循环。
• **模板（Templates）**处理共享框架。可为全站使用一个布局，为不同文章类型使用独立布局，并设计一个真正属于你自己的 404 页面。内容会流入一个 outlet，因此页头和页脚只需编写一次，便可包裹所有内容。
• **循环（Loops）**可将一个布局重复应用于集合：文章、页面、媒体，或任意由插件作为来源暴露的数据。为循环提供几个变体，它会在运行时交替使用。适用于文章列表、产品网格和图库。
• 属于你的 CMS 的表单。 使用语义化字段构建表单，提交内容会进入你自己的数据表。Instatic 可以读取你放置的字段，并为你创建匹配的数据表。无需第三方表单服务，无需嵌入代码，也无需为联系表单支付月费。
• 真正编辑页面的 AI Agent。 描述你的需求，它会在画布上将其构建为真实、可编辑的节点，而不是一张截图或一整面代码。它通过与你粘贴标记时相同的导入管线，为结构编写语义化 HTML，为样式编写 CSS。拥有 35 个工具的 Site 范围可构建页面；拥有 15 个工具的 Content 范围可编辑内容条目。自带模型：Claude、OpenAI、OpenRouter 或本地 Ollama。你的密钥、你的模型、你的账单。
• 可靠的导入能力。 粘贴原始 HTML，即可获得可编辑节点。或者导入整个静态网站——HTML、CSS、图片、字体——Super Import 会将其转换为页面、样式规则、设计令牌和媒体。所有冲突都会在写入前展示给你，且整个导入过程可通过一次撤销恢复。

• 统一的底层内容模型。 页面、文章、组件、自定义集合，以及你定义的任意结构化表格，全部存储在同一套存储中：data_tables 和 data_rows。不存在隐藏在角落里的特殊“pages”表。模式、原始行、导入、导出和表单提交都位于同一个一致的位置。
• 用于设计自定义集合的数据工作区。 在 /admin/data 中，你可以创建具有自有字段的自定义文章类型和自定义数据表，然后在电子表格式网格中处理行数据：搜索、排序、筛选、批量发布、批量导出。自定义文章类型拥有真正的编辑工作流——草稿、定时发布、已发布——并为已发布副本提供版本历史。普通数据表则是简单的网格，可指向任何内容：表单提交、产品目录、轻量级 CRM 或推荐语列表。你构建的每张表都可以成为循环可渲染的内容来源。只需定义一次“团队”表，再将其循环渲染到“关于我们”页面，即可完成。
• 面向写作的内容工作区。 为文章和集合提供专注的编辑界面，并提供实时模式，让作者可以直接在网站的真实设计中编辑，而不是面对一个灰色文本框。
• 像文件管理器一样工作的媒体工作区。 提供文件夹和智能文件夹、批量操作、使用情况跟踪以确认文件实际被用于何处、替换工作流，以及当本地磁盘不再满足需求时可用的可插拔存储适配器。
• 真实而非装饰性的访问控制。 基于 38 项能力构建的角色、基于令牌的会话、静态加密密钥的 TOTP 双因素认证、连续失败后的带退避机制账户锁定，以及删除用户、让所有设备退出登录等危险操作前的加强确认提示。
• ⌘K 覆盖一切。 覆盖整个管理后台的模糊搜索命令面板。无需触碰鼠标，即可跳转至任意位置、执行任何操作。
• 草稿始终是草稿。 未发布的修改绝不会泄露给访客。你没有发布的内容，他们就不会看到。

• 可自行编排的仪表盘。 一个由磁贴小组件组成的 12 列网格，你可以拖动、调整大小和重新排列。在自定义模式中添加你关心的小组件，布局会按用户保存。插件也可以将自有小组件加入同一网格。
• 不会遗忘的审计日志。 每项重要的管理操作都会写入一行记录：登录、内容变更、角色编辑、插件生命周期事件。日志为只追加模式，因此它真实记录了谁在何时做了什么，而不是任何人都能悄悄改写的内容。
• 属于你的表单数据。 提交内容存放在你自己的表中。你可以查询、导出并在其基础上构建功能。没有中间供应商。

当前的分析界面有意聚焦于运营：仪表盘状态、审计历史和自有表单数据，而不是第三方访客追踪。

每个 CMS 都有插件。这里的区别在于后端插件代码的运行位置。

Instatic 插件是带有清单文件的 zip 包。其服务器入口点运行在每插件独立的 worker 中，该 worker 承载一个 QuickJS-WASM 沙箱：没有文件系统、没有环境变量、完全没有网络访问，除非网站所有者明确授予权限；一次仅托管一个插件。编辑器扩展和 app-kind 管理页面则不同：它们在管理后台窗口中运行，并且必须在安装前获得明确的 editor.code 权限。

通过 SDK，插件可以添加：

• HTTP 路由和自己的管理页面
• 存储与定时后台任务
• 循环数据源，让内容循环可以从任意位置拉取数据
• 画布模块——在编辑器中显示的新区块
• 媒体存储适配器和前端资源
• 覆盖安装、激活及后续阶段的生命周期钩子

请从插件系统文档和模板插件开始。

快，因为几乎没有什么需要加载

已发布的 Instatic 页面基本就是一个文件，

Own your site. Love building it.

A self-hosted CMS where the visual editor, content engine, and publisher all live in one Bun server — and the pages it ships are clean enough to read in view-source.

One-Click Deploy · Quick Start · Docs · Plugins · Roadmap

Watch the introductory video about Instatic on YouTube.

A modern website usually means assembling a stack: a headless CMS, a framework, a host, a form service, an analytics vendor, an image CDN — each with its own bill, dashboard, and 2 a.m. outage. Instatic is the opposite bet. One Bun server holds the whole thing — the canvas editor, the content engine, media, auth, forms, plugins, and the publisher — and you run it wherever you like, backed by SQLite or Postgres.

What comes out the other end is the part most builders quietly compromise on: plain semantic HTML and compact CSS, with none of the editor's machinery left behind in the page. No framework runtime, no builder attributes, no div soup. The site loads like a static file because, most of the time, it is one.

MIT. Self-hosted. Yours.

Railway is the fastest way to get Instatic live. Pick a template, hit the button, wait about two minutes. That's it. It generates the secret keys, attaches the storage volume, and sets up the health checks on its own. You never open a terminal.

One minute to live. Unedited.

Provider	Database	Best for	Deploy
Railway · Recommended	SQLite	A single site — blog, portfolio, small business	Deploy →
Railway	Postgres	Multiple authors, managed backups, room to grow	Deploy →
Render	SQLite or Postgres	Teams that prefer Render services, disks, and managed Postgres	Guide →
Docker / VPS	SQLite or Postgres	Bring-your-own server, Caddy TLS, custom backup policy	Guide →

SQLite is the right default for most sites. Reach for Postgres when you've got a team of authors or want managed database backups.

Updating is just a redeploy

When a new Instatic version is available, update by redeploying the latest image. Your database and uploads stay on the attached storage, so the app container can be replaced without rebuilding the site from scratch.

Prefer your own hardware? Instatic is a single Docker image:

INSTATIC_IMAGE=ghcr.io/corebunch/instatic:latest docker compose -f compose.prod.yml -f compose.sqlite.yml up -d

Full guides for VPS, Postgres, HTTPS with Caddy, Render, and backups are in docs/deployment.

One tool, the whole life of a site

Most tools do one job and hand you off for the rest. You design in one place, build in another, keep content somewhere else, then bolt analytics on from a fourth. Instatic does all of it. Here's what's actually in the box.

The editor is a real canvas, not a form with a preview pane stapled to it. You put several breakpoint frames side by side and edit them together. Change the desktop and the mobile frame reacts in the same view. When you'd rather work on the real thing, flip to live mode and edit a single full-size page in place.

The part nobody else has: Core Framework is built in. It's the design-token engine thousands of WordPress pros already use every day, and here it's a core system, not a plugin you install and pray over.

• Color tokens that generate their own shade scale. Define one brand color, get the full set of tuned tints and shades automatically.
• Type scales that are fluid and mathematical. One ramp that scales with the viewport, instead of forty hand-picked font sizes you have to keep in sync.
• Spacing scales so every page and every breakpoint keeps the same rhythm.
• A utility-class generator that emits locked, generated classes into one small framework.css. No bloat, no duplicate rules, nothing you didn't ask for.

Your whole design system lives as data. Change one token and every page that uses it updates.

• Modules are the building blocks: containers, text, images, buttons, video, lists, links, SVG, forms. Drag them onto the canvas and nest them however you want.
• Visual Components are reusable pieces with typed parameters and named slots. A parameter can be a string, number, boolean, color, image, URL, rich text, an enum, or a whole slot of content. Edit the component once and every instance on the site updates. Components that would reference themselves are blocked before they happen, so nothing eats its own tail.
• Templates handle the shared chrome. One layout for the whole site, separate layouts per post type, and a real 404 page you design yourself. Content flows into an outlet, so a header and footer get written once and wrap everything.
• Loops repeat a layout over a collection: your posts, your pages, your media, or anything a plugin exposes as a source. Give a loop a couple of variants and it alternates between them as it goes. Good for post lists, product grids, galleries.
• Forms that belong to your CMS. Build a form out of semantic fields and the submissions land in your own data tables. Instatic can read the fields you placed and create the matching table for you. No third-party form service, no embed, no monthly fee for a contact form.
• An AI agent that actually edits the page. Describe what you want and it builds it on the canvas as real, editable nodes, not a screenshot or a wall of code. It writes semantic HTML for structure and CSS for style, through the same import pipeline you use when you paste markup. A 35-tool Site scope builds pages; a 15-tool Content scope edits entries. Bring your own model: Claude, OpenAI, OpenRouter, or local Ollama. Your key, your model, your bill.
• Imports that hold up. Paste raw HTML and get editable nodes. Or drop a whole static site — HTML, CSS, images, fonts — and Super Import turns it into pages, style rules, design tokens, and media. Every conflict is shown to you before anything is written, and the entire import is a single undo.

• One content model under everything. Pages, posts, components, custom collections, and any structured table you invent all live in the same store: data_tables and data_rows. There's no special-cased "pages" table hiding in a corner. Schemas, raw rows, imports, exports, and form submissions all sit in one consistent place.
• A Data workspace where you design your own collections. At /admin/data you create custom post types and custom data tables with their own fields, then work the rows in a spreadsheet-style grid: search, sort, filter, bulk publish, bulk export. Custom post types come with a real editorial workflow — draft, scheduled, published — and version history on the published copy. Plain data tables are simple grids you can point at anything: the submissions from a form, a product catalog, a lightweight CRM, a list of testimonials. And every table you build is a content source a loop can render. Define a "Team" table once, loop it onto your about page, done.
• A content workspace for writing. A focused surface for posts and collections, plus live mode so authors edit inside the real design of the site instead of a gray textarea.
• A media workspace that works like a file manager. Folders and smart folders, bulk operations, usage tracking so you know where a file is actually used, replacement workflows, and pluggable storage adapters when you outgrow local disk.
• Access control that's real, not decorative. Roles built from 38 capabilities, token-based sessions, TOTP two-factor with secrets encrypted at rest, account lockout with backoff after repeated failures, and step-up prompts before the dangerous stuff like deleting a user or signing out every device.
• ⌘K for everything. A fuzzy command palette over the whole admin. Jump anywhere, do anything, without touching the mouse.
• Drafts stay drafts. Unpublished edits never leak to a visitor. What you didn't publish, they don't see.

• A dashboard you arrange yourself. A 12-column grid of tile widgets you can drag, resize, and rearrange. Add the ones you care about in customize mode, and the layout saves per user. Plugins can ship their own widgets into the same grid.
• An audit log that doesn't forget. Every meaningful admin action writes a row: logins, content changes, role edits, plugin lifecycle. It's append-only, so it's a real record of who did what and when, not something anyone can quietly rewrite.
• Form data that's yours. Submissions sit in your own tables. Query them, export them, build on them. No vendor in the middle.

The analytics surface today is intentionally operational: dashboard status, audit history, and owned form data instead of third-party visitor tracking.

Every CMS has plugins. The difference here is where backend plugin code runs.

An Instatic plugin is a zip package with a manifest. Its server entrypoint runs in a per-plugin worker that hosts a QuickJS-WASM sandbox : no filesystem, no environment variables, no network at all unless the site owner grants it, one host at a time. Editor extensions and app-kind admin pages are different: they run in the admin window and require the explicit editor.code permission before install.

Through the SDK, a plugin can add:

• HTTP routes and its own admin pages
• Storage and scheduled background jobs
• Loop data sources, so your content loops can pull from anywhere
• Canvas modules — new blocks that show up in the editor
• Media storage adapters and frontend assets
• Lifecycle hooks across install, activation, and beyond

Start with the plugin system docs and the template plugin.

Fast because there's almost nothing to load

A published Instatic page is mostly just a file sitting on disk. No framework to boot, no hydration step, no database round-trip on the common path. The browser pulls down semantic HTML and compact CSS bundles, and it's done. There's barely anything between the visitor and the content, so the pages feel instant.

That speed isn't a setting you tune. It falls out of how publishing works, in three layers you never have to think about:

• Static pages are baked straight to disk when you publish and swapped in atomically. Visitors are served a file, not a render.
• Routes that genuinely change hit a versioned in-memory cache. Publishing bumps the version, so old entries miss lazily and nobody sees a stale page.
• The few truly per-visitor parts are detected automatically and lazy-loaded by a runtime that weighs about 1.1 kB. Smaller than this paragraph.

What comes out the other end is plain HTML and compact CSS, all the way down. Nothing from the editor rides along: no React on your public pages, no editor runtime, no framework in the markup. And because it's just HTML and CSS, nothing holds your site hostage — you can read it, host it anywhere, or take it and leave. Full design: the publisher.

You need Bun. Nothing else. The default dev setup runs on SQLite, so there are no extra services to stand up.

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

Open http://localhost:5173. The first visit walks you through creating your site and your owner account.

Want to see it the way it actually ships? bun run start builds the admin and serves it from the Bun server at http://localhost:3001/admin.

Backups, in one sentence: back up the database (a Postgres dump or the SQLite file) and the uploads folder, and you've backed up the whole site — details.

We're the team behind Motion.page and Core Framework — tools that thousands of people use to build websites for a living, mostly in the WordPress world.

We spent years making other platforms more bearable. At some point the obvious question wouldn't go away: what if the thing underneath was just right to begin with? No legacy to work around, no markup we're not allowed to touch, no business model that depends on keeping your site where we can see it.

So we built Instatic. And we brought Core Framework along, wired in as a core system, so the color shades, type scales, spacing, and utility classes our users already rely on are part of the product — not an add-on you install and hope for the best.

Here's the honest part: this is version 0.0.x.

Everything above — the canvas, Core Framework, the universal content model, the sandboxed plugins, the AI agent, forms, loops, templates, media, MFA, the audit log, one-click deploy, the clean publisher — is the starting line, not the finish. What's coming:

• Real analytics. First-party and privacy-respecting, to round out the Analyze pillar.
• A bigger module and plugin ecosystem. More first-party blocks, more SDK surface, more examples to copy from.
• A sharper AI agent. More tools, deeper awareness of your actual site.
• Everything tighter. We're pre-1.0 on purpose. It's the cheapest time to throw out bad ideas and keep the architecture clean.

APIs and workflows can still shift before 1.0. If that makes you nervous, wait for 1.0 — no hard feelings. If you'd rather help shape what site ownership looks like for the next twenty years, now's the good seat.

One Bun server. A React admin built with Vite. A publisher that emits pages you'd be happy to have written yourself.

|
---|---
Runtime | Bun, for both server and tooling
Language | TypeScript everywhere
Admin app | React 19 (React Compiler on), Vite, Zustand + Mutative, CodeMirror, dnd-kit
Server | Bun.serve with a hand-written router
Database | SQLite or Postgres — one DbClient interface, picked by DATABASE_URL
Validation | TypeBox at every untyped boundary; schemas are the source of truth
Plugins | QuickJS-WASM backend sandbox, owner-granted permissions, explicit editor.code for admin-window code
AI | Provider-agnostic drivers over raw HTTP/SSE, no vendor SDKs
Output | Semantic HTML, compact CSS, baked static files plus auto-detected dynamic holes

The codebase is opinionated, and the opinions are enforced in code. Architectural rules live in src/__tests__/architecture/ as actual tests, so the structure that keeps the output clean can't quietly rot.

bun run build   # tsc -b && vite build
bun test
bun run lint

Dig in: docs index · architecture · editor · server · publisher · plugin system

Instatic's interface uses Pixelarticons by Gerrit Halfmann. Thanks to Gerrit for a genuinely distinctive icon set, and for kindly letting us use it in an open-source project.

MIT. See LICENSE. No tiers, no open-core asterisks, no "contact sales."