Skip to content

OpenIWeb v0.1.0：把运维交给 AI 代理，你只留一把密钥

jixoai v0.1.0 openiweb

OpenIWeb 第一个公开版本：单端口 Rust 内核、MCP 运维面、两层信任运行时、内置 RustFS、可吊销 owner 密钥。把自托管交给 AI 编程代理，把管理收进一把密钥；整节点闲时内存 ≤ 240 MB。

$ curl -H "Host: $IWEB_BASE_HOST" http://127.0.0.1:9010/_iweb/health

OpenIWeb v0.1.0 发布了（2026-09-06，第一个公开版本）。它是开源个人应用节点：你不需要理解容器、数据库或网络运维；把 MCP 端点和一把密钥交给 AI 编程代理（Codex、Claude Code……），应用就部署和运行在你自己的节点上；你用一个浏览器控制台和一把密钥管理一切。

背景：自托管对普通人太难，而运维劳动力已经变了

想在个人服务器上跑几个自己的应用，今天要么把整套运维学一遍，从容器、数据库到反向代理和网络运维；要么把数据交给别人的 PaaS。AI 编程代理则已经能干大部分部署与运维的活，缺的只是一个受控的入口：一个端点、一把密钥和一个明确的边界。

OpenIWeb 用同一套架构回答这两件事。应用代码可能来自网络复制或 AI 生成，所以默认不可信；每个应用与节点控制面之间、与其他应用之间默认隔离，没有开关。

单端口 Rust 内核：一台安装，一个入口

整个节点对公网只开一个端口：kernel-rs（约 4MB 的静态二进制）监听 :8080，承担 Host 路由、owner-key 鉴权与节点恢复，并为每个应用代理流量（带 WebSocket 升级隧道），是全节点唯一发布的端口。其余一切（RustFS、控制 API 与每个 celld 的监听）全部留在容器内回环，绝不发布：

公网
  |
iweb-kernel :8080           唯一发布端口（单个 Rust 静态二进制）
  +-- api.<base>                  -> Kernel 控制 API（与回环监听同鉴权）
  +-- admin.<base>                -> 独立 celld :8787（管理控制台）
  +-- mcp.<base>/mcp              -> 独立 celld :8797（MCP 端点）
  +-- <app>.<base>                -> 各应用独立 celld（IWEB_CELLD_PORTS）
  +-- <base>/<app>/app            -> 同一应用的路径别名
                                      |
                    RustFS（S3 兼容，仅回环，不开 console）
                                      |
                  iweb-workspace / iweb-cells-<app> / iweb-apps / iweb-system

TLS 在节点前置层终止（1Panel、Caddy 或 nginx），内核只按 HTTP Host 头路由。整节点闲时内存不超过 240 MB（RssAnon 口径），这条上限写在规格里（openspec/specs/node-boundary/）。

示例：验证唯一发布端口 
curl -H "Host: $IWEB_BASE_HOST" http://127.0.0.1:9010/_iweb/health

9010 是宿主机上任意的映射端口；容器内对外的只有内核的 8080。

MCP 运维面：每个请求都要带密钥

给 AI 代理的运维入口就是一个 MCP 端点：mcp.<base>/mcp 是一个受保护的系统应用，每个 JSON-RPC 请求（包括 initialize 和 tools/list）都必须携带 owner key 作为 Bearer token。工具覆盖 workspace 读写删除与域名列出/注册；worker 逐请求转发凭据、永不存储。AI 代理的接入就是一段标准的 MCP 配置：

{ "mcpServers": { "OpenIWeb": { "url": "https://mcp.<base>/mcp",
  "headers": { "Authorization": "Bearer <owner-key>" } } } }

两层信任运行时：不可信代码只能进 Wasmtime 沙箱

应用分两层，对应两种信任：可信应用独享进程，不可信代码没有 socket 能力。

  • 信任层 celld v0.3（Cloudflare Workers API）：应用只能随你构建的节点镜像进入，每应用独立进程，看门狗只设软限。控制台与演示应用属于这一层。

  • 不可信层 iweb-wasmd（Wasmtime，wasi:http 0.2 组件）是新代码进节点的唯一路径：引擎内强制隔离，只有宿主服务，没有 socket 能力。从网上抄来的或 AI 生成的应用，从这里进入。

对象存储内置 RustFS（S3 兼容，源自 MinIO，单节点友好，仅回环不开 console），四个桶各有分工：iweb-workspace · iweb-cells-<app> · iweb-apps · iweb-system。

示例：信任层的演示应用域名

hello.<base>（纯静态）· search.<base>（D1/SQLite 搜索）· collab.<base> / collab-b.<base>（跨实例实时协作）；浏览器打开即验。

可吊销的 owner 密钥：一个身份，多把密钥

交给 AI 代理的每一把密钥都随时可以收回。委托密钥（iwb_<id>_<secret>，GitHub PAT 的模型）带绝对过期；控制台可一键复制一段开箱即用的中文部署提示词（含 MCP 端点与密钥）直接交给 AI 代理；吊销即时生效（在途监控 socket 关闭、新请求 401）；append-only 的审计流按密钥归因记录每一次控制面操作，被拒绝的尝试也在内。

bootstrap IWEB_API_TOKEN 永远有效、不可吊销：它是通过 api.<base> 直接恢复节点的凭据。即使每把委托密钥连同 Admin 应用全部沦陷，owner 仍然可以直接触达 Kernel 控制 API。

示例：MCP 端点认的就是这把密钥 
curl -H "Authorization: Bearer <owner-key>" https://mcp.<base>/mcp

bootstrap 与委托密钥均可；不带密钥的请求会被拒绝。

其余变更与已知限制

  • 静态控制台：SvelteKit + shadcn-svelte 静态应用，以 celld 原生资产服务；它本身是一个普通应用，可整体替换，永远不是密钥配置界面

  • 三个演示应用：hello（celld assets 纯静态）、search（D1/SQLite 参数化 SQL 搜索）、collab（两个 celld 实例共享一个 Durable Object，跨实例 WebSocket 实时协作）；域名见上节示例

  • 测试规模：bun 全量 489 测 + Rust 侧（cargo test / clippy）+ kernel-recovery 黑盒契约套件

已知限制：TLS/通配符证书是部署侧的事（内核在容器内做 HTTP Host 路由）；监控指标随 Kernel 生命周期、非持久历史；notes 已部署但未路由；wasm 发布保持 fail-closed（celld 侧发布尚不存在，只有镜像供应）。

安装

本版以源码构建容器镜像分发（未发布 registry 镜像）。从 tag 构建：

git clone https://github.com/jixoai/openiweb.git && cd openiweb
git checkout v0.1.0
cp .env.example .env   # 设置 CELLD_NODE、IWEB_BASE_HOST、足够长的随机 IWEB_API_TOKEN、S3 凭据
docker compose up -d --build
curl -H "Host: $IWEB_BASE_HOST" http://127.0.0.1:9010/_iweb/health

多架构：Dockerfile（arm64）与 Dockerfile.amd64（x86_64；受限主机可用 CARGO_BUILD_JOBS 与 CRATES_MIRROR=rsproxy 构建旋钮）。节点数据落在 iweb-data 卷与 RustFS 桶里，配置落在 .env 里，所以重建容器不丢状态；owner 密钥由 Kernel/控制台签发、控制台可吊销，密钥永不落 workspace。

致谢

信任层站在 celld（DenoLand）之上；RustFS 源自 MinIO；不可信层的隔离由 Wasmtime 提供。

链接

jixoai logo jixoai jixoai.com