How do agencies onboard multiple clients for Google OAuth on a self-hosted n8n instance?

Feedback General
1

N/A

Describe the problem/error/question

Hi everyone,
I have a self-hosted n8n instance where I manage automation workflows for multiple clients.
I’m curious how agencies handle Google OAuth onboarding for Google Calendar and Google Sheets in production.

  • Do you give clients temporary remote access (AnyDesk, RustDesk, Zoom, etc.) so they can click “Sign in with Google” and authorize their own account?
  • Or do you give clients access to the n8n editor to connect their credentials themselves?
  • If you give editor access, how do you do that securely when a single n8n instance contains workflows for many different clients? How do you prevent clients from seeing other clients’ workflows?
  • Or do you use a completely different approach?
    I’m looking for real production workflows used by agencies managing multiple clients on a single self-hosted n8n instance.
    Thanks!

What is the error message (if any)?

N/A

Please share your workflow

N/A (This is an architecture and best-practice question.)

Share the output returned by the last node

n8n version: Latest stable
Database: PostgreSQL
n8n EXECUTIONS_PROCESS: own
Running n8n via: Docker (Self-hosted)
Operating system: Ubuntu 24.04 LTS

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
1 curtida
2

Most agencies tend to avoid giving clients access to the n8n editor as it is too easy to expose other clients’ workflows or credentials even with the use of folders. A common pattern is one Docker container per client so there is no shared instance to keep secure in the first place.

For the OAuth flow itself skip the screen sharing entirely and spin up a tiny external consent page. This runs Google’s OAuth flow, grabs the refresh token and pushes it into the client’s credential via the n8n API. The client will authorize their own account and never touch your editor.

3

Keep in mind you need a license to be allowed to do this.

4

The external consent page pattern @AnthonyAtXRay describes is the right call. The technical flow for that: build a small Express/Fastify app (or even an n8n webhook workflow) that runs the Google OAuth flow, captures the access_token and refresh_token, then uses the n8n API (PATCH /api/v1/credentials/{credentialId}) to write the tokens directly into the pre-created credential. Client authorizes their Google account, your backend handles the rest, and they never see the editor.

If you’re on the enterprise plan, n8n Projects gives you native workflow/credential isolation per client inside a single instance - no separate containers needed. For non-enterprise, separate Docker containers per client is the most secure option, though it adds ops overhead.

2 curtidas