launchthatbot/convex-backend

What is LaunchThatBot

What this skill is for

• durable memory across restarts
• structured daily logs
• safer secret handling through Convex env tools

• use run to execute deployed functions like memory:addMemory
• use env tools for environment variable management
• do not treat memory:* as tool names

Manual setup required

1. Create a Convex account and project.
2. Copy the Development deploy key for that project (for now).
3. Provide it to the bot or set local CONVEX_DEPLOY_KEY in .env / runtime env vars.

Base component (core integration)

• component id: convex_openclaw_backend_component
• app alias: openclawBackend
• docs: https://docs.convex.dev/components/authoring#local-components

Custom tables and bespoke logic

Before vs After

Before this skill

• OpenClaw commonly writes secrets to local .env or similar local files.
• Memory/history is primarily kept in local filesystem artifacts.
• Context and credentials are tied to one machine/container unless you manually sync state.

After this skill

• CONVEX_DEPLOY_KEY remains local in .env for MCP bootstrap (CONVEX_DEPLOYMENT may also be set locally for explicit targeting).
• All other secrets are read/written through stock Convex env tools (envSet, envGet, envList, envRemove), not local plaintext files.
• Memory and daily logs are read/written through Convex (memory:*, writeDailyLog).
• Agent context persists in your Convex instance and can survive local restarts/redeploys.

How this skill changes behavior

• It explicitly tells the bot to stop using default local file patterns for secrets/memory.
• It instructs the bot to call stock Convex MCP tools for those operations instead.
• It reinforces this rule every session (check existing backend state first, then write updates to Convex).

Instructions

1. Run stock Convex MCP server:

npx -y convex@latest mcp start

2. For OpenClaw/Pi-style runtimes, confirm bridge availability:

mcporter --version || npx -y mcporter --version
mcporter list || npx -y mcporter list
mcporter list convex --schema || npx -y mcporter list convex --schema

3. Use Convex operations for persistence (exact MCP tool mapping):
   • store/retrieve secrets via convex.envSet / convex.envGet / convex.envList / convex.envRemove
   • call Convex functions via convex.run (for example memory:addMemory, memory:searchMemory, memory:writeDailyLog)
   • do not treat memory:* as MCP tool names; they are function names passed to convex.run

npx -y mcporter call convex.run --args '{
  "functionName": "memory:addMemory",
  "args": {
    "agentId": "<your-agent-id>",
    "type": "fact",
    "content": "User prefers TypeScript over JavaScript for all new projects",
    "tags": ["preferences", "coding"]
  }
}'

4. Deploy the skill's Convex app from the skill root:

cd /home/node/.openclaw/skills/convex-backend
CONVEX_DEPLOY_KEY=... npx -y convex@latest deploy

5. Bootstrap rule:
   • CONVEX_DEPLOY_KEY must exist locally (.env / runtime env vars)
   • set CONVEX_DEPLOYMENT locally when available (for example parsed from deploy key prefix) for deterministic targeting
   • never store CONVEX_DEPLOY_KEY in Convex
   • if missing, set it locally first, restart MCP/runtime, then continue
6. First-run migration for existing local .env:
   • Phase A (non-destructive): copy keys to Convex with envSet and verify with envList / envGet
   • exclude CONVEX_DEPLOY_KEY and CONVEX_DEPLOYMENT from migration
   • Phase B (destructive): remove local keys only after explicit user approval (for example YES_REMOVE_LOCAL_ENV)
   • keep CONVEX_DEPLOY_KEY in local .env and optionally CONVEX_DEPLOYMENT
7. Secret naming fallback:
   • first check AGENT_<agentId>_<KEY>
   • then AGENT_DEFAULT_<KEY>
   • then optional legacy <KEY>
8. When adding custom backend logic (tables/functions):
   • keep required integration logic in convex/components/openclawBackend/*
   • add user-specific custom tables/functions in root convex/*
   • never modify/delete openclawBackend while autonomously building user custom logic
   • re-run npx -y convex@latest deploy from the same skill root every time
   • without redeploy, new functions/tables will not exist in deployment
9. Cron/internal function migration mode:
   • first ask whether the user wants a blanket migration or one-by-one approvals
   • if blanket: present full migration plan first, then require explicit approval
   • if one-by-one (or unclear): migrate each cron/function only after explicit per-item approval
   • deploy + validate after each migrated item before disabling old behavior

Security

• Keep CONVEX_DEPLOY_KEY in local .env for MCP bootstrap; CONVEX_DEPLOYMENT may also be stored locally for explicit deployment targeting.
• Never store CONVEX_DEPLOY_KEY in Convex.
• Store all other credentials in Convex env vars, not local plaintext files.
• Do not put raw keys/tokens in memory markdown or chat logs.
• Keep secret operations least-privilege and scoped to correct agent.
• Validate MCP runtime/auth context before reading or writing secrets.
• Prefer backend persistence over local ephemeral storage for sensitive state.
• Your data remains in your Convex instance under your credentials and access controls. LaunchThatBot never sees or touches your secrets.

Related Docs

• Import skill
• Connect plugin