Self-Hosting n8n on GCP: Production-Ready Multi-Environment Setup

Introduction

n8n is one of those tools that starts out simple, spin it up, build a few workflows, ship it. But once multiple people are building automations (and you care about staging, approvals, and not breaking production), you need a setup that's a bit more structured.

In this article, We'll walk through a clean way to host n8n on Google Cloud with separate dev/beta/prod environments, queue mode for production readiness, and a Git-based workflow promotion flow that keeps changes predictable.

Plan

We'll host n8n on a GKE Autopilot cluster. It's a nice sweet spot: you get Kubernetes flexibility without having to babysit nodes. And if you're aiming for something lighter, the same overall idea can work on Cloud Run too, the building blocks don't really change, you just swap the runtime.

We're also running n8n in queue mode, which is the go-to setup for production because it separates the "UI/API side" from the "job execution side" (so things scale and behave more predictably).

As illustrated below, we run this as three separate environments:

• dev — a playground for workflow builders to experiment and iterate
• beta — a staging space for testing and validation
• prod — the real production environment

To keep workflow promotion clean, we use n8n's Version Control with Git feature (available on the Business and Enterprise plans). Each environment maps to its own GitHub branch.

How changes move through environments

Dev is push-only.
Workflow developers build and tweak workflows directly in the n8n UI. When something's ready to move forward, they push those workflows to GitHub straight from n8n. No extra steps, no copy-pasting between environments.

Once the changes land on the dev branch, the team opens a pull request to the beta branch. That PR is where a project admin can review what's changing and approve it.

Beta is pull-only.
The beta environment doesn't accept manual edits as the source of truth — it only pulls from GitHub. So once the PR is merged, beta syncs and you can test in a controlled, repeatable way.

After validation, workflow developers open another PR from beta → main. That one is typically the "final gate", where the n8n admin gives the go-ahead.

Prod is pull-only too.
Just like beta, production only pulls from GitHub. When the beta → main PR is merged, production syncs from main — and that's how changes make it to prod without anyone directly "click-editing" workflows in the live environment.

GCP Architecture

As illustrated above, the whole setup is basically "one private network, one Kubernetes cluster, three separate environments".

Everything sits inside a dedicated VPC (private network). That VPC is where we keep the cluster and all the supporting services so they can talk to each other without being exposed to the public internet.

Private GKE Autopilot cluster (where n8n runs)

n8n itself runs on a GKE Autopilot cluster, and we keep it private. In practice, that just means we're not putting the cluster nodes out on the internet, we treat the cluster like an internal runtime and only expose what we actually need.

Inside that single cluster, we split the three environments using Kubernetes namespaces:

• development namespace → dev.n8n.example
• beta namespace → beta.n8n.example
• production namespace → n8n.example

Each namespace has the same basic shape:

• Main n8n component (the UI + API side)
• Workers component (the queue workers that actually execute jobs)

This keeps the environments cleanly separated, while still letting you manage everything in one place.

How users reach n8n

Traffic comes in through a GCP Load Balancer (shown as the "Cluster Gateway" in the diagram). That acts as the front door. It's the one public-facing piece, and it routes requests to the right environment based on the hostname (dev/beta/prod).

So from the user's point of view, it feels like three independent n8n instances but behind the scenes they're just three neatly separated lanes inside the same cluster.

Secrets and config

Sensitive values (credentials, encryption keys, etc.) are stored in Secret Manager. The cluster pulls what it needs from there, so secrets don't end up scattered across random places or hardcoded into configs.

Data services: Postgres + Redis

n8n needs reliable persistence and (in queue mode) a queue backend:

• Cloud SQL (PostgreSQL) is used as the main database for n8n data (workflows, executions, credentials metadata, and so on).
• Redis handles the queueing layer that makes the whole "Main + Workers" setup work smoothly.

Both of these sit alongside the cluster in the same overall GCP environment so the traffic stays internal and predictable.

Outbound traffic and network controls

Because the cluster is private, when workloads need to reach the outside world (calling third-party APIs, webhooks, SaaS tools, etc.), outbound traffic goes through Cloud NAT. That gives you controlled egress without turning the cluster into something publicly exposed.

On top of that, firewall rules act as the final guardrails — only the paths you expect are open, and everything else is locked down by default.

Overall, the idea is: one private GCP network, a private Autopilot cluster running three isolated namespaces, managed data services for reliability, and a load balancer as the single public entry point. It stays tidy, secure, and it scales without you babysitting infrastructure.

Outro

To wrap up, this approach keeps n8n deployments clean and predictable: environments are separated, execution runs reliably in queue mode, and workflow changes move through a reviewable Git-based promotion process instead of ad-hoc UI edits in production.

If you want to see how Codimite helps teams run n8n in a secure, production-ready way, you can check this out: https://codimite.ai/n8n-self-hosted-service/