Migrating from TypeScript OpenClaw to Rust

The compatibility surface is the migration path. openclaw-rs was designed so that “switching runtime” is not a project — it’s a config swap, plus optional cleanup.

Step 0: Audit what you actually use

Run through your current TypeScript OpenClaw deployment:

• Which providers are you using? (Anthropic? OpenAI? Google? Ollama?)
• Which channels are active? (Telegram? Slack? Discord?)
• Which plugins are loaded? (List them by name.)
• What’s in your skills directory?
• What’s in your openclaw.json?

Write these down. The migration plan falls out of the answers.

Step 1: Install the Rust CLI alongside

cargo install openclaw-cli
openclaw --version

This doesn’t touch your existing TS deployment. The Rust CLI uses the same ~/.openclaw/ workspace by default, but you can point it elsewhere with --workspace.

Step 2: Validate the config

openclaw config validate ~/.openclaw/openclaw.json

openclaw-rs reads the same JSON5 schema. If you used providers that don’t ship in v0.1.0 yet (Google, Ollama), the validator will tell you. Comment those out for now; they’re roadmap items.

Step 3: Plan provider coverage

Today’s stable providers in openclaw-rs:

Provider	Status	Notes
Anthropic	shipped	Claude 3.5 Sonnet, Haiku, Opus. SSE streaming, tool use.
OpenAI	shipped	GPT-4o, GPT-4, GPT-3.5. SSE streaming, function calling. Azure base URL supported.
Google Gemini	planned	Roadmap.
Ollama	planned	Roadmap.

If your TS deployment uses Anthropic + OpenAI, you’re done here. If you depend on Google or Ollama, either stay on TS for those agents or wait for the planned provider.

Step 4: Plug in your TypeScript plugins

This is the moment of truth. Move your plugins as-is:

~/.openclaw/plugins/
  ├── my-team-plugin/
  │   ├── package.json
  │   └── index.ts
  └── another-plugin/
      ├── package.json
      └── index.ts

openclaw-plugins discovers them by scanning for package.json markers. It launches each plugin as a Node subprocess, opens an nng IPC channel, and dispatches the 8 lifecycle hooks over JSON-RPC.

The hooks are identical to TS OpenClaw:

export default {
  async BeforeToolCall(ctx, params) {
    // your existing code, unchanged
  },
  async AfterToolCall(ctx, result) {
    // your existing code, unchanged
  },
};

You haven’t deleted anything yet.

Step 5: Plan channel coverage

Today’s stable channels in openclaw-rs:

• Telegram — full Bot API adapter with attachments, allowlisting, routing rules.

Roadmap: Discord, Slack, Signal, Matrix, WhatsApp. If your TS deployment uses Slack today, that adapter has to keep running in TS while you migrate.

The Channel traits in openclaw-channels are stable, so writing the Slack adapter in Rust is a single-file PR if you’re motivated. We’d merge it.

Step 6: Run the Rust gateway

openclaw gateway run --port 18790    # different port from your TS gateway
openclaw doctor                       # confirm sled, credential store, sandbox

Point a test session at the Rust gateway. Verify your existing plugins fire. Verify event history reads correctly. The event format on disk is wire-compatible with TS OpenClaw.

Step 7: Cut over

Once your test traffic looks identical:

1. Stop the TS gateway.
2. Switch the Rust gateway to the production port.
3. Migrate channel adapters one-by-one (Telegram first, since it’s covered).

If something breaks, the TS gateway is still installed. You can flip back in seconds.

Step 8: Optional — delete the Node dependency

After a week of stable Rust operation, you can:

• Uninstall the Node OpenClaw package.
• Delete node_modules/ from your deployment image.
• Trim ~100 MB off your container.

Or keep TS around if you have plugins that genuinely need it. The plugin bridge means it’s not all-or-nothing.

What you don’t migrate

• Skill files (Markdown + YAML frontmatter). Same format. Same loader.
• Event format. openclaw-rs reads the existing append-only log.
• Plugin code. The nng bridge handles it.
• Config. Same JSON5 schema.
• Workspace layout. ~/.openclaw/ stays the same.

What you might actually rewrite

• Custom channel adapters if you wrote any in TS. Port them to the Rust Channel trait.
• Custom tools if you wrote them as Node modules rather than as plugins. Port them to a Rust Tool impl or run them as a TS plugin.
• CI scripts that assume node_modules. Cleanup, not blocker.

When not to migrate yet

• You depend on Google Gemini or Ollama → wait for the planned providers.
• You depend on Discord/Slack/Signal/Matrix/WhatsApp natively → stay on TS or write the adapter yourself.
• You’re prototyping → stay on TS for the dev velocity.

For everyone else: the runtime is a cargo install away.