Self-host

Run the caput bot on your own infrastructure: a Pi, a NAS, a home server, a VPS you control. Total sovereignty, total responsibility.

Why self-host

• Full control over the host environment.
• No third-party platform between you and your bot.
• Often cheaper than managed hosting if you already have hardware.
• Best option if you have specific operational requirements (firewalls, custom networking, audit logging) that managed platforms don't expose.

Trade-offs

• You manage uptime. No platform auto-restart. No platform monitoring. If your power flickers and your Pi reboots without supervisor, the bot doesn't come back.
• You manage public reachability. A self-hosted bot needs an inbound HTTPS endpoint that buyers can reach. This means either a static public IP, a tunnel service, or dynamic DNS.
• You manage TLS certificates.
• You manage updates.

If any of those is "no thanks," use Railway, Render, or Fly.io instead.

What you need

• A machine with reliable power and internet, running Linux (Ubuntu, Debian, Alpine, etc.). Raspberry Pi 4+ is sufficient.
• Docker installed.
• A way to expose the bot's public port to the internet:
  • Static public IP and a domain name pointing at it
  • A tunnel service (Cloudflare Tunnel, ngrok, Tailscale Funnel)
  • Dynamic DNS with port forwarding on your router
• TLS — easiest via the tunnel option, otherwise via Caddy or nginx with Let's Encrypt.

Steps

1. Pull the Docker image

When the bot ships (Phase 2+), pull the image:

docker pull caputdev/caput-bot:latest

Verify the image hash against the published sha256 on caput.dev:

docker inspect caputdev/caput-bot:latest --format='{{.Id}}'

Compare this hash with the one published on the caput.dev site for that release. If they don't match, do not run the image.

2. Prepare your config

In a directory you'll use for caput:

mkdir -p /opt/caput/data
cp /path/to/your/bundle/config.env /opt/caput/config.env

Edit /opt/caput/config.env:

• Keep LICENSE_* values as baked from the configurator.
• Set XRPL_NETWORK=testnet for testing, mainnet for production.
• Set STATE_DB_PATH=/data/caput.db (path inside the container).
• Set PUBLIC_HOST to your public URL (whatever you set up in step 5).

3. Run the container

Basic run:

docker run -d \
  --name caput-bot \
  --restart=always \
  --env-file /opt/caput/config.env \
  -v /opt/caput/data:/data \
  -p 7777:7777 \
  -p 8080:8080 \
  caputdev/caput-bot:latest

The --restart=always flag tells Docker to restart the container if it crashes or if the host reboots. This is critical.

-p 7777:7777 exposes the admin UI on localhost:7777 (admin should never be exposed to the internet).

-p 8080:8080 exposes the public buyer-facing UI; this is what you'll route through your reverse proxy.

4. Verify it's running

docker logs caput-bot

Check for the admin setup token in the startup logs.

5. Expose the public port

You have several options. Pick one:

Option A — Cloudflare Tunnel (recommended for self-host).

Install cloudflared, point it at port 8080:

cloudflared tunnel create caput-bot
cloudflared tunnel route dns caput-bot caput.yourdomain.com
cloudflared tunnel run --url http://localhost:8080 caput-bot

Cloudflare handles TLS. No port forwarding on your router. Your home IP is not exposed. Free for personal use.

Option B — Caddy reverse proxy with Let's Encrypt.

If you have a static public IP and a domain:

# /etc/caddy/Caddyfile
caput.yourdomain.com {
    reverse_proxy localhost:8080
}

Caddy handles TLS automatically. Forward ports 80 and 443 on your router.

Option C — Tailscale Funnel.

If you use Tailscale:

tailscale funnel 8080

Exposes your bot via Tailscale's edge, no router config needed.

6. First-run setup

Visit your bot's admin URL from your local network only:

http://localhost:7777/admin?setup=XXXX-XXXX-XXXX

Use the setup token from the docker logs.

Connect your wallet adapter, verify license, configure.

7. Set up uptime monitoring

External monitoring is even more important when self-hosting. Recommendations:

• UptimeRobot with HTTP check on https://caput.yourdomain.com/health every 5 minutes.
• Healthchecks.io with a periodic ping from a cron inside the container.
• A second machine that pings the first and alerts you if it stops responding.

If your house loses power and your bot is offline, you need to know within minutes, not hours.

8. Set up local monitoring

On the host machine itself:

# /etc/systemd/system/caput-watchdog.service
[Unit]
Description=Caput bot health watchdog
After=docker.service

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do if ! docker exec caput-bot wget -q --spider http://localhost:8080/health; then echo "BOT DOWN" | mail -s "Caput bot down" you@example.com; fi; sleep 60; done'
Restart=always

[Install]
WantedBy=multi-user.target

This is one of many possible patterns. The point: have something local watching the bot, separate from the bot itself.

9. Updating

When a new release comes out:

docker pull caputdev/caput-bot:latest
# Verify hash against caput.dev
docker stop caput-bot
docker rm caput-bot
# Re-run the docker run command from step 3

State is in /opt/caput/data — preserved across container replacements.

10. Backups

The /opt/caput/data directory contains your SQLite database. Back it up regularly:

# Daily backup
0 3 * * * cp /opt/caput/data/caput.db /opt/caput/backups/caput-$(date +\%Y\%m\%d).db

Restoring from backup loses any open positions that were created after the backup. Most state is reconstructable from the chain via caput-bot rebuild-state, but pre-signed exit transactions for active positions are not — they only exist locally. If you lose them and lose the chain-derivable copy, you cannot fire liquidation on those positions until the chain reconstructs them.

Costs

• Hardware: yours.
• Power: yours.
• Internet: yours.
• Monitoring: free tiers usually adequate.
• Domain (if needed): ~$15/year.
• Total marginal cost: ~$0/month if you're using existing hardware.

Plus XRPL transaction fees from your wallet.

When self-host is the wrong choice

• You don't already have reliable hardware and internet.
• You don't have time to monitor and maintain it.
• Your contracts will represent material value and you can't accept the operational risk of self-hosting.
• You haven't deployed and managed self-hosted services before.

For all of the above, use Railway, Render, or Fly.io. Operational reliability is part of the seller's risk surface, and managed platforms reduce it meaningfully compared to self-host.

Support

Self-host means self-support. Read the source on GitHub. The Docker image and runtime behavior are documented there.