Skip to content

OpenIWeb v0.1.0：降低自托管门槛，简化节点管理

jixoai v0.1.0 openiweb

第一个公开版本。自托管不再要求容器与运维知识：把 MCP 端点和一把密钥交给 AI 编程代理，应用就部署在你自己的节点上；公网只开一个端口，不可信代码只进沙箱，交给代理的每一把密钥都可即时收回。整节点闲时内存 ≤ 240 MB。

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

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

在此之前，想在个人服务器上跑几个自己的应用只有两条路：把容器、数据库到反向代理的整套运维学一遍，或者把数据交给别人的 PaaS。AI 编程代理已经能干其中大部分活，缺的是一个受控入口：一个端点、一把密钥和一条明确的边界。OpenIWeb 就是照这个入口设计的节点；仓库 2026-08-11 才落下第一个提交，到本版 tag 不到一个月。

对公网只开一个端口

在一台自己维护的服务器上，数据库、管理面板和对象存储各自监听，每一处都是要单独守的暴露面。OpenIWeb 把整个节点收到一个端口后面：kernel-rs（约 4MB 的 Rust 静态二进制）监听 :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/）。

口径：240 MB 是怎么量的

节点空闲（无在途请求）、完成至少一轮存储租约续期后，逐进程采样 RssAnon 求和；可回收的文件页缓存（RssFile）不计入。规格记录的实测：lima 159 MB、云主机 162.3 MB 与 iMac 231.3 MB。

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

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

运维收进一个 MCP 端点

给 AI 代理的运维入口就这一个端点。mcp.<base>/mcp 是一个受保护的系统应用，每个 JSON-RPC 请求（包括 initialize 和 tools/list）都必须携带 owner 密钥作为 Bearer token；Worker 逐请求转发凭据，绝不存储。接入是一段标准的 MCP 配置。

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

0.1.0 的工具面共 19 个，覆盖三组能力：应用生命周期（admit, prepare, readiness, activate, start, stop, rollback, versions 等）、工作区读写删，以及域名列出与注册。部署、验证、回滚与清理都在同一把密钥的授权下完成。

清单：19 个 MCP 工具全名 
应用生命周期    iweb_application_list      iweb_application_start
                iweb_application_admit     iweb_application_stop
                iweb_application_prepare   iweb_application_rollback
                iweb_application_readiness iweb_application_delete_version
                iweb_application_activate  iweb_application_inspect
                                           iweb_application_versions
                                           iweb_application_delete_data
                                           iweb_application_metrics
工作区          iweb_workspace_list        iweb_workspace_read_text
                iweb_workspace_write_text  iweb_workspace_delete
域名            iweb_domain_list           iweb_domain_register

不可信的代码只进沙箱

应用代码可能来自网络复制或 AI 生成，所以一律默认不可信；每个应用与节点控制面之间、与其他应用之间默认隔离，没有开关。运行时按信任分两层。

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

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

对象存储是内置的 RustFS（S3 兼容，源自 MinIO，单节点友好），仅回环监听、不开 console。

落点：四个存储桶

RustFS 里的四个桶各有分工：iweb-workspace, iweb-cells-<app>, iweb-apps, iweb-system。

交给代理的密钥随时能收回

密钥走 GitHub PAT 的模型：一个身份，多把可吊销令牌。控制台签发 iwb_<id>_<secret> 格式的委托密钥，可设绝对过期（1/7/30 天或永久）；「一键复制部署提示词」会把 MCP 端点与密钥模板化成一段可直接粘贴的中文指令，粘给任何 AI 代理即可。

吊销即时生效：票据失效、监控 WebSocket 主动关闭、后续请求 401。审计流 append-only 且按密钥归因：每次控制面操作都有记录，被拒绝的 401 尝试也在内；4 MiB 封顶轮转。

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 黑盒契约套件。

示例：演示应用域名与验证方法

hello.<base>（纯静态）、search.<base>（D1/SQLite 搜索）、collab.<base> 与 collab-b.<base>（跨实例实时协作）。在 collab 的两个域名各开一个浏览器窗口，一边发消息另一边实时跳动。

已知限制：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