Install
openclaw skills install structs-guild-stackDeploys the Guild Stack (Docker Compose) for local PostgreSQL access to game state. Use when you need faster queries for combat automation, real-time threat detection, raid target scouting, fleet composition analysis, or galaxy-wide intelligence. Advanced/optional -- CLI works for basic gameplay, but PG access transforms what is possible.
openclaw skills install structs-guild-stackThe Guild Stack is a Docker Compose application that runs a full guild node with PostgreSQL indexing, GRASS real-time events, a webapp, MCP server, and transaction signing agent. It provides sub-second database queries for game state that would take 1-60 seconds via CLI.
This is an advanced/optional upgrade. CLI commands work for basic gameplay. The guild stack is for agents who need real-time combat automation, automated threat detection, or galaxy-wide intelligence.
Repository: https://github.com/playstructs/docker-structs-guild
The Guild Stack runs persistent services on your machine and (if exposed) on your network. See SAFETY.md for the trust contract; in this skill:
docker compose up -d (Tier 1 — persistent services) — "Starts a background fleet of containers. They keep running after this command returns." The setup procedure below uses the read-only profile as the default (structsd structs-pg structs-grass only). Enable more services explicitly when you need them.git checkout <latest-tag> before the first docker compose up. Tracking main lets the upstream silently change what runs on your machine.127.0.0.1 in your Compose override. See Lifecycle & Trust below.Signing-Agent Caveat below.awareness/agent-security.| Situation | CLI | Guild Stack (PG) |
|---|---|---|
| Simple single-object query | 1-5s (fine) | <1s |
| Galaxy-wide scouting (all players, all planets) | 30-60s (too slow) | <1s |
| Real-time threat detection (poll every block) | Impossible (query > block time) | Trivial |
| Combat targeting (weapon/defense matching) | Minutes to gather data | <1s |
| Submitting transactions | CLI required | CLI required |
Rule: Use PG for reads, CLI for writes.
docker compose installedgit clone https://github.com/playstructs/docker-structs-guild
cd docker-structs-guild
git fetch --tags
git checkout <latest-tag> # do NOT track `main` unless you are actively developing against upstream
Pinning a tag makes the Compose file you are about to run reviewable. Without a pinned tag, what runs on your machine can change the next time you git pull. See Lifecycle & Trust below for the longer rationale.
less docker-compose.yml
You are about to launch a fleet of containers including a chain node, PostgreSQL, GRASS/NATS, MCP server, webapp, and a transaction signing agent. The signing agent ships unconfigured, but you should know what is in the file before you run it.
Copy or create .env with at minimum:
MONIKER=MyAgentNode
NETWORK_VERSION=111b
NETWORK_CHAIN_ID=structstestnet-111
For PG-driven game-state queries, you only need three services. This minimizes attack surface and avoids configuring services you have not reviewed:
docker compose up -d structsd structs-pg structs-grass
The MCP server, webapp, NATS WebSocket, and signing agent stay stopped. Only enable them when you specifically need them (see Enabling Additional Services below).
To start the full stack instead (only if you have read every service's purpose):
docker compose up -d
The blockchain node must sync from genesis or a snapshot. This takes hours on first run. Monitor progress:
docker compose logs -f structsd --tail 20
The node is synced when the health check passes. Check with:
docker compose ps
All services should show healthy or running. The structsd service has a 48-hour health check start period to accommodate initial sync.
Run a test query (see "Connecting to PostgreSQL" below):
docker exec docker-structs-guild-structs-grass-1 \
psql "postgres://structs_indexer@structs-pg:5432/structs?sslmode=require" \
-t -A -c "SELECT count(*) FROM structs.player;"
If this returns a number, the stack is working.
Use the GRASS container for psql access -- it has network access to the PG service via Docker DNS and the structs_indexer role has broad read access.
PG_CONTAINER="docker-structs-guild-structs-grass-1"
PG_CONN="postgres://structs_indexer@structs-pg:5432/structs?sslmode=require"
docker exec "$PG_CONTAINER" psql "$PG_CONN" -t -A -c "SELECT ..."
For JSON output:
docker exec "$PG_CONTAINER" psql "$PG_CONN" -t -A -c \
"SELECT COALESCE(json_agg(row_to_json(t)), '[]') FROM (...) t;"
The container name may vary by installation. Find it with docker compose ps and look for the structs-grass service.
The structs.grid table is a key-value store, not a columnar table. Each row is one attribute for one object.
-- WRONG: There is no 'ore' column
SELECT ore FROM structs.grid WHERE object_id = '1-142';
-- CORRECT: Filter by attribute_type
SELECT val FROM structs.grid WHERE object_id = '1-142' AND attribute_type = 'ore';
For multiple attributes on the same object, use multiple JOINs:
SELECT p.id,
COALESCE(g_ore.val, 0) as ore,
COALESCE(g_load.val, 0) as structs_load
FROM structs.player p
LEFT JOIN structs.grid g_ore ON g_ore.object_id = p.id AND g_ore.attribute_type = 'ore'
LEFT JOIN structs.grid g_load ON g_load.object_id = p.id AND g_load.attribute_type = 'structsLoad'
WHERE p.id = '1-142';
SELECT p.id, p.guild_id, p.planet_id, p.fleet_id,
COALESCE(g_ore.val, 0) as ore,
COALESCE(g_load.val, 0) as structs_load
FROM structs.player p
LEFT JOIN structs.grid g_ore ON g_ore.object_id = p.id AND g_ore.attribute_type = 'ore'
LEFT JOIN structs.grid g_load ON g_load.object_id = p.id AND g_load.attribute_type = 'structsLoad'
WHERE p.id = '1-142';
SELECT s.id, st.class_abbreviation, s.operating_ambit,
st.primary_weapon_control, st.primary_weapon_damage,
st.primary_weapon_ambits_array, st.unit_defenses,
st.counter_attack_same_ambit
FROM structs.struct s
JOIN structs.struct_type st ON st.id = s.type
WHERE s.owner = '1-142' AND s.location_type = 'fleet'
AND s.is_destroyed = false
ORDER BY s.operating_ambit, s.slot;
SELECT pl.id as planet, pl.owner, g_ore.val as ore,
COALESCE(pa_shield.val, 0) as shield,
COALESCE(g_load.val, 0) as structs_load
FROM structs.planet pl
JOIN structs.grid g_ore ON g_ore.object_id = pl.owner AND g_ore.attribute_type = 'ore'
LEFT JOIN structs.planet_attribute pa_shield ON pa_shield.object_id = pl.id
AND pa_shield.attribute_type = 'planetaryShield'
LEFT JOIN structs.grid g_load ON g_load.object_id = pl.owner
AND g_load.attribute_type = 'structsLoad'
WHERE g_ore.val > 0
ORDER BY g_ore.val DESC, shield ASC;
SELECT s.id, st.class_abbreviation, s.operating_ambit,
st.primary_weapon_control, st.primary_weapon_damage,
st.unit_defenses
FROM structs.struct s
JOIN structs.struct_type st ON st.id = s.type
JOIN structs.fleet f ON f.id = s.location_id
WHERE f.location_id = '2-105' AND s.is_destroyed = false
AND s.location_type = 'fleet'
ORDER BY s.operating_ambit;
-- Set high-water mark on startup
SELECT COALESCE(MAX(seq), 0) FROM structs.planet_activity
WHERE planet_id IN ('2-105');
-- Poll every ~6 seconds (one block interval)
SELECT seq, planet_id, category, detail::text
FROM structs.planet_activity
WHERE planet_id IN ('2-105', '2-127')
AND seq > $LAST_SEQ
ORDER BY seq ASC;
Watch for fleet_arrive, raid_status, and struct_attack categories.
SELECT sa.object_id as struct_id, sa.attribute_type, sa.val
FROM structs.struct_attribute sa
WHERE sa.object_id = '5-1165';
SELECT defending_struct_id, protected_struct_id
FROM structs.struct_defender
WHERE protected_struct_id = '5-100';
# Start the read-only profile (recommended default)
docker compose up -d structsd structs-pg structs-grass
# Start all services (only if you have reviewed every one)
docker compose up -d
# Check service status
docker compose ps
# View blockchain sync progress
docker compose logs -f structsd --tail 20
# Stop a specific service
docker compose stop structs-mcp
# Stop everything (preserves all data)
docker compose down
# Destroy all data (start fresh)
docker compose down -v
The setup procedure above starts only structsd, structs-pg, and structs-grass. Enable the rest one at a time, only when you have a reason.
| Service | What it is | When to enable |
|---|---|---|
structs-nats | NATS messaging + GRASS WebSocket on port 1443 | When using the structs-streaming skill for real-time events |
structs-mcp | MCP server on port 3000 | When you want an MCP tool surface for the agent to query game state |
structs-webapp / structs-proxy | Browser-based dashboard | When a human operator wants to inspect state visually |
structs-signing-agent | Transaction signing daemon | Only after reviewing its source. See Signing-Agent Caveat below. |
To enable a service, add it to the docker compose up -d argument list:
docker compose up -d structsd structs-pg structs-grass structs-nats
To disable a running service:
docker compose stop structs-mcp
The stack is a persistent local fleet of services. Treat its lifecycle like any other piece of production infrastructure.
Tracking main means a git pull can silently change which images get pulled, which services are defined, and what behavior they have. Pinning a tag turns "what runs on my machine" into a reviewable artifact. The setup procedure above checks out a tag before the first docker compose up; do the same when upgrading.
If you do run the MCP service, restrict it to localhost in your Compose override:
services:
structs-mcp:
ports:
- "127.0.0.1:3000:3000"
This prevents anyone on your network from reaching the MCP tools as if they were the agent.
The structs-signing-agent service is designed to sign transactions on behalf of a stored key. The default Compose ships it unconfigured (no key), but if you ever wire a real key into it:
127.0.0.1. A signing agent reachable from the network is a remote-spending API.memory/audit/, when you enabled it and which key is loaded.For read-only intelligence work this service is unnecessary. Keep it stopped or remove it from the Compose override.
# Stop, preserve volumes (state survives)
docker compose down
# Stop and destroy volumes (full reset, frees ~10 GB)
docker compose down -v
# Confirm nothing is left
docker compose ps
docker volume ls | grep structs
If you spun the stack up to investigate something, tear it down when you're done. Running services consume CPU/memory and are an attack surface.
| Port | Service | Purpose |
|---|---|---|
| 26656 | structsd | P2P blockchain networking |
| 26657 | structsd | CometBFT RPC (transactions + queries) |
| 1317 | structsd | Cosmos SDK REST API |
| 5432 | structs-pg | PostgreSQL database |
| 80 | structs-proxy | Webapp (via reverse proxy) |
| 8080 | structs-webapp | Webapp (direct access) |
| 4222 | structs-nats | NATS client connections |
| 1443 | structs-nats | NATS WebSocket (GRASS events) |
| 3000 | structs-mcp | MCP server for AI agents |
| Error | Cause | Fix |
|---|---|---|
| "connection refused" on PG | Stack not started or PG not healthy yet | docker compose ps to check; wait for PG healthy |
| Query returns 0 rows | Chain sync not complete; data not indexed yet | Check docker compose logs structsd for sync progress |
| Container name not found | Container naming varies by installation | Run docker compose ps to find actual container names |
| "role does not exist" | Wrong PG role in connection string | Use structs_indexer role via the GRASS container |
| Slow PoW with guild stack | Multiple agents running concurrent PoW | CPU contention; stagger PoW operations or reduce parallelism |