n8n for Client Projects

When you build automations for clients, self-hosting n8n gives you a competitive advantage that cloud-only tools cannot match. You control the data, the cost, and the deployment. A single $6/month VPS can run n8n for dozens of client workflows simultaneously, and you pass that infrastructure cost into your retainer without the per-seat pricing that makes Zapier expensive at scale.

The standard deployment stack is n8n plus a PostgreSQL database plus Traefik as a reverse proxy, all orchestrated with Docker Compose. PostgreSQL replaces the default SQLite database and is required for anything beyond a personal sandbox - it handles concurrent executions reliably and survives container restarts without data loss. Traefik handles HTTPS termination with automatic Let's Encrypt certificate renewal, so your n8n instance is always accessible at a clean domain like automation.yourclientname.com.

The Docker Compose file defines four things: the n8n container with your environment variables (including the webhook URL, basic auth credentials, and database connection string), the PostgreSQL container with a named volume for persistence, the Traefik container with your domain labels, and the shared network that connects them. Once the stack is running, every workflow you create is immediately accessible and every execution is logged to PostgreSQL for debugging.

For client deployments, run a separate n8n instance per client or use n8n's built-in multi-tenancy with separate credential scopes. Mixing client credentials inside one instance creates confusion and risk if a client ends the engagement and requests data deletion. The cleanest approach is a subdomain per client pointing to either a dedicated instance or a dedicated workspace on a shared instance.

Before pitching self-hosted n8n to a client, confirm they are comfortable with a non-SaaS tool that requires you to manage updates and uptime. Some enterprise clients will prefer the n8n Cloud option at $20/month for a hosted workspace - that is also a valid delivery model and removes your infrastructure maintenance obligation entirely.

n8n has over 400 integrations, but mastering every node before taking client work is a procrastination trap. In practice, roughly 17 nodes handle the mechanics of most real-world workflows. Once you are fluent with these, you can deliver the majority of client automation projects without reaching for anything obscure.

The trigger layer covers four nodes you will use constantly. The Webhook node receives data from external services via HTTP POST and is the entry point for most client integrations. The Schedule trigger runs workflows on a cron schedule - daily reports, weekly syncs, monthly cleanups. The Email Trigger watches an inbox and fires on new messages. The Form Trigger creates a hosted web form that submits directly into your workflow.

The data layer is where most of the logic lives. HTTP Request is the most versatile node in n8n: it lets you call any REST API that does not have a native n8n integration, which means you can connect to virtually any modern SaaS tool. Code runs arbitrary JavaScript inside the workflow, useful for data transformations that cannot be expressed with expressions alone. Set adds or overwrites specific fields in your data. Edit Fields restructures the data shape. Merge combines data from two branches of a workflow.

The control flow layer shapes how data moves. IF splits the workflow into two paths based on a condition. Switch creates multiple paths from a single condition with several possible outcomes. Loop Over Items processes an array one item at a time, essential for batch operations like sending individual emails to a list of contacts or processing a spreadsheet row by row.

The action layer connects to the external world. Send Email via SMTP or an email provider. Google Sheets for reading and writing spreadsheet data. Slack for notifications. HTTP Request (again) for any API call. Respond to Webhook sends a response back to whatever triggered the workflow.

Expressions bind these nodes together. Every field in every node accepts expressions using double curly braces: {{ $json.email }} references the email field from the previous node's output. {{ $now.toISO() }} inserts the current timestamp. {{ $items().length }} gives the count of items. Fluency with expressions is what separates n8n builders who can deliver anything from those who hit walls constantly.

The biggest differentiator n8n offers over Make and Zapier is native AI nodes that run language models directly inside the workflow. An n8n workflow can receive an email, pass its content to GPT-4o for classification or summarization, then route the result through branching logic - all without leaving the workflow canvas.

The AI Agent node is n8n's most powerful AI primitive. It wraps an LLM (OpenAI, Anthropic, Google Gemini, or any OpenAI-compatible endpoint) with a tool-use layer that lets the model call other n8n nodes as tools. You define a system prompt describing the agent's role, attach tools like "search the web," "read this Google Sheet," or "call this API," and the agent decides which tools to call and in what order to fulfill the user's request. This is how you build AI assistants that can actually take action rather than just generate text.

For simpler use cases, the OpenAI node and Anthropic node offer direct API access without the overhead of the agent loop. Pass a prompt and some data, receive the model's response, use it downstream. Common patterns include: summarizing long text inputs, classifying incoming data into categories, extracting structured fields from unstructured text (like pulling name, email, and company from a free-text form submission), and generating personalized content from template data.

Credential management is where many beginners create security problems. n8n stores credentials encrypted at rest, but you still need discipline about which credentials live in which workspace and who has access. For client projects, create a dedicated credential for each client's services - one Gmail OAuth credential per client Gmail account, one Notion API key per client Notion workspace. Never share a credential that grants access to your agency's accounts for a client-facing workflow.

When handing off a deployed workflow to a client, document every credential the workflow uses with the service name, the account it authenticates, and instructions for rotating it if the key is compromised. Clients who end your engagement will need to reconfigure these credentials under their own accounts. Building that handoff documentation into every project protects you from support calls six months later.

A workflow that runs perfectly in testing but crashes silently in production destroys client trust faster than anything else. The two most important reliability mechanisms in n8n are webhook configuration and error workflows, and both require intentional setup before you hand anything over to a client.

Webhooks in n8n have two modes: test and production. The test URL is active only while you have the workflow open in the editor with the "Listen for Test Event" button clicked. The production URL is active whenever the workflow is activated (toggled on). A very common mistake is registering the test URL in the external service during development and forgetting to update it to the production URL before going live. When you activate the workflow and the client starts sending data, nothing arrives because the external service is still pointing at the now-inactive test endpoint. Always register the production URL in external services.

Webhook authentication prevents unauthorized requests from triggering your workflows. n8n supports HTTP Header Auth, Basic Auth, and JWT verification on incoming webhooks. For client workflows, always require at minimum a shared secret in the request headers. A webhook endpoint that accepts any request without authentication is a security liability and a potential abuse vector.

Error workflows are n8n's mechanism for catching failures in activated workflows. In a workflow's settings, you can specify an error workflow that runs whenever that workflow fails. The error workflow receives context about what failed, including the error message, the workflow name, and the execution ID. A standard agency error workflow sends a Slack notification or email to you with that context so you hear about failures immediately rather than when a client calls asking why their automation stopped working.

Beyond error workflows, use the retry on fail option on individual nodes for operations that can fail transiently, like HTTP requests to external APIs that sometimes return 429 rate limit responses. Set a retry count of three and a wait of two seconds between retries. This handles a large proportion of transient failures automatically without triggering the full error workflow.