> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rkat.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Mobpack and Web Deployment

> Portable multi-agent deployment with signed .mobpack artifacts and browser-target web bundles.

`mobpack` is the portable artifact for mobs. You build it once, then deploy consistently in CLI, service, or browser workflows.

## What this guide is for

Use this guide when you want to:

* package a mob into a portable artifact
* sign and validate that artifact
* deploy it consistently across CLI, service, and browser targets

## What you get

* Single-file artifact: `.mobpack`
* Optional signing and trust verification
* Deterministic `inspect` and `validate` boundaries
* Direct deploy (`mob deploy`) and browser bundle target (`mob web build`)

## Directory to artifact

```bash theme={null}
rkat mob pack ./mobs/release-triage -o ./dist/release-triage.mobpack
rkat mob inspect ./dist/release-triage.mobpack
rkat mob validate ./dist/release-triage.mobpack
```

Expected source files:

* `manifest.toml`
* `definition.json`
* optional `skills/`, `hooks/`, `mcp/`, `config/defaults.toml`

## Signed packs and trust policy

Sign at pack time:

```bash theme={null}
rkat mob pack ./mobs/release-triage -o ./dist/release-triage.mobpack --sign ./keys/release.key
```

Deploy with strict trust:

```bash theme={null}
rkat mob deploy ./dist/release-triage.mobpack "triage release regressions" --trust-policy strict
```

Trust policy resolution:

1. CLI `--trust-policy`
2. `RKAT_TRUST_POLICY`
3. config `trust.policy`
4. default `permissive`

Strict mode rejects:

* unsigned packs
* unknown signers
* invalid signatures
* signer key mismatches

## Deploy modes

One-shot CLI run:

```bash theme={null}
rkat mob deploy ./dist/release-triage.mobpack "triage latest incidents"
```

RPC service deployment:

```bash theme={null}
rkat mob deploy ./dist/release-triage.mobpack "boot service" --surface rpc
```

## Browser target: `mob web build`

The web build compiles the **real meerkat agent stack** to wasm32 — same agent loop, same LLM providers (Anthropic, OpenAI, Gemini), same streaming as CLI/RPC/REST. Not a simulation.

Prerequisites:

```bash theme={null}
cargo install wasm-pack
export PATH="$HOME/.cargo/bin:$PATH"
```

Build:

```bash theme={null}
rkat mob web build ./dist/release-triage.mobpack -o ./dist/release-triage-web
```

Output includes:

* `runtime.js` — wasm-bindgen JS bindings
* `runtime_bg.wasm` — compiled meerkat agent stack (\~1.5MB)
* `mobpack.bin` — the packed mob artifact
* `manifest.web.toml` — derived web manifest

Environment overrides:

* `RKAT_WASM_PACK_BIN`: explicit wasm-pack binary
* `RKAT_WEB_RUNTIME_CRATE_DIR`: explicit runtime crate directory for build

### How the WASM runtime works

The runtime uses `tokio_with_wasm` as a drop-in tokio replacement (backed by the JS event loop), `reqwest` with browser `fetch` for HTTP, and `web-time` for browser-safe timestamps. The `#[async_trait(?Send)]` pattern handles wasm32's single-threaded model.

API:

```typescript theme={null}
import { MeerkatRuntime } from "@rkat/web";
import * as wasm from "@rkat/web/wasm/meerkat_web_runtime.js";

const runtime = await MeerkatRuntime.initFromMobpack(wasm, mobpackBytes, {
  anthropicApiKey: "sk-ant-...",
  model: "claude-sonnet-4-6",
});

const session = runtime.createSession({ model: "claude-sonnet-4-6" });
const result = await session.turn("Your prompt here");
const events = session.pollEvents();
```

### Browser capabilities and limitations

**Available:** agent loop (streaming, retries), all LLM providers, sessions, JSON schema validation, budget enforcement, events, skills, MCP config types, tool/compactor/memory traits.

**Not available (browser inherent):** filesystem config loading, stdio MCP servers, shell tool, file-based persistence. Use programmatic config and in-memory storage instead.

**Not yet available (upstream blocker):** MCP protocol client over HTTP — the `rmcp` crate depends on `tokio`/`mio` which don't compile on wasm32. MCP config types and tool definitions work; actual connections to MCP servers are blocked pending rmcp wasm32 support.

## Cool web patterns

### Incident war room

Build `ops-war-room.mobpack`, publish web bundle behind internal auth, and let responders open a zero-install multi-agent workspace in-browser.

### Embedded dashboard copilot

Bundle `dashboard-copilot.mobpack` and embed it in your observability or release dashboard to summarize anomalies and propose mitigation steps in context.

## Example library

See runnable examples:

* `examples/028-mobpack-release-triage-sh` for a signed release-triage mobpack that is packed, inspected, validated, and deployed end to end
* `examples/029-web-incident-war-room-sh` for a browser-deployable SEV war room with source-controlled mobpack inputs and kickoff prompts
* `examples/030-web-dashboard-copilot-sh` for an embeddable dashboard copilot that emits a web bundle plus sample host-integration assets

## See also

* [Examples: Mobpack](/examples/mobpack)
* [Examples: WASM](/examples/wasm)
* [Mobs guide](/guides/mobs)