トゥルーファウンドリー付きセルフホスト n8n

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
n8nは、視覚的なノードベースのインターフェースを使用して複雑なワークフローを作成できる、強力なオープンソースのワークフロー自動化プラットフォームです。n8nはクラウド版も提供していますが、 n8nをセルフホストすること で、データ、コスト、インスタンスのパフォーマンスを完全に制御できます。
TrueFoundryのデプロイプラットフォームを使えば、簡単に n8nをセルフホストできます 複雑なKubernetes構成に迷うことなく、自身のインフラストラクチャに。このガイドでは、 n8nをセルフホストした インスタンスを稼働させるための、ストレージの設定からアプリケーションのデプロイまでの全プロセスを説明します。
n8nデプロイの前提条件
開始する前に、以下のものがセットアップされていることを確認してください。これらはスムーズなデプロイ体験のために不可欠です。
- TrueFoundryアカウントとクラスター: Kubernetesクラスターに接続されたアクティブなTrueFoundryアカウントが必要です。まだ設定していない場合は、こちらの アカウント設定ガイドをご覧ください。
- TrueFoundry CLI: ターミナルからデプロイするには、TrueFoundryコマンドラインインターフェース(CLI)が必要です。こちらの CLI設定ガイドを使用してインストールおよび設定してください。
- ワークスペース: TrueFoundryでのデプロイはすべてワークスペース内で行われます。新しいワークスペースを作成するか、n8nをデプロイしたいターゲットワークスペースを特定してください。ワークスペースの詳細については、弊社の 主要な概念に関するドキュメント.
なぜn8nをセルフホストするのか?主な利点
クラウドプラットフォームは利便性を提供しますが、n8nインスタンスをセルフホストすることで、本格的な自動化目標を持つ企業にとって不可欠な、新たなレベルのパワー、制御、効率性が解放されます。これは、賃貸スペースから自分自身の工場を所有することへの移行のようなものです。
主な利点は以下の通りです。
完全なデータ主権とセキュリティ
- データのプライバシーを保護する: セルフホストする場合、認証情報、顧客情報、ワークフロー内の独自のビジネスロジックを含む機密データは、自身のインフラストラクチャから外に出ることはありません。
- コンプライアンスに確実に対応する: GDPR、HIPAA、SOC 2のような厳格なデータ規制がある業界では、セルフホストは単なる好みではなく、要件となることがよくあります。これにより、明確で監査可能なデータ処理環境が提供されます。
- セキュリティ体制を管理する: ネットワークポリシーを定義し、アクセス制御を管理し、会社の基準に沿ったセキュリティプロトコルを実装できます。
予測可能なコストと無制限のスケーラビリティ
- 実行ごとの課金から解放される: ワークフローの実行ごとに変動費用を支払う代わりに、コストはプロビジョニングするインフラストラクチャに紐付けられるため、予測可能になり、大規模な運用では大幅に低くなることがよくあります。
- 人為的な制限なし: 階層型クラウドプランによって課される、アクティブなワークフロー数、ユーザー数、実行時間に関する制約を取り除きます。制限されるのは、提供するインフラストラクチャの能力のみです。
比類のないパフォーマンスとカスタマイズ性
- 専用パフォーマンス: n8nインスタンスは専用リソース上で動作します。これにより実行時間が短縮され、「ノイジーネイバー」効果も発生しないため、時間制約のある自動化にとって極めて重要です。
- 完全なカスタマイズ: カスタムコミュニティノードやプライベートな社内ノードをインストールする必要がありますか?セルフホスト型インスタンスを使用すれば、n8n環境を制限なく拡張・カスタマイズできます。
セクション2:n8nをセルフホストする際の一般的な課題
メリットは明らかですが、本番環境に対応したセルフホスト型n8nインスタンスをゼロからセットアップし、管理することは、大きな技術的課題となり得ます。開発者やプラットフォームチームは、急な学習曲線に直面し、いくつかの一般的な障害に遭遇することがよくあります。
1. 複雑なKubernetes構成
- YAMLの煩雑さ: デプロイメント、サービス、イングレス、シークレット用のKubernetes YAMLファイルを手動で作成・保守することは、面倒でエラーが発生しやすい作業です。
- ネットワーキングとイングレス: ネットワークポリシーを適切に構成し、イングレスコントローラーをセットアップし、SSL/TLS証明書を管理してn8nをインターネットに安全に公開することは、複雑なタスクです。
2. 永続データの管理
- ステートフルアプリケーションの課題: ステートフルアプリケーションであるn8nは、ワークフローと認証情報のデータを保存するために永続ボリュームを必要とします。適切に
PersistentVolumeClaimsを構成し、ボリュームが正しくマウントされていることを確認することは難しい場合があります。 - データベース管理: 本番環境での使用には、デフォルトのSQLiteよりもPostgreSQLのような堅牢なデータベースが推奨されます。これにより、デプロイ、管理、セキュリティ保護、接続が必要な別のコンポーネントが追加されます。
3. 本番ワークロードのためのスケーリング
- 単一インスタンスを超えて: 大量のワークフローに対応するためにn8nをスケールアップするには、専用ワーカーを備えたマルチノード設定への移行が必要であり、これにはキュー(Redisなど)の設定、ロードバランサー、高可用性の確保が含まれます。
- 監視とメンテナンス: セルフホスト型インスタンスでは、リソース使用量(CPU/メモリ)を追跡し、稼働時間を確保するために積極的な監視が必要です。n8nの新しいバージョンへのアップグレードも、慎重な手動プロセスを要します。
これらの課題は、貴重なエンジニアリング時間を自動化の構築からインフラ管理へと逸らしてしまうことがよくあります。まさにこのような状況で、合理化されたデプロイプラットフォームが不可欠となります。
Truefoundryを使用してn8nをセルフホストする方法
ステップ1:n8n用の永続ボリュームを作成する
どんな n8nのセルフホスト型 インスタンスは、ワークフロー、認証情報、実行データを保存するために永続ストレージを必要とします。インスタンスが再起動しても、このボリュームによってすべてのデータが安全に保たれます。このボリュームは、TrueFoundry UIまたは当社のPython SDKを使用して作成できます。
オプションA:TrueFoundry UIを使用する
コード不要のアプローチとして、必要なボリュームを当社のウェブインターフェースから直接作成できます。詳細な手順については、当社の ボリューム作成ガイド。
.webp)
オプションB:Pythonデプロイメントを使用する
コードベースで再現可能なセットアップの場合、Pythonスクリプトでボリュームを定義できます。
- という名前のファイルを作成します。
volume_deploy.py。 - 以下のコードを追加します。プレースホルダー値は必ず置き換えてください。
storage_classとworkspace_fqn。
import logging
from truefoundry.deploy import (
DynamicVolumeConfig,
Volume,
)
logging.basicConfig(level=logging.INFO)
# Define the persistent volume for n8n data
volume = Volume(
name="n8n-volume",
# Replace with your cluster's storage class size
config=DynamicVolumeConfig(storage_class="efs-sc", size=2),
workspace_fqn="<your-workspace-fqn>", # Paste your Workspace FQN here
)
# Deploy the volume to your workspace
volume.deploy(workspace_fqn="<your-workspace-fqn>", wait=False)- ターミナルからスクリプトを実行します。
python volume_deploy.pyステップ2:n8nサービスのデプロイ
ストレージボリュームの準備が整ったので、n8nアプリケーション本体をデプロイできます。このサービスはn8nのDockerコンテナを実行し、作成したボリュームに接続します。
- という名前の新規ファイルを作成します
service_deploy.py。 - 以下のコードを貼り付けてください。ただし、
host、volume_fqn、およびworkspace_fqnのプレースホルダーを置き換える必要があります。
import logging
from truefoundry.deploy import (
Image,
VolumeMount,
Service,
Port,
)
logging.basicConfig(level=logging.INFO)
service = Service(
name="n8n-svc",
image=Image(image_uri="docker.n8n.io/n8nio/n8n"),
ports=[
Port(
port=5678,
protocol="TCP",
expose=True,
app_protocol="http",
host="<your-host-name>", # e.g., n8n.your-company.com
)
],
env={}, # Add license keys or other env vars here
mounts=[
VolumeMount(
mount_path="/home/node/.n8n",
volume_fqn="<your-volume-fqn>", # Paste the FQN of the volume from Step 1
)
],
workspace_fqn="<your-workspace-fqn>", # Paste your Workspace FQN here
)
service.deploy(workspace_fqn="<your-workspace-fqn>", wait=False)設定に関する注意点:
host:n8nにアクセスするための公開URLです。利用可能なホストドメインは、以下の ポートとドメインに関するガイド。ボリューム_ファン: これはステップ 1 で作成したボリュームの完全修飾名です。これは TrueFoundry ダッシュボードのボリュームのページで確認できます。ワークスペース_ファン: サービスをデプロイするワークスペースのFQN。
- スクリプトを実行して n8n サービスをデプロイします。
python service_deploy.py
ステップ 3: n8n インスタンスにアクセスする
デプロイが完了したら、で設定したホスト URL に移動します。 service_deploy.py ファイル。n8n のセットアップ画面が表示されます。
次のことができるようになりました。
- パワフルなワークフロー自動化を実現しましょう。
- 何百もの異なるサービスや API に接続できます。
- 複雑なデータ処理パイプラインを構築します。
- ジョブのスケジュールされたタスクとトリガーを設定します。
.webp)
これで、n8n インスタンスが完全に動作し、永続ストレージを備えた独自のインフラストラクチャで実行されるようになりました。これにより、再起動後もワークフローと認証情報が保持されます。
n8n エンタープライズ機能のロック解除
このガイドでは、n8n のコミュニティエディションをデプロイします。Enterprise ライセンスをお持ちの場合は、にライセンスキーを追加することで追加機能をアンロックできます。 うらやましい の辞書 service_deploy.py ファイル。
環境変数の詳細については、 n8n 公式ドキュメンテーション。
トラブルシューティング
問題が発生した場合は、まず次の点を確認してください。
- ストレージクラスが無効です: 以下を確認してください
ストレージクラスで指定したのはvolume_deploy.pyは利用可能で、クラスターと互換性があります。 - FQN が正しくありません: 次のことを再確認してください
ワークスペース_ファンそしてボリューム_ファン値は正しく、タイプミスが含まれていません。 - デプロイログ: デプロイが失敗した場合は、TrueFoundry ダッシュボードのサービスログで詳細なエラーメッセージを確認してください。
結論
おめでとう!次の方法を正常に学習しました セルフホスト n8n トゥルーファウンドリーを使用しています。これ n8nセルフホスト セットアップは、ワークフローとデータを完全に制御できるだけでなく、すべての自動化ニーズに対応するスケーラブルで堅牢な基盤を提供します。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI












.webp)




.png)








.webp)
.webp)








