2026年のWindmillセルフホスト：Worker、PostgreSQL、分離、安全な更新
ベンダー文書を運用統制、移行判断、検証可能なリリース基準へ落とし込む、プロダクション志向の最新フォローアップです。
2026年に変わったこと
運用上の境界条件が変化したため、このテーマを改めて検討します。長期的に有効な原則は残る一方、現行バージョンでは過去の近道が不十分、あるいは危険になっている場合があります。本稿は2026年7月14日時点で入手できる公式文書を起点に、事実とローカルな判断を分け、設定変更をすべて管理された本番介入として扱います。
最新の一次資料
この更新版の使い方
まず一次資料を確認し、実際に稼働しているバージョンを記録し、設定を変える前に観測可能な成果を定義します。代表性のある環境で、最小かつ元に戻せる変更を試します。コマンドが成功しただけでは受け入れ基準を満たしません。サービスの健全性、データ完全性、レイテンシー、セキュリティ境界、ロールバック時間まで確認します。旧稿の診断手順で現在も有効な部分は運用基盤として残しますが、バージョン依存の例は必ず現行文書と照合します。
リリース前に、設定差分、少なくとも一度は復元確認を行ったバックアップまたはスナップショット、変更を戻すためのコマンドを記録します。最初の本番監視を担当する人と、指標が悪化した場合にエスカレーションを承認する人を分けます。アラートは発報した部品名だけでなく、利用者に見えるリスクを説明する必要があります。確認期間には、エラー率、キュー深度、リソース飽和、処理レイテンシー、データ完全性を合意したベースラインと比較します。平均値が安定していても、少数ながら重要な処理の失敗を隠すことがあるため、裾の挙動も確認します。遅延ジョブ、再試行、定期処理、下流エクスポートが完了するまで変更をクローズしません。復旧時の手作業はすべて記録し、ランブックにない救済手順があれば、ランブックは未完成と判断します。
- セルフホスティングの決定：SaaS が自社インフラより高くつく場合
- セルフホスティングサービスのディザスタリカバリー：バックアップ戦略
- 単一サーバーで複数のデータベースインスタンスをセルフホスティングする
運用の基盤
ワークフロー自動化プラットフォームは現代の開発チームに不可欠ですが、Windmill Cloudのようなクラウドソリューションは使用量の増加に伴いコストが高くなる可能性があります。Docker ComposeとTraefik統合を使用してUbuntu上に独自のWindmillインスタンスをセットアップする方法を、インストールを妨げる可能性のある重大なPostgreSQL認証の問題を克服しながらご紹介いたします。
構築するもの
このチュートリアルの終わりには、以下が構築されます：
- HTTPS付きの完全に機能するWindmillインストール
- Traefik経由のLet’s Encryptによる自動SSL証明書
- 適切な認証を備えた本番対応のPostgreSQLデータベース
- リソース最適化されたワーカー設定
- 既存のDockerインフラとの統合
- プロフェッショナルなワークフロー自動化のための本番対応セットアップ
月額コスト： 4.51ユーロ（CX11サーバー）+ ドメインコスト – 複数の自動化ツールを処理できる同一のインフラ
前提条件
- DockerとDocker Composeがインストールされた Ubuntu 24.04 LTSサーバー
- 既存のTraefikリバースプロキシセットアップ（Traefik設定についてはn8nセットアップガイドをご参照ください）
- サーバーIPに向けられたドメイン名
- 最低4GB RAMと2 vCPUを推奨
- SSHアクセスと基本的なコマンドラインの知識
Windmillの理解
Windmillは以下を提供するオープンソースのワークフローエンジンです：
- TypeScript/Python/Goサポート付きのビジュアルワークフローエディター
- ジョブスケジューリングと実行管理
- API統合機能
- チームコラボレーション機能
- 使用制限のないセルフホスティング対応
n8nのノードベースのアプローチとは異なり、Windmillは強力な開発環境を備えたコードファーストのワークフローに焦点を当てています。
ステップ1：サーバーの準備とディレクトリ構造
まず、サーバー環境を準備します。競合を避けるために、Windmillインスタンスには食べ物に基づく命名規則を使用します：
命名規則： 複数のWindmillインスタンスにはシンプルな食べ物の名前を使用します：
- 最初のインスタンス：pizza
- 追加インスタンス：pasta、salad、soup、burgerなど
- 競合を回避し、管理を容易にします
ステップ2：環境設定
適切な認証情報を含む安全な環境ファイルを作成します：
重要： windmill.yourdomain.comを実際のドメインに置き換えてください。
ステップ3：Docker Compose設定
メインのDocker Compose設定を作成します：
重要： Traefikラベルのドメインをお客様のセットアップに合わせて更新してください。
ステップ4：PostgreSQLパスワード問題（重大な問題）
ここが、ほとんどのWindmillインストールが失敗するポイントであり、根本原因の特定にはかなりのトラブルシューティングが必要でした：
問題：パスワード内の特殊文字
openssl rand -base64 32を使用してパスワードを生成すると、=、@、#、%などの特殊文字が含まれることがよくあります。これらの文字は、適切にエスケープされていても、Docker環境でPostgreSQL認証の失敗を引き起こします。
問題のあるパスワードの例：
解決策：16進数のみのパスワード
特殊文字を含まない16進数のみのパスワードを使用します：
追加のPostgreSQL設定の問題
- ユーザー設定：windmill_userのようなカスタムユーザーではなく、デフォルトユーザーとしてpostgresを使用
- ボリュームの永続性：既存のデータボリュームに異なる認証情報が含まれている場合、PostgreSQLはPOSTGRES_PASSWORD環境変数を無視
- URLフォーマット：Docker環境ではデータベースURLに?sslmode=disableを含める
ステップ5：インストールと起動
修正された設定でWindmillをインストールします：
以下のような出力が表示されるはずです：
ステップ6：よくある問題のトラブルシューティング
問題1：PostgreSQL認証の失敗
症状：
解決策：
問題2：コンテナが起動しない
症状：
- コンテナが即座に終了
- リソース割り当てエラー
解決策：
問題3：SSL証明書の問題
症状：
- HTTPSが機能しない
- 証明書エラー
解決策：
ステップ7：アクセスと初期セットアップ
インストールが完了したら：
- Windmillにアクセス：https://windmill.yourdomain.com
- デフォルト認証情報：
- パスワード：changeme
- セットアップを完了：
管理者パスワードを変更
- ベースURLを設定
- ユーザーアカウントをセットアップ
ステップ8：リソース最適化
メモリ割り当て（8GBサーバーの場合）
当社の設定では、リソースを効率的に割り当てます：
- Windmillサーバー：約800MB
- Windmillワーカー：2GB（制限付き）
- PostgreSQL：約500MB
- システム予約：約4.7GB
CPU割り当て（4 vCPUサーバーの場合）
- ワーカー：1 vCPU（制限付き）
- その他のサービス：3 vCPU（共有）
スケーリングルール： vCPUあたり1ワーカー、各1〜2GB RAM
ステップ9：本番環境の堅牢化
バックアップスクリプトの作成
監視のセットアップ
自動アップデートの設定
ステップ10：高度な設定
既存SMTPとの統合
メールサーバーがある場合（当社のn8nセットアップのように）、統合します：
複数のWindmillインスタンス
隔離された環境を必要とするチーム向け：
セキュリティの考慮事項
ネットワーク分離
- PostgreSQLはDockerネットワーク内からのみアクセス可能
- 外部データベースポートの公開なし
- TraefikレベルでのHTTPS終端
リソース制限
- ワーカーコンテナにCPUとメモリの制限あり
- リソース枯渇攻撃を防止
- サーバー容量に基づいて設定可能
SSLセキュリティ
- Let’s Encrypt証明書の自動取得
- HTTPからHTTPSへのリダイレクト
- 最新のTLS設定
監視とメンテナンス
週次ヘルスチェック
月次メンテナンス
コスト内訳と比較
月額コスト
セルフホスティングセットアップ：
- Hetzner CX21（4GB RAM）：月額8.46ユーロ
- ドメインコスト：約月額1ユーロ
- 合計：約月額9.50ユーロ
Windmill Cloudとの比較：
- チームプラン：ユーザーあたり月額30ドル
- 節約額：小規模チームで年間250ドル以上
パフォーマンスのメリット
セルフホスティングの利点：
- 無制限のワークフロー実行
- 外部レート制限なし
- 完全なデータ制御
- カスタム統合
- リソーススケーリングの柔軟性
トラブルシューティングリファレンス
クイック診断
よくあるエラーパターン
- “password authentication failed” → 16進数パスワードを使用し、ボリュームをクリア
- “connection refused” → ネットワーク設定を確認
- “certificate errors” → DNSとTraefikセットアップを検証
- “out of memory” → ワーカーのリソース制限を調整
Windmillインフラのスケーリング
水平スケーリング
大量処理環境向け：
垂直スケーリング
サーバーリソースをアップグレード：
- CX31（8GB RAM）：重いワークロード向けに月額16.07ユーロ
- CX41（16GB RAM）：エンタープライズ使用向けに月額29.75ユーロ
既存インフラとの統合
n8nとの連携
すでにn8nを実行している場合（当社の以前のチュートリアルから）：
- Windmillはコードファーストのワークフローを処理
- n8nはビジュアルでシンプルな自動化を処理
- 両方が同じTraefikプロキシを共有
- 別々のデータベースで競合を防止
共有サービス
既存のインフラを活用：
- Traefik：すべてのサービスのSSLを処理
- メールサーバー：通知用の共有SMTP
- 監視：統一されたログとメトリクス
- バックアップ：一元化されたバックアップ戦略
まとめ
Windmillのセルフホスティングは、クラウドホスティングコストのごく一部でエンタープライズグレードのワークフロー自動化を提供します。成功の鍵は、PostgreSQLの認証要件を理解し、インストールを妨げる可能性のある特殊文字の問題を回避するために16進数のみのパスワードを使用することです。
このセットアップの主な利点
- コスト効率：クラウドソリューションと比較して年間数百ドルを節約
- 本番対応：エンタープライズワークロードを確実に処理
- 安全：HTTPS、隔離されたネットワーク、リソース制限
- スケーラブル：必要に応じてワーカーとリソースを簡単に追加
- プライベート：コードとデータがインフラの外に出ることはない
この設定は本番環境でテスト済みであり、ビジネスクリティカルなワークフロー自動化に必要な信頼性を提供します。トラブルシューティングの手順は、デプロイメント中に遭遇した実際の問題、特に多くのセルフホスティングインストールに影響するPostgreSQL認証の問題に対処しています。
複雑なワークフロー要件やエンタープライズデプロイメントの場合は、特定のユースケースを最適化し、最適なリソース配分を確保するためにプロフェッショナルなコンサルテーションをご検討ください。
次のステップ
- Windmillにも適用できるWebhookトラブルシューティング技術を探求
- 大規模データセットの処理のためのペイロード最適化をレビュー
- 既存のn8nインストールとの統合を検討
tvaについて
tvaは、データベースシステム、クラウド環境、グローバルサプライチェーンの包括的なインフラ管理を担っています。当社の体系的なアプローチは、厳格なセキュリティプロトコルとパフォーマンス最適化を組み合わせ、戦略的アドバイザリーサービスによりデジタル能力と物理的資産の両方の精密な調整を可能にし、すべてのエンゲージメントにおいて最高水準の運営卓越性とコンプライアンスを維持しています。
当社のサービスおよび追加の自動化チュートリアルの詳細については、 tva.sg をご覧ください。
設定作業から運用判断へ
重要なのは、プラットフォームを設定できるかどうかではありません。担当範囲を説明し、ドリフトを検出し、場当たり的な対応なしに復旧し、狙った効果を証明できることが必要です。そのため各変更に、責任者、ベースライン、ロールバック手順、確認期間を結び付けます。単発の修正を、再現可能な運用能力へ変えるためです。 同じ記録が次の担当者に信頼できる出発点を与え、その後の最適化を新たな推測ではなく、計測に基づく判断へ変えます。