18-Network Docker Setup: Deploy Multi-Chain AI Agent Infrastructure

2026-09-20

Self-Hosted Multi-Chain AI Agent Infrastructure: Deploy WAIaaS Across 18 Networks with Docker

Docker makes it surprisingly straightforward to run your own multi-chain AI agent wallet infrastructure — but most developers don't realize they can have the whole thing running locally in under five minutes, with no third-party custody of their keys. If you've ever felt uneasy handing an AI agent's private keys to a hosted service, or hit rate limits on a managed wallet API at the worst possible moment, this post is for you.

Would You Trust a Third Party With Your Agent's Private Keys?

It's a fair question. When you use a hosted wallet-as-a-service, you're typically making a deal: convenience in exchange for custody. Someone else's server holds the keys, processes the transactions, and sits between your AI agent and the blockchain. For personal projects or low-stakes experiments, that trade-off is fine. But as soon as real funds are involved — or you need predictable uptime, custom policies, or just don't want to explain your agent's trading activity to a third-party compliance team — the hosted model starts to feel like running your own email but using Gmail to store the messages.

The alternative is self-hosting. Your server, your keys, your rules.

WAIaaS is an open-source, self-hosted Wallet-as-a-Service built specifically for AI agents. It runs in Docker, covers 18 networks across EVM chains and Solana, integrates with 15 DeFi protocols, and ships with a policy engine that puts you — not the platform — in control of what your agents can and can't do.

Why Self-Hosting Actually Makes Sense Here

The crypto self-hosting instinct is well-established. People run their own nodes, their own validators, their own RPC endpoints. The reasons are always the same: privacy, reliability, and sovereignty. WAIaaS extends that philosophy to the wallet infrastructure layer.

When your AI agent needs to swap tokens, check a balance, or execute a DeFi position, it's talking to your local daemon — not an external API with its own rate limits, terms of service, or downtime schedule. You configure which RPC endpoints to use. You decide which networks are active. You set the policies that govern what the agent is allowed to spend, where it can send funds, and which contracts it can interact with. None of that configuration lives on someone else's server.

There's also a practical engineering argument: the hosted model means your agent's behavior is coupled to external API availability. A self-hosted daemon bound to 127.0.0.1:3100 is a dependency you control entirely.

What You're Actually Deploying

WAIaaS ships as a 15-package monorepo with two Docker images: the main daemon and a push-relay for notifications. The daemon exposes 39 REST API route modules, supports 45 MCP tools for AI agent integration, and implements a 7-stage transaction pipeline that handles validation, policy checks, gas conditions, execution, and confirmation.

The network coverage is broad: 18 networks across two chain types (EVM and Solana). You point each network at your own RPC endpoint using environment variables, so you're never dependent on WAIaaS's infrastructure for chain connectivity.

The 15 DeFi protocol integrations — covering lending (Aave v3, Kamino), swaps (Jupiter, 0x, LI.FI, D'CENT), staking (Lido, Jito), perpetuals (Hyperliquid, Drift), prediction markets (Polymarket), bridging (Across), and more — run through the same local daemon. Your agent's DeFi activity stays between your server and the chain.

Getting the Daemon Running

The simplest path to a running instance is three commands:

git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d

That's it for a development setup. The Docker Compose file binds to 127.0.0.1:3100 by default, so the daemon is only accessible from localhost unless you explicitly change that.

For a more self-contained start — useful if you want to skip cloning the repo entirely — you can use docker run with auto-provision:

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  -e WAIAAS_AUTO_PROVISION=true \
  ghcr.io/waiaas/waiaas:latest

# Retrieve auto-generated master password
docker exec waiaas cat /data/recovery.key

WAIAAS_AUTO_PROVISION=true generates a random master password on first start and writes it to /data/recovery.key inside the container. You retrieve it once, store it somewhere safe, and then delete the recovery file. The data persists in a named Docker volume, so docker compose down without -v preserves everything.

Configuring Your RPC Endpoints

This is the part that actually makes self-hosting meaningful. WAIaaS lets you specify RPC endpoints per network via environment variables:

WAIAAS_RPC_SOLANA_MAINNET=<url>
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<url>

You can point these at your own node, a private RPC provider you already pay for, or a public endpoint — your choice. The daemon doesn't phone home for chain connectivity.

The full Docker Compose configuration gives you a clear picture of what's configurable:

services:
  daemon:
    image: ghcr.io/waiaas/waiaas:latest
    container_name: waiaas-daemon
    ports:
      - "127.0.0.1:3100:3100"
    volumes:
      - waiaas-data:/data
    environment:
      - WAIAAS_DATA_DIR=/data
      - WAIAAS_DAEMON_HOSTNAME=0.0.0.0
    env_file:
      - path: .env
        required: false
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

volumes:
  waiaas-data:
    driver: local

Put your RPC URLs and other configuration in a .env file in the same directory. The env_file stanza picks it up automatically, and required: false means the daemon starts fine without it if you're just exploring.

Hardening for Production: Docker Secrets

If you're running this on a homelab server or a VPS you control, environment variables in a .env file are convenient but not ideal for sensitive values. WAIaaS supports Docker Secrets for production deployments via a secrets overlay file:

# Create secret files
mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt

# Deploy with secrets overlay
docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

The entrypoint script reads secrets from the Docker Secrets mechanism, which mounts them as files in /run/secrets/ rather than exposing them as environment variables. For a homelab setup where you care about not having credentials in docker inspect output, this is worth the extra step.

The daemon also runs as a non-root user (UID 1001) by default, which is one of those small things that matters when you're thinking about container security seriously.

Creating Wallets and Issuing Agent Sessions

Once the daemon is running, you interact with it through its REST API. Three authentication headers cover different roles: X-Master-Password for system administration (wallet creation, session management, policies), Authorization: Bearer for AI agent sessions, and X-Owner-Signature for fund-owner approval of high-value transactions.

Create a wallet:

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

Then create a session token for your AI agent:

curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

The session token is what your agent actually uses. It's scoped to a specific wallet, and its capabilities are bounded by whatever policies you've attached to that wallet. The master password never leaves your environment.

If you prefer the CLI, waiaas quickset --mode mainnet creates wallets and MCP sessions in a single command.

The Policy Engine: Defining What Your Agent Can Do

Self-hosting is only half the sovereignty story. The other half is controlling what your agent is actually allowed to do with the funds you've given it access to.

WAIaaS implements a policy engine with 21 policy types and 4 security tiers: INSTANT (execute immediately), NOTIFY (execute and notify you), DELAY (queue for a configurable number of seconds, cancellable), and APPROVAL (require explicit human sign-off). The engine is default-deny: transactions involving tokens not on the ALLOWED_TOKENS whitelist, or contracts not on the CONTRACT_WHITELIST, are blocked.

A spending limit policy that tiers transactions by USD value looks like this:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

With this configuration, transactions under $100 execute immediately. Transactions between $100 and $500 trigger a notification. Transactions between $500 and $2,000 are queued for 15 minutes before execution, giving you a window to cancel. Anything over $2,000 requires your explicit approval — delivered via WalletConnect, Telegram, or push notification, depending on how you've configured signing channels.

The full list of 21 policy types covers DeFi-specific constraints too: LENDING_LTV_LIMIT caps loan-to-value ratios, PERP_MAX_LEVERAGE limits futures leverage, PERP_MAX_POSITION_USD caps position sizes, and X402_ALLOWED_DOMAINS controls which APIs your agent can pay for automatically via the x402 HTTP payment protocol.

Connecting AI Agents via MCP

The most practical integration path for LLM-based agents is MCP (Model Context Protocol). WAIaaS ships 45 MCP tools covering wallet operations, transfers, DeFi actions, NFT management, and x402 payments.

After running waiaas mcp setup --all, you get a configuration block to paste into Claude Desktop:

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

WAIAAS_BASE_URL points at your local daemon. The agent session token scopes what the agent can do. Everything stays local — Claude's tool calls go to 127.0.0.1:3100, which means your wallet interactions never pass through any external MCP relay.

For multi-agent setups, you can run one MCP server entry per wallet, each with its own session token and policy set.

Simulating Before Executing

One useful capability for self-hosters who are still tuning their agent's behavior: dry-run simulation. Before any real transaction hits the chain, you can simulate it:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The pipeline runs through all its stages — validation, policy checks, gas condition evaluation — without submitting anything on-chain. Useful for verifying that your policy configuration is doing what you think it's doing before you let the agent loose.

Quick Start Summary

Five steps from zero to running multi-chain agent infrastructure:

  1. Clone and start: git clone https://github.com/waiaas/WAIaaS.git && cd WAIaaS && docker compose up -d
  2. Create a wallet: POST to /v1/wallets with your master password
  3. Set policies: POST to /v1/policies to define spending limits and token whitelists
  4. Create an agent session: POST to /v1/sessions to get a scoped session token
  5. Connect your agent: Run waiaas mcp setup --all and paste the output into Claude Desktop config

The interactive API reference at http://127.0.0.1:3100/reference documents every endpoint. The OpenAPI 3.0 spec is downloadable at /doc if you want to generate client code or import it into Postman.

What's Next

The 684+ test files in the codebase mean the daemon is genuinely production-ready for homelab and small-scale production use, not just a demo. The GitHub repository at https://github.com/waiaas/WAIaaS has the full setup documentation, and https://waiaas.ai covers the broader ecosystem including SDK references and protocol integration details. If you're already running your own RPC nodes and want to close the loop on self-hosted agent infrastructure, the Docker setup is the natural next step.