Bringing Your Existing OpenClaw Setup to LaunchThatBot

You have an OpenClaw agent running somewhere. Maybe it is on your desktop. Maybe it is on a Mac Mini in your closet. Maybe it is on a VPS you set up three months ago.

The agent works. It has a personality defined in a soul.md file. It has memory banks full of context it has accumulated over weeks of conversations. It has skills and MCP servers configured. It has environment variables with API keys for every service it connects to.

And now you want to move it to LaunchThatBot -- to get container isolation, a management dashboard, security hardening, and the operational layer that makes running agents sustainable at scale.

The question is: how do you get everything over without starting from scratch?

The problem with "just redeploy"

The naive path is to create a new deployment on LaunchThatBot and manually recreate your agent's configuration. Copy the soul.md. Re-enter the environment variables. Reconfigure the skills. Hope you did not forget anything.

This works for a fresh agent with no history. It does not work for an agent that has been running for weeks or months and has accumulated meaningful state:

• Memory banks contain context the agent has learned. Recreating this manually is not practical -- and in many cases, you do not even know exactly what the agent has stored.
• Skill configurations may have been tuned through iterations you did not document. The current state is the result of experimentation, not a config file you can read.
• Environment variables span multiple providers and services. Listing them all from memory is error-prone, and missing one means a broken integration that only surfaces when the agent tries to use it.
• Soul.md and system prompts are the easy part, but even these may have evolved from the original version in ways you do not fully remember.

The more an agent has been used, the more painful a manual migration becomes. And the agents most worth migrating are exactly the ones with the most accumulated state.

Our approach: token handshake and end-to-end encrypted transfer

We built an import path centered on a question skeptical users will ask: "Why would I share my API keys with a platform I have never heard of?"

The answer: you are not sharing them with us. Here is how it works.

The trust model

The import path is built on three pillars:

1. Your secrets never touch our database. The encrypted payload passes through our API as an opaque blob. The private key exists only inside the container on your VPS. We physically cannot decrypt it.
2. Your API keys land in your own container's .env. After import, you can SSH into your server and verify the keys are exactly where they should be. We do not hold copies.
3. The import token is single-use and time-limited. It expires in 15 minutes and is consumed on first use. Even if intercepted, it cannot be replayed.

Step 1: Generate an import token

In the LaunchThatBot dashboard, navigate to your agent's detail page and click Import Agent. This generates:

• A one-time import token (64-character hex string, valid for 15 minutes)
• An RSA-2048 public key that your old instance will use to encrypt secrets

The raw token is shown once and never stored. Only its SHA-256 hash lives in the database. The RSA private key is encrypted at rest with AES-256-GCM and stored alongside the token record.

Step 2: Install the LaunchThatBot Import skill

You add the launchthatbot-import skill to your existing OpenClaw instance, the same way you add any other skill. No changes to your existing configuration. No disruption to your running agent.

Step 3: Tell your agent to export

The skill is conversational. You tell your agent to export its configuration to LaunchThatBot, and it asks you for the import token and the platform URL.

Then it collects:

• Soul and personality -- your soul.md, system prompts, and personality configuration
• Memory banks -- accumulated context, conversation history, learned preferences
• Skills and MCP servers -- all connected tools and their configurations
• Environment variables -- API keys, tokens, and secrets for connected services

You choose what to transfer. Want to bring everything? Say everything. Want to leave behind old memory banks and start fresh on the new deployment? You can do that too.

Step 4: Secrets are encrypted on your machine

Before anything leaves your old instance, the skill encrypts each secret value with the RSA public key from Step 1. This means:

• Config files (soul.md, memory, skills) travel as plaintext -- they are not sensitive
• Secret values (API keys, tokens) travel as RSA-OAEP ciphertext -- only the target container can decrypt them
• The entire payload travels over TLS, adding a second layer of transport encryption

Even if someone intercepted the HTTPS request, they would get RSA-encrypted blobs that require a private key locked inside a specific Docker container on your VPS.

Step 5: LaunchThatBot relays the payload

The encrypted payload hits our /api/import/push endpoint. Here is what happens server-side:

1. The token is validated (hash lookup, expiry check, single-use enforcement)
2. The token is marked as consumed -- it cannot be used again
3. The encrypted payload is relayed to the target container via Portainer exec
4. Inside the container, the RSA private key decrypts each secret
5. Config files are written to the agent's filesystem
6. Secrets are written to the container's .env file

At no point does LaunchThatBot's application code have access to your decrypted secrets. The private key is encrypted at rest and only decrypted inside the target container's process memory, briefly, during import.

Step 6: Verify and shut down

Once the import is complete, the dashboard shows you exactly what was imported:

• Number of config files written
• Number of secrets imported
• Any errors that occurred

Verify your agent has everything it needs. Then shut down your old instance. The import is a one-time transfer, not a continuous sync. This is a deliberate security decision -- we do not want a persistent connection between your old setup and your new one. Clean cutover. One system running, not two.

Security at every layer

Concern	Mitigation
"Why would I share my API keys?"	You are not sharing them with us. They are encrypted on your machine, transit as an opaque blob, and are decrypted only inside your container.
Man-in-the-middle	TLS for transit plus RSA encryption of secrets. Even if TLS were compromised, secrets are RSA-encrypted with a key only the target container holds.
Token theft	15-minute expiry, single-use, SHA-256 hashed in storage. Cannot be replayed after consumption.
LaunchThatBot employee access	Private key is encrypted at rest with AES-256-GCM. Even with database access, an attacker needs the process-level encryption key. Secrets are ephemeral in memory during import only.
Stale import data	Token expires; no persistent connection. The old instance can be shut down immediately after import.

Why agent-based first

The first version of the import path is agent-based: one agent at a time. You point the skill at one agent, export it to one target agent on LaunchThatBot.

This is deliberate. Most OpenClaw users today are running one or two agents. Their agent has a unique soul, unique memory, and a unique set of skills. The import needs to respect that uniqueness -- it is not a bulk operation, it is a careful transfer of everything that makes a specific agent what it is.

Server-based import is on the roadmap

For users running multiple agents on a single server, we are planning a server-based import that can discover all agents on the machine, enumerate their configurations, and transfer them to corresponding agents on LaunchThatBot.

This is a more complex problem -- it involves understanding how agents are organized on the source server, handling shared vs. per-agent configurations, and managing the case where multiple agents share environment variables or skill configurations. We want to get agent-based import right first, then extend to the multi-agent case.

What this means for you today

If you are running an OpenClaw agent on your desktop or a VPS and you have been hesitant to move to LaunchThatBot because of security concerns about sharing sensitive data -- the architecture is designed specifically to address that.

Your secrets never touch our database. The encrypted payload passes through our API as an opaque blob. The private key exists only inside the container on your VPS. You can verify this yourself by inspecting the container after import.

Moving your agent to LaunchThatBot will be a conversation with your existing agent, not a weekend of manual configuration. Tell your agent to export, paste the token, and let the encrypted transfer handle the rest.

In the meantime, if you are starting a new agent, there is no reason to wait. Deploy on LaunchThatBot now and skip the infrastructure work entirely. When you are ready to bring your existing agents over, the import path will be waiting.