Skip to content
nacre.sh
— Your bot

LLM providers

Nacre is BYOK — bring your own key. You keep the billing relationship with the model provider; we keep out of it.

Why BYOK

Reselling inference sounds nice but cripples two things: pricing transparency and model choice. When you bring your own key:

  • You see the real cost per token, straight from the provider.
  • You pick the exact model — no "sorry, that SKU isn't available on our platform".
  • Switching providers is a single env-var change, not a contract renegotiation.
  • Your provider-side rate limits and usage caps follow you, not our whole fleet.

Supported providers

Nacre runs OpenClaw, which speaks to every provider OpenClaw supports — 290+ at time of writing. The common ones:

ProviderWhere you get a keyTypical env var
OpenAIplatform.openai.com/api-keysOPENAI_API_KEY
Anthropicconsole.anthropic.com/settings/keysANTHROPIC_API_KEY
Google (Gemini)aistudio.google.com/app/apikeyGOOGLE_API_KEY
OpenRouteropenrouter.ai/keysOPENROUTER_API_KEY
Groqconsole.groq.com/keysGROQ_API_KEY
Ollama (self-hosted)your own hostOLLAMA_BASE_URL

The full list lives in the OpenClaw docs. Any provider listed there works on Nacre.

Two ways to store your key

You choose — this is a security trade-off we think you should make, not us.

Option A — server-side (encrypted)

Paste the key into the LLM wizard in your dashboard. We encrypt it with pgsodium (libsodium) before it ever hits disk. The decryption key lives in Supabase Vault, not in our application code. On each provisioning or rotation, the provisioner injects it into your VM via the cloud-init env file.

Pros: survives VM rebuilds, restores from backup automatically, works across resizes.
Cons: we technically hold the ciphertext. If you're under regulated data handling rules, pick Option B.

Option B — terminal-injected

Open the web terminal, edit /etc/openclaw/env directly, and restart the OpenClaw container with docker compose restart openclaw. The key only ever touches your VM's disk, never our database.

Pros: we have zero knowledge of the key.
Cons: on a VM rebuild (rare but possible after DR), you re-inject. Keep a note.

Runaway keys are your bill
Because you own the provider relationship, a looping agent or a tokenized-recursion bug is billed to you, not us. Most providers support spend limits — set one, at least until you trust your skills and memory. OpenAI: Usage Limits. Anthropic: Billing → Monthly Budget. OpenRouter: Settings → Credits cap.

Switching providers

OpenClaw reads the key env vars on startup. To switch:

  1. Paste the new key into the wizard (or update /etc/openclaw/env).
  2. OpenClaw reloads on the next message, or you can docker compose restart openclaw from the terminal.

If you want failover (e.g., OpenAI primary, Anthropic fallback), OpenClaw supports provider chains in its config — see the OpenClaw upstream docs.

Key rotation

Rotating a key is a two-minute job:

  1. Generate a new key with your provider.
  2. Paste it into the wizard (Option A) or update the env file (Option B).
  3. Restart the OpenClaw container.
  4. Delete the old key from your provider's dashboard.

Do this quarterly at minimum. If you suspect a leak, do it now — then email security@nacre.sh so we can check for unusual activity on the VM.

What we can and can't see

Your key (server-side)
Ciphertext only; pgsodium-encrypted at rest.
Your key (terminal)
We cannot see it. It is on your VM only.
Model responses
On your VM only. Never streamed to us.
Token counts
We see aggregate disk and RAM — not token usage. Use your provider dashboard.
Your prompts
On your VM only.