08 – Fleet management and CLI [SPEC]

Fleet manifest, batch operations, TUI Infra window, setup flow, self-deploy wizard, and cost tracking

Related: 00-overview.md (compute overview), 03-billing.md (x402 billing), 07-frontend.md (web dashboard)

Reader orientation: This document specifies the fleet management CLI and TUI Infra window for Bardo Compute, the managed VM hosting service for Golems (mortal autonomous DeFi agents). It belongs to the Compute layer of Bardo (the Rust runtime for these agents). The key concept before diving in: owners can manage multiple Golems through the bardo CLI, including batch operations, fleet manifests for declarative multi-agent deployment, and a self-deploy wizard for users who want to run on their own infrastructure. Terms like Golem, Styx, Grimoire, and x402 are defined inline on first use; a full glossary lives in 00-overview.md § Terminology.

Setup flow

First-time authentication

The first time you use Bardo Compute, you authenticate. If you already ran bardo auth login from the TUI wizard, those credentials carry over – no second login needed.

$ bardo compute login

How do you want to sign in?

  [1] Connect existing wallet (MetaMask, WalletConnect)
  [2] Create new wallet (email, Google, GitHub)

Choose [1/2]:

Path 1 opens the browser to auth.bardo.run/wallet-connect, the user connects MetaMask or scans a WalletConnect QR, signs a SIWE message, and optionally sets up delegation. Path 2 opens auth.bardo.run/signup for Privy-based account creation.

Authentication successful.
  Wallet: 0x742d...9f18 (Base)
  Auth:   SIWE (MetaMask)
  Stored: ~/.bardo/credentials.json (mode 0600)

You're ready to deploy. Run: bardo deploy --strategy ./STRATEGY.md

This is one-time. The credentials persist in ~/.bardo/credentials.json with restrictive file permissions. All subsequent bardo deploy and bardo attach commands use these stored credentials silently.

What bardo compute login does behind the scenes:

• Opens a browser-based auth flow (wallet connect or Privy, user’s choice)
• Receives a JWT upon successful authentication (SIWE session JWT or Privy JWT)
• Stores the JWT and refresh token locally
• Verifies the user has a USDC balance on Base (warns if zero)
• For wallet-connect path: sets up ERC-7715 delegation if not already configured
• Optionally prompts for default deployment preferences (tier, custody mode)

Subsequent deploys

After login, bardo deploy works without further authentication. The CLI loads stored credentials, constructs the x402 payment, and provisions. No browser. No prompts. No ceremony.

$ bardo deploy --strategy ./momentum.md
# That's it. Deploys in ~5 seconds.

If the JWT has expired, the CLI refreshes it automatically using the stored refresh token. If the refresh token is expired, it prompts for re-authentication.

Strategy upload

At deploy time, three files get injected into the container:

1. golem.toml – Generated by the control plane from your deploy parameters. Contains golem ID, owner address, custody configuration, Styx URL, inference provider configuration, tool profile, and tier. You never write this file manually. For USDC-based inference providers (Bardo, Bankr), no API keys are injected – the golem pays from its own wallet via x402. For key-based providers (Venice, Anthropic, OpenAI), API keys from the owner’s keychain are encrypted and injected into the container’s golem.toml at deploy time.

2. STRATEGY.md – Your strategy file. Written by you (or generated by Meta Hermes in the TUI). Contains entry/exit criteria, risk parameters, target protocols, asset allocation, position sizing rules, and any custom constraints. Hot-swappable without restarting the golem. STRATEGY.md changes are detected via fsnotify file watcher. On change: re-parse, validate, diff against current strategy, apply. No golem restart required. Hot-swap latency: <1 heartbeat tick. Invalid STRATEGY.md files are rejected with a warning log; the previous strategy remains active.

3. Wallet configuration – Every golem receives credentials for both its identity address and its spending authority (the two-address model). Injected as Fly.io per-machine env vars (not app-wide secrets, so one golem cannot read another’s keys).

The deploy command:

$ bardo deploy \
  --strategy ./my-strategy.md \
  --tier medium \
  --custody delegation \
  --hours 72

The --hours flag determines how much USDC to pay. 72 hours at $0.10/hr = $7.20 USDC. Minimum purchase is 1 hour.

No frontend on Bardo Compute

This is a design decision, not a limitation.

The golem container has no web dashboard. No browser UI. No React app. No port 80. The container runs a single Rust binary with three internal endpoints: a public API on :3000, an owner-authenticated API on :3001, and an internal health endpoint on :3002. None of these are designed for human browsing.

Why

The golem doesn’t need a face. It’s an autonomous agent running a heartbeat loop. What would a web dashboard show? The same information the TUI already shows, except rendered in a browser, requiring authentication, adding attack surface, consuming memory, and needing its own deployment pipeline.

The TUI is the face. It connects to the remote golem via Styx relay and renders everything: heartbeat events, trading activity, position status, vitality, emotional state, inference costs, Grimoire entries. The data flows over WebSocket from the golem through Styx to your terminal. Real-time. No browser needed.

How TUI reaches remote golems

Your machine                    Public internet               Bardo Compute
+-----------+                  +----------+                 +---------------+
|  bardo    | ---- WSS -----> |  Styx    | <---- WSS ---- |  golem binary |
|  terminal |                  |  relay   |                 |  (no UI)      |
+-----------+                  +----------+                 +---------------+
     |                              |
     |  GolemEvents flow:           |
     |  golem -> Styx -> TUI        |
     |                              |
     |  Steers flow:                |
     |  TUI -> Styx -> golem        |

The golem emits 50+ typed GolemEvent variants through its Event Fabric: heartbeat ticks, tool executions, trades, dream cycles, vitality updates, inference calls. These events stream over the Styx WebSocket. The TUI subscribes and renders them.

Steers (commands from the user) flow the other direction. When you hot-swap a strategy or adjust a risk parameter in the TUI, the steer travels through Styx to the golem.

Both directions use persistent WebSocket. Both are outbound-only from their respective endpoints. A golem behind Fly’s 6PN private network and a TUI behind home NAT both work without port forwarding.

What the TUI shows instead

Everything you’d want from a dashboard, rendered in your terminal:

• Live heartbeat stream with tier selection, gate results, and execution details
• Position table with real-time P&L, unrealized gains, and risk metrics
• Vitality gauges showing the three death clocks (economic, epistemic, stochastic)
• Inference cost breakdown by model and provider
• Grimoire activity (writes, pruning cycles, dream insights)
• Styx connection status and clade sync health
• TTL countdown with cost-per-hour and projected remaining balance

The TUI renders this with sub-second latency. The Styx relay adds ~20-50ms. You get real-time monitoring of a remote golem from your terminal, without running a web server on the golem.

Fleet management

Deploying multiple golems

One user can run up to 5 active golems (v1 limit). Deploy them independently:

$ bardo deploy --strategy ./eth-momentum.md --tier small --hours 168
$ bardo deploy --strategy ./arb-base-mainnet.md --tier medium --hours 72
$ bardo deploy --strategy ./lp-watcher.md --tier micro --hours 720

Or use a fleet manifest:

# fleet.toml
[[golems]]
strategy = "./strategies/eth-momentum.md"
tier = "small"
hours = 168

[[golems]]
strategy = "./strategies/arb-base-mainnet.md"
tier = "medium"
hours = 72

[[golems]]
strategy = "./strategies/lp-watcher.md"
tier = "micro"
hours = 720

$ bardo fleet deploy --manifest fleet.toml
Deploying 3 golems...
  [1/3] golem-kX9mR2Yq7pLN  small   eth-momentum       168h  $8.40
  [2/3] golem-pQ4nT8Ws2jDm  medium  arb-base-mainnet    72h  $7.20
  [3/3] golem-rW7bN3Xk9mPq  micro   lp-watcher         720h  $18.00

Total: $33.60 USDC

Confirm? [y/N]

Fleet deploy creates each golem sequentially (parallel provisioning is phase 2). Each gets its own x402 payment, its own machine name, its own TTL.

Naming and tagging

Machine names are cryptographic (golem-{nanoid(12)}). Not human-friendly, but secure: names can’t be guessed or enumerated. For human identification, the TUI shows strategy names alongside machine names.

Users can add tags for organization:

$ bardo tag golem-kX9mR2Yq7pLN --add "production" --add "eth"
$ bardo list --tag production

Tags are stored locally in ~/.bardo/tags.json. They don’t exist on the server. This keeps the server API simple and avoids another data model.

Batch operations

$ bardo fleet kill --all                    # Kill all active golems (confirms first)
$ bardo fleet extend --all --hours 24       # Extend all golems by 24 hours
$ bardo fleet restart --tag production      # Restart all golems tagged "production"
$ bardo fleet status                        # Show all golems with status summary

Batch operations run sequentially and show progress:

$ bardo fleet extend --all --hours 24
Extending 3 golems...
  golem-kX9mR2Yq7pLN  +24h  $1.20  done
  golem-pQ4nT8Ws2jDm  +24h  $2.40  done
  golem-rW7bN3Xk9mPq  +24h  $0.60  done

Total: $4.20 USDC

Cost aggregation

The TUI aggregates costs across the fleet. The CLI does too:

$ bardo fleet costs --period 7d
Fleet cost report (last 7 days):

  golem-kX9mR2Yq7pLN (small, eth-momentum)
    Compute:    $8.40
    Inference:  $2.31
    Gas:        $0.89
    Subtotal:   $11.60
    Revenue:    $18.42
    Net:        +$6.82

  golem-pQ4nT8Ws2jDm (medium, arb-base-mainnet)
    Compute:    $7.20
    Inference:  $4.17
    Gas:        $2.34
    Subtotal:   $13.71
    Revenue:    $21.09
    Net:        +$7.38

  golem-rW7bN3Xk9mPq (micro, lp-watcher)
    Compute:    $4.20
    Inference:  $0.42
    Gas:        $0.03
    Subtotal:   $4.65
    Revenue:    $0.00
    Net:        -$4.65

  Fleet total:
    Spent:      $29.96
    Revenue:    $39.51
    Net:        +$9.55
    Sustainability: 1.32x

Credits and bulk purchases

For users who want predictable costs, credits are pre-purchased USDC balances on the Bardo platform. You deposit USDC and draw down against it for provisioning and extensions.

Credit pricing:

Credits simplify the deploy flow: instead of signing an x402 payment for each deploy, you sign once for the credit deposit and subsequent deploys deduct from your balance. This is a convenience layer over x402, not a replacement.

Combined cost of ownership

Monthly cost estimates at 24/7 operation:

These are compute costs only. Styx is free. Inference and gas add to the total. For a context-engineered golem that routes 95% of decisions through T0 (deterministic, free) and T1 (Haiku, cheap), inference adds maybe $0.20-0.50/day. Gas depends on chain and activity.

TUI Infra window

The TUI’s Infra window (accessible via Tab) shows all compute golems managed by the authenticated user. This is your fleet command center.

Process table

+-- Compute Golems -----------------------------------------------+
| Name                 Tier    Region  Status   Uptime   TTL       |
| golem-kX9mR2Yq7pLN  small   ord     running  14h 23m  33h 37m   |
| golem-pQ4nT8Ws2jDm  medium  ams     running  3h 12m   44h 48m   |
| golem-rW7bN3Xk9mPq  micro   ord     crashed  2h 01m   --        |
|                                                                   |
| [D] Deploy new  [K] Kill  [R] Restart  [E] Extend  [T] Change tier |
+------------------------------------------------------------------+

Each row shows:

• Name – The golem’s nanoid identifier
• Tier – micro/small/medium/large
• Region – Fly.io region code (ord, ams, etc.)
• Status – running, provisioning, booting, draining, crashed, destroyed
• Uptime – Time since last boot
• TTL – Time remaining before death (red when <1h, amber when <6h)

Health indicators

Expanding a golem row shows detailed health:

+-- golem-kX9mR2Yq7pLN (expanded) --------------------------------+
|                                                                    |
|  Heartbeat:   active, 234ms avg, tick #3,427                     |
|  Styx:        connected (23ms latency, last sync 4s ago)         |
|  Vitality:    0.87 (thriving)                                    |
|  Phase:       stable                                              |
|  CPU:         12% avg (last 5m)                                  |
|  Memory:      187MB / 512MB (36%)                                |
|  Disk:        124MB / 1GB (12%)                                  |
|  Crashes:     0                                                   |
|                                                                    |
|  Inference (last 1h):                                            |
|    T0: 847 calls ($0.00)                                         |
|    T1: 92 calls ($0.18)                                          |
|    T2: 3 calls ($0.09)                                           |
|                                                                    |
|  Strategy: momentum (ETH/USDC, Base)                             |
|  Wallet: 0x7a3f...9e21 (delegation, $2,340 managed)             |
+-------------------------------------------------------------------+

Quick actions

From the process table, single-keypress actions:

• [D] Deploy – Opens the deploy wizard (strategy file, tier, hours, custody mode)
• [K] Kill – Initiates graceful shutdown (Thanatopsis). Confirms before executing.
• [R] Restart – Stops and restarts the golem binary. Grimoire preserved. Useful after strategy updates.
• [E] Extend – Prompts for hours, sends x402 extension payment
• [T] Change tier – Destroys current machine and re-provisions at the new tier. Strategy and Grimoire carry over via snapshot restore.

Cost tracking panel

The bottom of the Infra window shows fleet-wide economics:

+-- Fleet Economics (last 24h) ------------------------------------+
|  Total spent:   $4.23 (compute: $2.88, inference: $1.18, gas: $0.17) |
|  Total revenue: $7.91 (fees: $5.20, LP: $2.71)                      |
|  Net:           +$3.68                                               |
|  Sustainability: 1.87x (self-sustaining)                             |
|  Projected monthly: $127 spend, $237 revenue                         |
+-------------------------------------------------------------------+

When the fleet is self-sustaining (sustainability_ratio > 1.0), the sustainability number turns green. Below 1.0, it turns amber. Below 0.5, red. This maps directly to the economic death clock.

Cost transparency

The TUI’s Infra window shows a running cost ticker per golem:

+-- Compute Costs -----------------------------------------------+
|                                                                  |
|  golem-kX9mR2Yq7pLN                                            |
|    Rate:      $0.05/hr (small)                                  |
|    Running:   14h 23m                                           |
|    Spent:     $0.72 compute + $0.31 inference + $0.04 gas       |
|    Total:     $1.07                                             |
|    TTL:       33h 37m remaining                                 |
|    Projected: $2.58/day | $77/month (at current usage)          |
|                                                                  |
|  golem-pQ4nT8Ws2jDm                                            |
|    Rate:      $0.10/hr (medium)                                 |
|    Running:   3h 12m                                            |
|    Spent:     $0.32 compute + $0.08 inference + $0.01 gas       |
|    Total:     $0.41                                             |
|    TTL:       44h 48m remaining                                 |
|    Projected: $3.10/day | $93/month                             |
|                                                                  |
|  Fleet total: $1.48 spent | $5.68/day projected                 |
+----------------------------------------------------------------+

The projected monthly spend is a moving average over the last 24 hours of actual costs (compute + inference + gas). It updates every heartbeat tick.

Self-deploy wizard

For users who want their own infrastructure

Not everyone wants managed compute. Some users want control over their infrastructure but don’t want to manually set up a golem from scratch. The self-deploy helper bridges this gap.

$ bardo deploy --self-host

This launches an interactive wizard:

Self-hosted deployment

Where would you like to deploy?
  [1] fly.io (your Fly account)
  [2] Docker (local or remote)
  [3] VPS via SSH
  [4] Generate files only (manual setup)

> 2

Docker deployment
  Generating docker-compose.yml...

  The compose file includes:
    - golem binary (latest)
    - Styx connection (outbound only)
    - Grimoire storage (local volume)
    - Health monitoring

  Configuration:
    Strategy file: ./my-strategy.md
    Custody mode: delegation
    Styx URL: wss://styx.bardo.run/v1/styx/ws

  Files written:
    ./bardo-deploy/docker-compose.yml
    ./bardo-deploy/golem.toml
    ./bardo-deploy/.env.example

  To start: cd bardo-deploy && docker compose up -d
  To connect: bardo attach --direct ws://localhost:8080/ws

Provider-specific commands

# Your own Fly.io account
bardo deploy --provider fly --app-name my-golem --region iad

# Railway
bardo deploy --provider railway --project my-golem

# Any VPS via SSH
bardo deploy --provider ssh --host 203.0.113.42 --user root

# Local Docker
bardo deploy --provider docker --name my-golem

Each provider path handles the specifics: Fly.io gets a fly.toml, Railway gets a railway.json, SSH gets a systemd service + binary upload, Docker gets a compose file.

Differences from managed

When to self-host

Self-host when:

• You want to control costs (managed path has a ~3x markup over raw Fly.io costs)
• You have existing infrastructure (a beefy home server, a Hetzner box)
• You want to run the inference gateway locally alongside the golem
• You want full control over the OS, networking, and updates

Cross-references