bootnode-mode is required by Bee 2.8 to honor --static-nodes, but
bootnode-mode collapses normal peer discovery (homelab dropped from
100+ peers to 2, depth jumped to 31). Use --bootnode to seed an
initial dial to the other gateway instead — that's just a hint, doesn't
change inbound behavior, and leaves hive discovery intact.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bee 2.8 rejects static-nodes config with 'can only be configured on
bootnodes' unless --bootnode-mode is also set. The side-effect of
bootnode-mode (always accepting inbound connections) is fine here —
the gateway pair only matters to each other.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bee 2.8's --static-nodes flag takes the 32-byte Swarm overlay address
(kademlia identifier) and looks the node up via DHT — not a libp2p
multiaddr. The multiaddr form crashes boot with
"invalid swarm address ... configured for static node".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PSS chunks targeting prod's ff89* neighborhood are being routed by
homelab pushsync to random peers in the ff prefix (e.g. ff7adaed) rather
than prod_bee at ff896a93, because Bee 2.8's routing table evicts
prod_bee from homelab's bin-1 when other ff peers appear. Same problem
in reverse — prod has no protection on its homelab connection.
--static-nodes keeps the libp2p connection alive across kademlia churn.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pairs with hosted-gateway commit fcf184b. The api/worker containers now
read /data/pss.key on boot — without a shared volume they'd each get
their own PSS identity per container, which is what was hanging PSS
replies from the provider.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Homelab migrated to a fresh data dir with --target-neighborhood matching
its original swarmOverlay, so its on-chain provider registration stays
valid. Both ends on 2.8 now speak the same v15 handshake protocol; the
prior --bootnode workaround for v14 isolation is no longer needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The default mainnet.ethswarm.org bootnodes all reject Bee 2.7.x's
v14 handshake — prod Bee was stuck at 0 peers. Point --bootnode at
the homelab node, which is the same version and reachable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bee 2.8 changed the swarm handshake protocol; homelab Bee can't move
to 2.8 (silent exit 2 on the existing data dir) so the two nodes
couldn't directly /connect — PSS routing kept failing. Match versions
to restore peering.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bee dashboard reports reachability=Private and underlay only lists
172.x/127.0.0.1 — peers see our node as unreachable, PSS messages
won't route. Setting BEE_NAT_ADDR to the host's public IP+port lets
libp2p autonat confirm reachability.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously a devops push would re-deploy prod-stack against whatever
:main was cached locally on the host, silently reverting recent
frontend/api rolls.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Light nodes can dial the network but PSS delivery requires nodes to
participate as forwarders. Job 0x7355…99fe stayed Pending on-chain
because the provider never received the PSS notify.
Trade-off: full nodes consume more disk + bandwidth and need a funded
chequebook to swap with peers (currently 0 — may need a top-up).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Try the newest version again now that port 1634 is published and the
Hostinger firewall lets inbound through.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.7.1 and 2.8.0 both get rejected by the mainnet bootnodes with
"protocols not supported: [/swarm/handshake/14.0.0/handshake]".
2.7.2-rc1 is the version bee.ffaerber.duckdns.org runs with 25 live
peers, so try that.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per request — don't fall back to the remote Bee. Local prod_bee will
need its peering fixed before /v1/chat/completions can dispatch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Local prod_bee can't peer with the Swarm mainnet (bootnode handshake
mismatch — see prior commits pinning 2.7.1). Remote node at
bee.ffaerber.duckdns.org is 2.7.2-rc1 with 25 live peers + usable
stamps, so PSS dispatch works there. Keeping prod_bee in the stack
for now (idle but harmless) so we can swap back once mainnet bootnodes
are usable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The latest tag (currently 2.8.0) speaks /swarm/handshake/14.0.0 which
the live mainnet bootnodes reject:
protocols not supported: [/swarm/handshake/14.0.0/handshake]
2.7.1 was the last release before the bump. Node stays isolated on 2.8
no matter how many peers it dials, so PSS routing never works.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bee was listening on :1634 inside the container but the swarm service
had no ports: block, so external peers couldn't connect. Outbound-only
peering isn't enough for PSS forwarding.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add `frontend` service running ghcr.io/token-for-token/hosted-gateway-frontend
behind Traefik on t4t-gateway.com + www.t4t-gateway.com. API router drops
the apex hostnames; api.t4t-gateway.com remains the gateway.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Prisma 7 dropped --browser none and hardcodes spawn('xdg-open'). Alpine
doesn't ship xdg-utils, so the spawn ENOENT bubbles to process exit and
the studio task fails after the server has already bound to :5555.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Run `prisma studio` alongside the migrate step so the prod_prisma service
serves the data browser. Behind Traefik basicauth (admin-auth middleware
defined on the traefik service).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Was added to debug the v3 multi-host parse error. Dashboard remains
reachable behind basicauth at traefik.t4t-gateway.com.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bee 2.8's BEE_BLOCKCHAIN_RPC_ENDPOINT env var doesn't bind (chain stays
disabled, node exits with "factory fail: chain disabled"). The CLI flag
works. BEE_CHAIN_ENABLE is also redundant — providing the endpoint
implicitly enables chain.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bee 2.x renamed BEE_SWAP_ENDPOINT to BEE_BLOCKCHAIN_RPC_ENDPOINT. With
the old name, Bee silently disables the chain backend and shuts down
with `factory fail: chain disabled`. Wire the endpoint inline so it
doesn't depend on the host .env.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v3 limits Host() to one parameter; chain with || for multiple. Error
seen in the api@swarm router: "unexpected number of parameters; got 3".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Why: prod_api router triggers ACME (cert issued for api.t4t-gateway.com)
but proxied requests return 404. Need the api endpoint to inspect why.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v3 split the swarm provider out of `--providers.docker.swarmmode`. New
flags use `--providers.swarm.*`. v2.11.22 is well past its EoL.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors cipherdolls/devops layout. Hostinger Swarm stacks for the t4t
hosted-gateway and local docker-compose for development + e2e tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
