OpenClaw Local vs Cloud Memory Setup with Hindsight

If you are deciding between OpenClaw local vs cloud memory setup with Hindsight, the real question is not just where memory runs. It is what kind of operational tradeoff you want. Local mode gives you a self-contained memory stack on the same machine as OpenClaw. Cloud mode gives you a managed Hindsight endpoint that OpenClaw talks to over the network. Both give you automatic retention and automatic recall. The difference is where the infrastructure lives, how credentials are managed, and how easy it is to share memory across machines.

This decision matters because it changes more than deployment. It affects startup behavior, reliability patterns, privacy boundaries, and whether one OpenClaw instance can share memory with another. A solo user on one laptop may prefer local mode because it is simple and keeps everything on device. A team running multiple OpenClaw gateways will usually prefer cloud mode because shared memory becomes straightforward.

This comparison walks through what each mode does, how the setup differs, when local mode wins, when cloud mode wins, and how to switch later if your needs change. Keep the OpenClaw integration docs, the docs home, and the quickstart guide open if you want the full reference while you compare.

Verdict

Use local if you want one-machine memory, minimal external dependencies, and strong local control. Use cloud if you want the fastest setup, simpler multi-instance sharing, and less infrastructure work. If you are unsure, start with cloud for team or multi-device use, and start with local for a single personal deployment.

What each setup does

At a high level, both modes give OpenClaw the same product behavior:

• conversations are retained automatically after each turn
• relevant memories are recalled automatically before each response
• the agent gets context without explicitly calling a memory tool

What changes is where Hindsight lives.

Local mode

In local mode, the plugin runs an embedded Hindsight service through hindsight-embed. That means the memory API and its PostgreSQL storage live on the same machine as OpenClaw.

You configure an extraction model for Hindsight, start OpenClaw, and the local daemon handles memory operations nearby.

A typical embedded setup command looks like this:

npx --package @vectorize-io/hindsight-openclaw hindsight-openclaw-setup \
    --mode embedded --provider openai --api-key-env OPENAI_API_KEY

This is a strong fit when the machine running OpenClaw is also the machine that should store and process memory.

Cloud mode

In cloud mode, OpenClaw talks to a managed Hindsight endpoint at https://api.hindsight.vectorize.io using an API token. The local gateway no longer needs to host the memory service itself.

A typical cloud setup command looks like this:

npx --package @vectorize-io/hindsight-openclaw hindsight-openclaw-setup \
    --mode cloud --token-env HINDSIGHT_CLOUD_TOKEN

This is the fastest way to get working memory across one or more OpenClaw instances without managing the Hindsight server locally.

Side by side comparison

Dimension	Local mode	Cloud mode
Setup path	embedded daemon on the OpenClaw machine	managed Hindsight endpoint with API token
Infra you manage	OpenClaw plus local Hindsight runtime	OpenClaw only
Data locality	memory service stays on the machine	memory service runs remotely
Shared memory across devices	awkward by default	easy
Startup behavior	may need daemon startup on first use	no local memory daemon startup
Best for	one machine, local-first preference	teams, multi-instance, fastest time to value
Key credentials	LLM provider key for extraction	Hindsight cloud token
Failure pattern	local daemon or local config issues	network or remote endpoint issues

That table gets you most of the way there, but the practical differences are easier to see in concrete workflows.

When to use local mode

Local mode is the better choice when control and locality matter more than centralization.

Choose local mode if:

• you run one OpenClaw instance on one machine
• you want the memory service to stay on that same machine
• you are comfortable giving Hindsight an extraction-model credential locally
• you do not need multiple OpenClaw instances to share a common bank right away

A local deployment feels clean because OpenClaw and Hindsight live together. There is no separate memory server to think about. For a personal assistant setup, that is attractive.

It is also nice for iterative experimentation. You can change plugin settings, restart the gateway, inspect logs, and keep the entire memory stack close to hand.

The tradeoff is that the memory service is no longer something you can naturally share across devices. If you later want your laptop OpenClaw and your server OpenClaw to share one memory bank, local mode stops feeling like the obvious answer.

Local mode example

A direct openclaw.json style example for embedded mode looks like this:

{
  "plugins": {
    "entries": {
      "hindsight-openclaw": {
        "enabled": true,
        "config": {
          "llmProvider": "openai",
          "llmApiKey": {
            "$ref": {
              "source": "env",
              "provider": "default",
              "id": "OPENAI_API_KEY"
            }
          },
          "apiPort": 9077,
          "daemonIdleTimeout": 0
        }
      }
    }
  }
}

The details can vary, but the important part is that OpenClaw is hosting the Hindsight path locally rather than calling a remote Hindsight API.

When to use cloud mode

Cloud mode is the better choice when you want less infrastructure work and more operational flexibility.

Choose cloud mode if:

• you want the fastest path from zero to working memory
• you are running more than one OpenClaw instance
• you want a shared bank across machines
• you do not want to manage an embedded memory service locally

The big win is simplicity at scale. A second OpenClaw instance can point at the same Hindsight backend without you having to expose or synchronize a local embedded daemon.

This is why cloud mode pairs naturally with shared-memory setups. If you want one user's context or one team's context to follow them across instances, cloud mode removes the biggest operational obstacle.

The tradeoff is obvious: your memory backend is now remote. That is often worth it, but it is still a real boundary change.

Cloud mode example

A direct cloud configuration looks like this:

{
  "plugins": {
    "entries": {
      "hindsight-openclaw": {
        "enabled": true,
        "config": {
          "hindsightApiUrl": "https://api.hindsight.vectorize.io",
          "hindsightApiToken": {
            "$ref": {
              "source": "env",
              "provider": "default",
              "id": "HINDSIGHT_CLOUD_TOKEN"
            }
          }
        }
      }
    }
  }
}

If you want a more locked-down production setup, use a SecretRef from env, file, or exec rather than writing secrets inline. The OpenClaw integration docs cover those patterns in more detail.

How setup and operations feel different

Startup and reliability

In local mode, a fresh machine may need time for the embedded memory runtime to start. That can make the very first memory-enabled interactions feel slower or more fragile if you are watching logs closely.

In cloud mode, the main operational dependency shifts to network reachability and API health. You avoid local daemon startup, but you now depend on the remote endpoint being reachable.

Credentials

In local mode, the main sensitive value is usually the extraction-model credential, for example OPENAI_API_KEY or another provider key.

In cloud mode, the critical credential is the Hindsight cloud token. You can still use SecretRef patterns either way, and you should for anything non-trivial.

Shared memory

This is where cloud mode usually wins decisively. If you want multiple OpenClaw instances to learn into the same bank, cloud mode is much simpler to reason about. The existing shared-memory OpenClaw pattern depends on a common external endpoint. That is why cloud mode pairs naturally with multi-instance memory.

If that is your main goal, also read the OpenClaw integration docs, the team shared memory post, and Adding memory to Codex with Hindsight. They make the multi-agent and multi-tool story clearer.

When local is better than cloud

Local mode is better when:

• you care most about keeping the memory service close to the gateway machine
• you are a single-user deployment
• you want fewer external moving parts during day-to-day use
• you are comfortable managing the local extraction-model credential yourself

In other words, local mode wins when the deployment is small and the control you gain is worth the operational responsibility.

When cloud is better than local

Cloud mode is better when:

• you want to get from setup to useful memory fast
• you expect more than one OpenClaw instance
• you want shared memory across machines
• you want to avoid running or diagnosing a local memory service

Cloud also tends to be the easier recommendation for teams, because the moment multiple gateways need the same memory, the local-first advantage gets weaker.

Migration notes

The nice part is that this choice is not permanent.

Moving from local to cloud

The cleanest path is usually just rerunning the setup wizard in cloud mode:

npx --package @vectorize-io/hindsight-openclaw hindsight-openclaw-setup \
    --mode cloud --token-env HINDSIGHT_CLOUD_TOKEN
openclaw gateway restart

Then verify the updated config and test a real memory-enabled conversation.

Moving from cloud to local

Likewise, rerun the wizard in embedded mode:

npx --package @vectorize-io/hindsight-openclaw hindsight-openclaw-setup \
    --mode embedded --provider openai --api-key-env OPENAI_API_KEY
openclaw gateway restart

The important thing in either direction is not to treat the switch like a purely cosmetic toggle. It changes the operational shape of the memory backend, and you should retest recall, retention, and bank behavior after the change.

Next steps

• Create a Hindsight Cloud account if you want the fastest path to shared OpenClaw memory across instances.
• Read the OpenClaw integration docs for the full plugin setup and config reference.
• Keep the quickstart guide handy if you want a smaller end-to-end Hindsight refresher.
• Use the Recall API reference to understand what each mode retrieves before it reaches OpenClaw.
• Use the Retain API reference if you want to reason about what actually becomes memory.
• Compare adjacent workflows like Adding memory to Codex with Hindsight and the team shared memory post if you are designing a broader multi-tool memory setup.