Our OpenClaw backup looked fine right up until the config vanished

The scary part isn’t losing a prompt.

It’s restoring an agent and realizing your “backup” never included the model routing, secrets, connector auth, or API base URL that made the thing work in the first place.

I went down this rabbit hole after seeing this r/openclaw thread about an "Unknown Backup Error". What stuck with me wasn’t the error itself. It was the false sense of safety.

A lot of us see an export file and think: cool, we have a backup.

That is not the same as having a restore.

The trap: workflow JSON is not the system

On paper, this all looks responsible:

• OpenClaw workflow exported
• n8n flows synced to Git
• Make scenarios saved as blueprints

If you skimmed the repo, you’d probably say the stack was covered.

It wasn’t.

Because agents do not run on workflow shape alone. They run on hidden state:

• API keys
• OAuth connections
• environment variables
• provider selection
• model IDs
• fallback rules
• routing logic
• API base URLs

Lose any of those, and you may not get a clean failure.

You may get something worse: a restore that technically runs, but behaves differently.

The worst restore failures are the quiet ones

A hard failure is annoying, but at least it’s honest.

A silent behavior change is where teams lose days.

You restore the agent. The import succeeds. The UI looks normal. A test run passes.

But now:

• the Slack connection is disconnected
• the Postgres credential exists, but the secret value is blank
• the OPENAI_BASE_URL env var is missing
• the model alias points somewhere else
• the fallback path now routes to a different provider

Same workflow. Different system.

That means different output quality, different latency, different tool behavior, and usually different cost.

If you run agents in production, that should make you nervous.

What each tool actually gives you

Here’s the practical version.

| Tool | What gets backed up | What still breaks restore |
|----------|----------|
| OpenClaw export | Workflow structure and visible config | Provider/model state can drift or be missing |
| n8n Git sync | Workflows in source control | Credential values and variable values are not fully restored from Git alone |
| Make blueprints | Scenario structure for rebuilds | Account connections must be recreated, and imports are limited to 2 MB |

All three are useful.

None of them, by themselves, deserve to be called disaster recovery.

OpenClaw is especially risky if model/provider state matters

This is the part people underestimate.

A working OpenClaw agent might depend on:

• a specific provider
• a specific model alias
• a route for long-context tasks
• a cheaper route for classification
• a fallback for rate limits or failures

If you restore the visible logic but lose that model/provider layer, the agent may still run.

It just won’t be the same agent anymore.

That matters even more if you use an OpenAI-compatible endpoint instead of talking directly to one vendor.

For example, if your agent expects an OpenAI-compatible base URL from Standard Compute, you need to preserve that assumption during restore:

export OPENAI_BASE_URL="https://api.standardcompute.com/v1"
export OPENAI_API_KEY="sc_..."

If those values disappear and someone restores with a default OpenAI endpoint or swaps providers manually, the workflow may still execute while quality, latency, and cost all change underneath you.

That’s exactly the kind of mess teams hit when they don’t back up routing and endpoint config.

What a broken restore actually looks like

This is the common sequence:

1. Import JSON
2. Reconnect one service
3. Hit run
4. Get an auth error
5. Patch the credential
6. Hit run again
7. Notice the model setting changed
8. Patch that
9. Realize the fallback route points somewhere else
10. Declare victory because the workflow finally completed

At that point, the system “works.”

But it may not be the same system you had before.

That’s the key mistake: treating successful import as successful recovery.

What you need to back up besides the workflow

If the agent matters, the backup has to include more than JSON.

My checklist looks like this:

• workflow definitions
• environment variables
• non-secret config values
• secrets stored in a separate secret manager
• connector mappings
• account reconnection steps
• model IDs
• provider routing rules
• fallback behavior
• API base URLs
• notes about OpenAI-compatible assumptions
• proof that restore was actually tested

If that sounds like a lot, that’s because it is.

Agent systems have more hidden operational state than most teams admit.

A practical backup layout

If I were setting this up for a small team, I’d keep it boring and explicit.

1. Version the workflow artifacts

mkdir -p backup/workflows
cp openclaw-export.json backup/workflows/
cp n8n-flows.json backup/workflows/
cp make-blueprint.json backup/workflows/

2. Store non-secret runtime config separately

mkdir -p backup/config
cat > backup/config/runtime.env.example <<'EOF'
OPENAI_BASE_URL=https://api.standardcompute.com/v1
PRIMARY_MODEL=gpt-5.4
FALLBACK_MODEL=claude-opus-4.6
CLASSIFIER_MODEL=grok-4.20
SLACK_WORKSPACE=my-workspace
EOF

Do not put live secrets in Git.

Use a secret manager for those.

3. Export a machine-readable restore checklist

{
  "connectors": [
    "Slack",
    "Postgres",
    "Notion"
  ],
  "restore_order": [
    "Import workflow",
    "Restore environment variables",
    "Reconnect OAuth accounts",
    "Validate model routing",
    "Run smoke tests"
  ],
  "endpoint_expectation": {
    "api_style": "OpenAI-compatible",
    "base_url": "https://api.standardcompute.com/v1"
  }
}

4. Add a smoke test script

Even a dumb script is better than vibes.

#!/usr/bin/env bash
set -euo pipefail

curl -s "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq '.data[0].id'

Then test one real prompt path your agent depends on.

My opinionated rule: if you haven’t tested restore, you do not have a backup

This is the part where I stop being diplomatic.

If your plan is:

• export JSON
• commit it somewhere
• assume future-you will figure it out

that is not a backup strategy.

That is a hope file.

The only backup that counts is one you can restore into a working agent with:

• the same connectors
• the same provider behavior
• the same model routing
• the same endpoint assumptions
• the same operational output

Everything else is documentation.

Useful documentation, sure. But still documentation.

Why this matters more for teams running agents all day

If you have one toy workflow, manual exports are fine.

If the agent touches production, customers, or revenue, this gets serious fast.

And if you’re running lots of agent traffic through OpenAI-compatible clients, preserving endpoint behavior matters just as much as preserving the prompt.

That’s one reason predictable infrastructure matters here. Teams using Standard Compute are usually trying to avoid two things at once:

• surprise cost from per-token billing
• surprise behavior from ad hoc provider changes

You don’t want a restore to quietly swap both.

The takeaway

OpenClaw export alone is not a backup.

Make blueprints are not disaster recovery.

n8n Git sync is not complete without secret and variable recovery.

And if you do not preserve model/provider config, API base URLs, and routing behavior, you are not restoring the agent you think you are.

That’s the real failure mode.

Not missing JSON.

Missing the invisible state that made the agent reliable in the first place.