8️⃣
n8n on Cloud Run （ツール比較から選定まで）

2025/04/08に公開
 はじめにこんにちは！日々の業務や個人開発で、繰り返し行う作業や複数のサービス間でのデータ連携に「もっと楽にならないかな？」と感じることはありませんか？私もその一人で、ワークフロー自動化ツールの導入を検討し始めました。
世の中にはZapierやIFTTTといったSaaS型の有名なツールがありますが、今回はオープンソースでセルフホストも可能な選択肢を中心に比較検討しました。この記事では、まず私がなぜ n8n を選んだのか、その理由を説明します。そして後半では、選定したn8nを Terraform を使用して Cloud Run 上に構築した際の具体的な手順や構成について解説します。

 候補となったツールたち
 候補となったツールたち今回、ワークフロー自動化やそれに類する機能を持つオープンソースツールとして、以下のようなものを比較検討しました。

n8n (GitHub): ノードベースのビジュアルインターフェースが特徴的な、人気のワークフロー自動化ツール。

Activepieces (GitHub): n8nやZapierライクなUIを持つ、比較的新しいオープンソースの自動化ツール。

Windmill (GitHub): スクリプト実行とローコードUI構築を組み合わせた、開発者向けのプラットフォーム。

Huginn (GitHub): 特定のWebサイトの変更監視やイベント駆動型のタスク実行に特化したシステム。

Dify (GitHub): LLMアプリケーションの開発に特化したプラットフォーム。ワークフロー機能も持つ。
どれも魅力的なツールでしたが、私の今回の要件は、より汎用的なサービス間連携の自動化でした。

 n8nを選んだ理由様々なツールを比較する中で、最終的にn8nを選んだ理由は、主に以下の2点です。

 理由1：圧倒的な外部接続（インテグレーション）の豊富さn8nの最大の魅力の一つは、連携できるサービスやツールの数が非常に多いことです。公式サイトを見ると、多くのアプリケーション、データベース、汎用プロトコル（HTTP Request, Webhookなど）に対応したノードが標準で提供されています。
私が自動化したかったワークフローでは、複数のWeb API、データベース、そしてコミュニケーションツールなどを連携させる必要がありました。n8nのインテグレーションリストを確認したところ、必要としていたサービスの多くが標準ノードとして用意されており、複雑なコーディングなしに連携を実現できる見通しが立ちました。もし標準ノードがない場合でも、拡張性の高さも安心材料でした。

 理由2：Supabaseとの連携が標準で可能だったこと【決め手】そして、今回のツール選定における最終的な決め手となったのが、Supabaseとの連携です。

私はバックエンドサービスとしてSupabaseを頻繁に利用しており、ワークフローの中でSupabaseデータベースのデータを読み書きしたりしたいと考えていました。
n8nには、標準でSupabaseノードが用意されています。
これにより、認証情報などを設定するだけで、データベース操作をワークフローに簡単に組み込めます。他のツールでもAPI経由で操作は可能ですが、専用ノードがあることで開発効率が格段に向上すると考えました。

 理由3：セルフホスティングによる拡張性の高さ（npmライブラリ利用）n8nの大きな特徴の一つに、セルフホスティングが可能な点が挙げられます。これが、技術的な拡張性を求める上で重要なポイントとなりました。
n8nでは、「Function」ノードや「Function Item」ノードを使ってJavaScriptでカスタム処理を記述できますが、より複雑な処理を行いたい場合、外部の npm ライブラリ を利用したくなることがあります。
セルフホスト環境であれば、環境変数 (NODE_FUNCTION_ALLOW_EXTERNAL) を設定することで、任意の外部 npm ライブラリを n8n のカスタムコード内で require して利用することが可能になります。 これにより、標準機能だけでは実現が難しい高度なデータ処理や、特定のライブラリに依存する機能などをワークフローに組み込む自由度が格段に高まります。
クラウド版の n8n では、セキュリティや環境管理の都合上、このような外部ライブラリの自由な追加は制限されているか、特定のプランでのみ可能となる場合があります。そのため、npm ライブラリを積極的に活用したい、あるいはその可能性を残しておきたいという要件がある場合、セルフホスティングは非常に有力な選択肢となります。この拡張性の高さも、n8nを選定する後押しとなりました。

 n8n環境の構築：Terraform on GCP Cloud Runさて、利用するツールとしてn8nを選定した後、次は実際にn8nを動かす環境を構築するフェーズです。n8nはセルフホスティングが可能であり、今回はその選択肢を取りました。
構築先としては、スケーラビリティや運用負荷の低減を考慮し、Google Cloud の Cloud Run を選択しました。さらに、インフラ構成をコードで管理し、再現性や変更管理を容易にするために Terraform を採用することにしました。
ここからは、Terraformを使用してCloud Run上にn8n環境を構築した際の具体的な設定内容や手順について解説します。

 Terraform構築の概要この記事で紹介するTerraform構成では、Cloud Run上にn8nアプリケーションをデプロイします。データベースにはCloud SQL for PostgreSQLを使用し、ネットワークはVPCで分離、機密情報はSecret Managerで管理します。これにより、セキュアでスケーラブルなn8n実行環境をコードで構築・管理することを目指します。

 アーキテクチャこのインフラストラクチャは以下のGCPサービスを使用します：

Cloud Run: n8nアプリケーションのホスティング

Cloud SQL: PostgreSQLデータベース (データ永続化)

VPC Network: Cloud RunとCloud SQL間のプライベート接続

VPC Access Connector: Cloud RunからVPCリソースへのアクセス

Cloud NAT: Cloud Runから外部へのアウトバウンド接続 (必要な場合)

Secret Manager: データベースパスワードやn8n暗号化キーなどの機密情報管理

 前提条件以下の準備が整っていることを前提とします。
GCPアカウントと、課金が有効なプロジェクト
ローカル環境へのTerraformのインストール
GCPプロジェクトに対する適切な権限を持つサービスアカウントキー、または gcloud auth application-default login による認証設定

 Terraformコードの構成例管理しやすいように、コードをモジュール化し、環境ごとに設定を分けられる構成を推奨します。
gcp/
├── modules/
│   └── n8n/
│       ├── cloudrun.tf      # Cloud Runサービス定義
│       ├── database.tf      # Cloud SQL設定
│       ├── network.tf       # VPCネットワーク関連設定
│       ├── secrets.tf       # Secret Manager設定
│       ├── outputs.tf       # モジュール出力
│       └── variables.tf     # モジュール内変数定義
├── environments/
│   └── dev/               # 開発環境用設定
│       ├── main.tf
│       └── terraform.tfvars
│   └── prod/              # 本番環境用設定
│       ├── main.tf
│       └── terraform.tfvars
├── README.md
├── variable.tf # gcp内変数定義
├── provider.tf
└── main.tf # backendの記述もある



 主要なリソース設定Terraformで定義する主要なGCPリソースの設定例です。

 ネットワーク構成n8nの実行環境は、セキュアな通信を確保するために以下のようなネットワーク構成を採用しています
# VPCネットワーク
resource "google_compute_network" "vpc" {
  name                    = "n8n-network"
  auto_create_subnetworks = false
}

# Cloud Run用のVPCコネクタ
resource "google_vpc_access_connector" "connector" {
  name          = "n8n-vpc-connector"
  region        = var.region
  network       = google_compute_network.vpc.id
  ip_cidr_range = "10.0.1.0/28"
  machine_type  = "e2-micro"
  min_instances = 2
  max_instances = 10
}

# 外部接続用のNAT設定
resource "google_compute_router_nat" "nat" {
  name                               = "n8n-nat-gateway"
  router                             = google_compute_router.router.name
  region                             = var.region
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}
この設定により：
プライベートなVPCネットワーク内でn8nを実行
Cloud SQLとの安全な接続
必要な外部APIへのアクセスをNATゲートウェイ経由で実現

 Cloud RunCloud Runサービスは以下の主要な設定を含みます
resource "google_cloud_run_service" "n8n" {
  name     = var.service_name
  location = var.region

  template {
    spec {
      containers {
        image = "n8nio/n8n:${var.n8n_version}"
        
        resources {
          limits = {
            cpu    = var.container_cpu
            memory = var.container_memory
          }
        }
        
        # 環境変数の設定
        env {
          name  = "DB_TYPE"
          value = "postgresdb"
        }
        
        # その他必要な環境変数...
      }
    }
  }
}

 データベース（Cloud SQL）n8nのデータを永続化するために、Cloud SQL for PostgreSQLを使用します
# PostgreSQLインスタンス
resource "google_sql_database_instance" "instance" {
  name                = "${var.database_instance_name}-${var.environment}"
  database_version    = "POSTGRES_14"
  region              = var.region

  settings {
    tier = var.database_tier
    
    backup_configuration {
      enabled = true
    }

    ip_configuration {
      ipv4_enabled    = false
      private_network = google_compute_network.vpc.id
    }
  }
}

# n8n用データベースとユーザーの作成
resource "google_sql_database" "database" {
  name     = var.database_name
  instance = google_sql_database_instance.instance.name
}

resource "google_sql_user" "user" {
  name     = var.database_user
  instance = google_sql_database_instance.instance.name
  password = var.database_password
}
この設定のポイント：
PostgreSQL 14を使用
プライベートIPのみを有効化し、パブリックアクセスを無効化
自動バックアップを有効化
環境ごとに異なるインスタンス名を使用

 シークレット管理n8nの運用に必要な機密情報は、Google Cloud Secret Managerで管理します
# データベースパスワード
resource "google_secret_manager_secret" "db_password" {
  secret_id = "n8n-db-password"

  replication {
    user_managed {
      replicas {
        location = var.region
      }
    }
  }
}

# n8n暗号化キー
resource "google_secret_manager_secret" "encryption_key" {
  secret_id = "n8n-encryption-key"

  replication {
    user_managed {
      replicas {
        location = var.region
      }
    }
  }
}

# 暗号化キーの自動生成（未指定の場合）
resource "random_password" "encryption_key" {
  count            = var.n8n_encryption_key == "" ? 1 : 0
  length           = 32
  special          = true
  override_special = "!@#$%&*()-_=+[]{}<>:?"
}
管理される機密情報：
データベースパスワード
n8nワークフローの暗号化キー（自動生成オプションあり）
これらのシークレットは、Cloud Run上のn8nアプリケーションから安全に参照されます。

 環境変数の設定n8nの実行に必要な環境変数は以下のように設定されます
env {
  name  = "DB_TYPE"
  value = "postgresdb"
}

env {
  name  = "DB_POSTGRESDB_HOST"
  value = local.database_connection.host
}

env {
  name = "DB_POSTGRESDB_PASSWORD"
  value_from {
    secret_key_ref {
      name = google_secret_manager_secret.db_password.secret_id
      key  = "1"
    }
  }
}

env {
  name = "N8N_ENCRYPTION_KEY"
  value_from {
    secret_key_ref {
      name = google_secret_manager_secret.encryption_key.secret_id
      key  = "1"
    }
  }
}

 まとめこの記事では、ワークフロー自動化ツールとして n8n を選定した具体的な理由と、そのn8n環境を Terraform を用いて GCP Cloud Run 上に構築する実践的な方法について解説しました。
振り返ると、n8nを選んだ決め手は、数百に及ぶ豊富な外部サービス連携と、特に私が利用していた Supabase との標準連携が可能であった点です。これにより、多様なサービスを組み合わせたワークフローを、視覚的なインターフェースで効率的に構築できる見込みが立ちました。
実際に環境を構築するにあたっては、GCP Cloud Run のスケーラビリティと運用負荷の低さ、そして Terraform によるInfrastructure as Code (IaC) のメリットを活かす構成を選択しました。VPCによるネットワーク分離、Cloud SQLによるデータベースの永続化、Secret Managerによる機密情報管理を組み合わせることで、セキュアかつスケーラブルなn8n実行環境をコードベースで管理できるようになりました。Terraformを利用することで、環境の再現性が保証され、将来的な変更や拡張も容易に行える基盤が整ったことは大きな利点です。

 n8nのライセンスと商用プランについてn8nはソースコードが公開されているオープンソースプロジェクトであり、セルフホスティング（自身でサーバーにインストールして運用）が可能です。基本的な機能はセルフホスト版（コミュニティ版）でも十分に利用でき、強力な自動化を実現できます。
一方で、n8nはビジネス向けの有料プランも提供しています。

より高度な機能（例: シングルサインオン(SSO)、監査ログ、ロールベースアクセス制御(RBAC)、エンタープライズレベルのサポートなど）が必要な場合や、n8nが提供するマネージドなクラウドサービスを利用したい場合は、Starter, Pro, Enterprise といった商用プランの検討をおすすめします。
セルフホスト版の利用においても、特定の条件下での利用や大規模な商用利用を検討される際には、ライセンス規約を確認することが重要です。詳細なプラン内容や価格、ライセンスに関する情報は、以下の公式サイトで確認できます。

n8n Pricing: https://n8n.io/pricing/

 Cloud Run で動かしている一部成果物の紹介lineのwebhookをn8nから受け取ることができることを確認しました！

 最後にTerraformによるIaCの実践は、環境構築の初期コストはかかるものの、長期的な運用保守性やガバナンスの観点から大きなメリットをもたらします。今回構築した環境をベースに、今後様々な業務プロセスの自動化を進め、開発効率の向上やヒューマンエラーの削減に繋げていきたいと考えています。
この記事が、ワークフロー自動化ツールの選定や、n8nのセキュアな実行環境構築を検討されている方にとって、少しでも参考になれば幸いです。
はじめに

候補となったツールたち

候補となったツールたち

n8nを選んだ理由

理由1：圧倒的な外部接続（インテグレーション）の豊富さ

理由2：Supabaseとの連携が標準で可能だったこと【決め手】

理由3：セルフホスティングによる拡張性の高さ（npmライブラリ利用）

n8n環境の構築：Terraform on GCP Cloud Run

Terraform構築の概要

アーキテクチャ

前提条件

Terraformコードの構成例

主要なリソース設定

ネットワーク構成

Cloud Run

データベース（Cloud SQL）

シークレット管理

環境変数の設定

まとめ

n8nのライセンスと商用プランについて

Cloud Run で動かしている一部成果物の紹介

最後に

Discussion
