RevampITは現在、revampit.orangecat.chのもと、Hetzner上でセルフホストアプリとして稼働しています。公開ドメインrevamp-it.chはまだ古いJoomla/Apacheのサイトを指しているため、新しいプラットフォームの本番ターゲットではありません。
自然と浮かぶ問いはこうでした。Coolify、Dokploy、あるいは他のPlatform-as-a-Service層が必要なのか、と。現時点での私たちの答えはノーです。そうしたツールが悪いからではなく、それらが最初の問題を解決しないからです。
本当の問題はもっとシンプルです。デプロイは再現可能でなければならず、明確な品質ゲートを持ち、エラー時にはロールバックし、今どのバージョンが稼働しているかを可視化しなければなりません。これらの特性は、既存のCaddy、systemd、rsyncの構造が、同じ本番サーバー上に新しいControl Planeを載せることなく、直接手に入れられるものです。
だからこそ、私たちはまず既存の経路を強化します。デプロイスクリプトは引き続きNext.jsのstandalone成果物をビルドし、Hetznerサーバーにコピーし、サービスを再起動します。新しいのは、アクティブ化の前に以前のリリースが保持されることです。サービスがアクティブにならない場合や、/api/healthが成功ステータスを返さない場合、自動的にロールバックされます。
加えて/api/versionエンドポイントがあります。これはアプリバージョン、Git-SHA、ビルド時刻を表示します。小さなことですが重要です。運用とモニタリングは、実際に何がライブで稼働しているかという問いへの明確な答えを必要とします。
その際、一つの細部が決定的でした。.envやlaunch.shのようなランタイムファイルはGitリポジトリに属しませんが、アクティブ化されるすべてのリリースに存在しなければなりません。そのためデプロイスクリプトは、新しいリリースを起動する前に、現在のアプリディレクトリからこれらのファイルをサーバーローカルに引き継ぎます。
Meilisearchも今や再び運用像の一部です。アプリはMeilisearchなしでSQL検索にフォールバックできましたが、それによって/api/healthはdegradedにとどまっていました。そのためHetznerサーバー上では、Meilisearchはサーバーローカルの鍵を持つlocalhost専用のDockerサービスとして稼働します。
GitHubのデプロイワークフローには、さらに明確なゲートが加わります。LintとTypecheckが本番デプロイの前に走ります。ローカルのpushデプロイは便利なままですが、長期的に唯一の真実であるべきではありません。目標とする状態はこうです。GitHubがビルドし、検証し、デプロイする。ローカルのデプロイは例外的なケースのための手動ツールにとどまる、と。
後から来るかもしれないもの。多くのアプリ、顧客環境、あるいはセルフサービスのデプロイを運用するようになれば、Control Planeが妥当になり得ます。そのときは冷静にCoolify、Dokploy、Kamalを検討します。それまでの原則はこうです。プラットフォームは少なく、信頼できる運用規律を多く、です。
