Architecture review for a self-hosted n8n + Gmail + Claude service for 3–5 clients

Questions
1

Describe the problem/error/question

Hello everyone,
I am building a small business focused on AI automation services for small businesses in France.
I currently have a working n8n workflow connected to Gmail and Claude. The workflow is intended to:

  • retrieve unread Gmail messages;
  • filter out automated reports and unwanted messages;
  • normalize each email into a canonical JSON structure;
  • send the email content to Claude for triage and response preparation;
  • create a Gmail draft;
  • add a fixed client signature outside the LLM;
  • mark the message as read only after successful processing;
  • send a summary report after each scheduled run.
    The workflow is self-hosted locally with Docker and is currently being redesigned from a personal prototype into a repeatable product for an initial maximum of 3–5 client companies.
    Current architecture
    Each client would have a configuration file containing settings such as:
  • client name and timezone;
  • language and tone;
  • text and HTML signatures;
  • business rules;
  • Anthropic model and token budget;
  • reporting recipients;
  • attachment limits;
  • optional Drive storage;
  • optional monitoring features.
    I also use a capabilities file to enable or disable modules such as:
  • attachment content reading;
  • OCR;
  • Google Drive storage;
  • monitoring and alerts.
    The workflow currently includes:
  • reading config.json;
  • reading capabilities.json;
  • merging and validating both files;
  • Gmail message retrieval;
  • email normalization;
  • LLM payload construction;
  • Anthropic API call;
  • response parsing;
  • Gmail draft creation;
  • message status update;
  • execution reporting.
    My main concern
    I am not trying to scale to hundreds of customers yet. My goal is to create a safe, maintainable and reproducible setup for only 3–5 first clients.
    I would appreciate feedback on the following architecture choices.
  1. Client isolation
    For 3–5 customers, which approach would you recommend?
    A. One separate n8n instance per client
    B. One shared n8n instance with one workflow per client
    C. One shared workflow using client-specific configuration
    D. Another architecture
    My priority is to prevent any possibility of mixing:
  • Gmail credentials;
  • email content;
  • signatures;
  • business rules;
  • reporting recipients;
  • Google Drive folders;
  • logs.
  1. Credentials and secrets
    What is the recommended way to manage:
  • Gmail OAuth credentials;
  • Anthropic API keys;
  • webhook URLs;
  • client-specific secrets;
  • exported workflow files?
    Should each client own their Anthropic account and API key, or is it reasonable for the service provider to use one account and track usage per client?
  1. Development, testing and production
    Would you recommend separate n8n environments for:
  • development;
  • testing;
  • production?
    What is the simplest reliable version-control process for n8n workflows?
    At the moment, I manually export workflow JSON files. I would like to avoid accidentally modifying the only stable version.
  1. Error handling and idempotency
    What would be the safest design to avoid:
  • processing the same email twice;
  • creating duplicate drafts;
  • marking an email as read before the draft is created;
  • losing an email if the LLM API fails;
  • running two scheduled executions at the same time?
    I am considering a client-specific lock with an expiration time, plus storing processed Gmail message IDs.
  1. Monitoring
    What minimum monitoring would you consider necessary before onboarding the first client?
    I plan to monitor:
  • workflow execution failures;
  • consecutive errors;
  • missing scheduled executions;
  • Gmail authentication failures;
  • Anthropic errors and rate limits;
  • token usage;
  • recovery after an incident.
    Would n8n Error Workflows be sufficient initially, or should I add an external monitoring tool from the beginning?
  1. Attachments
    Attachments are not yet fully enabled.
    I am considering:
  • MIME type allowlists;
  • maximum file size;
  • maximum files per email;
  • OCR as an optional capability;
  • not marking the email as read if an attachment could not be processed.
    Are there common n8n design patterns for safely handling attachments without keeping sensitive files in execution data or logs?
  1. Execution data and privacy
    Because this workflow processes business emails, I want to minimize sensitive data stored in n8n.
    What settings or practices do you recommend regarding:
  • successful execution retention;
  • failed execution retention;
  • binary data storage;
  • pruning;
  • logging;
  • workflow data saved in the database?
  1. Maintainability
    I am still learning n8n, JavaScript, Docker and API architecture.
    Which parts of this system would you strongly recommend having reviewed by an experienced n8n or DevOps engineer before using it with paying clients?
    My current thinking
    My current preference is:
  • one isolated environment or instance per client at first;
  • draft creation only, without automatic sending;
  • client-specific Gmail and Anthropic credentials;
  • strict configuration validation;
  • minimal execution retention;
  • daily backups;
  • an Error Workflow and external uptime monitoring;
  • a maximum of 3–5 clients until the installation process is stable.
    Does this sound reasonable, or is it unnecessarily complex for the first few customers?
    I am especially interested in feedback from people who have operated self-hosted n8n workflows for multiple businesses.
    Thank you for any advice, architecture criticism or lessons learned.

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

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): Docker
  • Operating system:
2

Hi @Jidenkaes

For a pilot serving 3‑5 French SMEs, the safest approach is to run a separate Docker‑Compose stack (n8n + database) for each client. This guarantees full credential and data isolation, prevents accidental cross‑talk between Gmail accounts, signatures, and Drive folders, and makes de‑provisioning a single client trivial. A shared instance with multiple workflows or a single workflow with per‑client config is riskier because n8n does not sandbox credentials, and mixing data would be hard to audit.

Store all OAuth refresh tokens, Anthropic API keys, webhook URLs, and any client‑specific secrets in a dedicated secret‑vault (HashiCorp Vault, AWS Secrets Manager, or Docker secrets). Prefer that each client supplies its own Anthropic account and API key; this isolates billing, rate limits, and usage tracking. Never embed secrets in config.json or workflow JSON—reference them via n8n credential objects instead.

Maintain three distinct n8n environments: development (local SQLite, mock credentials), testing/staging (real credentials but isolated DB), and production (per‑client stacks with PostgreSQL). Keep every workflow JSON in a Git repository, use pre‑commit validation, and automate deployment via a CI pipeline that pushes the exact JSON to the target instance. Tag releases per client to avoid accidental overwrites.

Implement idempotency by recording each Gmail Message‑ID in a processed‑ids table and acquiring a per‑client lock (Redis or DB row) before processing. Skip already‑seen IDs, and only mark the email as read after a draft is successfully created. Use n8n Error Workflows to capture failures, and add a simple heartbeat ping to an external service like Healthchecks.io. As the service grows, you can layer Prometheus/Grafana for richer metrics.

Allow‑list MIME types, enforce size limits, and handle attachments in a temporary directory that is deleted immediately after processing; disable binary data storage in n8n to avoid retaining sensitive files. Retain execution data only for a short window (e.g., 7 days), prune old runs, and redact PII on error logs. Before onboarding paying clients, have a DevOps or n8n specialist review Docker secret handling, credential scoping, and GDPR‑related data‑retention policies. This lightweight yet rigorous setup should be robust enough for the initial client cohort without unnecessary complexity.

3

Hi @Jidenkaes Welcome!
For stopping the same email being processed twice or a duplicate draft being created, there’s a no-code option built into n8n: the Remove Duplicates node with the Remove Items Processed in Previous Executions operation. Feed it the Gmail message id and it keeps a store of ids across runs and drops anything already seen. On a database-backed install that store survives restarts.
Where you place it matters. The node records an id the moment an item passes through it, so if it sits right after Gmail retrieval and the Anthropic call later fails, that id is already marked as seen and the email gets silently skipped on the next run, which is the “losing an email if the LLM fails” case you listed. Put it after the draft is created instead, so items that fail earlier are never recorded and get retried on the next run.