Migration
OpenClaw gave you automation.
0trace gives you accountability.
Your scripts don't change. Your security posture does. Full feature parity plus a capability enforcement model OpenClaw was never designed for.
Why migrate
What changes. What stays. What you never worry about again.
A side-by-side look at what OpenClaw gives you and what 0trace adds on top.
| OpenClaw | 0trace | |
|---|---|---|
| Skill format | Visual node graph | Plain Markdown + YAML |
| Capability model | Trust all / ambient authority | Declare-first, deny by default |
| Audit trail | Log aggregation (optional) | SHA-256 hash-chained, built-in |
| Skill signing | None | Ed25519, verified before execution |
| Self-hosted | Yes (Node.js + PostgreSQL) | Yes (single Zig binary + SQLite) |
| Runtime deps | Node.js, npm, external DB | Zero — single binary |
| Version control | Export/import JSON | Git-native (plain text files) |
| Memory footprint | ~512 MB typical | 64 MB default cap |
Why migrate before something goes wrong?
An OpenClaw skill runs with whatever authority is present in its environment.
That works fine — until it doesn't. A skill tampered with between commit and execution. An agent writing to a path you didn't intend. An auditor asking you to prove what your agents did on a specific date.
0trace's execution model makes these scenarios structurally impossible or immediately verifiable. You don't have to wait for an incident to justify the migration.
No signature check → runs anyway
No capability enforcement → no alert
No hash chain → no provable answer
Before you ever need to explain them
Concept mapping
Everything has an equivalent
The concepts translate directly — the format is just more secure.
| OpenClaw | 0trace | Notes |
|---|---|---|
| Flow / Workflow | Skill (.md file) | 0trace skills are version-controlled plain text |
| Node / Step | Step in skill frontmatter | Declarative, not visual drag-and-drop |
| Trigger | Scheduler / API call / CLI | zt run skill.md or HTTP POST /api/run |
| Credential / Secret | secrets.read:SECRET_NAME | Referenced by name, never embedded |
| Team / Workspace | Org | Managed via dashboard or API |
| Execution History | Run + Audit Log | SHA-256 chained, tamper-evident |
| Plugin | Capability declaration | Explicit resource access replaces opaque plugins |
| Node editor | Code editor (any) | Skills are text files — edit anywhere |
Step by step
Seven steps. Run 0trace alongside OpenClaw — no cutover required.
Audit your OpenClaw flows
Export all flows from OpenClaw. List every credential, every external service, every file path your flows touch. This becomes your capability list in 0trace.
Install 0trace
# Docker
docker pull 0trace/runtime:latest
docker run -p 8080:8080 0trace/runtime zt serve
# Or download the binary
curl -L https://github.com/0trace-ai/zt/releases/latest/download/zt-linux-amd64 -o zt
chmod +x zt && ./zt --version Convert your flows to skills
Each OpenClaw flow becomes a .md file. Before and after:
Before (OpenClaw)
// OpenClaw flow (simplified JSON)
{
"name": "Backup Database",
"trigger": { "type": "cron", "schedule": "0 2 * * *" },
"nodes": [
{ "type": "credential", "id": "db-cred" },
{ "type": "execute", "cmd": "pg_dump", "credential": "db-cred" },
{ "type": "write", "dest": "/var/backups" }
]
} After (0trace)
# Backup Database
capabilities:
- fs.write:/var/backups
- secrets.read:DB_PASSWORD
- process.exec:pg_dump
steps:
- run: pg_dump -U admin {{secrets.DB_PASSWORD}} mydb > /var/backups/dump.sql Declare capabilities
For each external resource your skill needs, add a capability declaration. Start restrictive — run the skill and see what gets blocked, then add only what's needed.
Sign your skills
Generate a keypair and sign your skill bundles before running in production.
zt sign backup-database.md --key=~/.zt/signing-key.pem Run and verify
Execute the skill. Check the audit log. Verify the hash chain.
zt run backup-database.md
zt audit --skill=backup-database --verify Migrate your team
Create an org, invite team members, migrate your credential store. When all skills are validated, decommission OpenClaw.
Parity
Everything OpenClaw does. Plus a security model it was never designed for.
Your workflows stay. Your scripts stay. Your accountability posture gets an upgrade.
FAQ
Common questions
Do my existing OpenClaw flows work as-is?
Not directly — OpenClaw uses a node graph format; 0trace uses Markdown skills. But the migration is straightforward: each node/step maps to a step declaration, and each credential maps to a capability. The guide above covers the full conversion.
Do I need to rewrite my scripts?
No. Your shell scripts, Python scripts, and API calls stay the same. Only the wrapper format changes from OpenClaw's JSON graph to a 0trace Markdown skill.
Can I run 0trace and OpenClaw in parallel during migration?
0trace is a completely separate binary with no dependencies on OpenClaw. Run both simultaneously, migrate flows one at a time, then decommission OpenClaw when done.
What about my OpenClaw plugins?
0trace's capability model replaces plugins. Instead of installing a plugin to access Stripe, you declare network.fetch:api.stripe.com. The difference: 0trace's model is explicit and auditable by default.
Is there a migration tool?
Not yet. We're building a CLI converter (zt migrate --from=openclaw flow.json). Follow the GitHub repo for updates.
Start with one skill. Migrate the rest when you're ready.
The runtime runs alongside OpenClaw — no cutover required.