Why n8n Over Zapier, Make, or Custom Code

Before we talk architecture, let's address the elephant in the room: why n8n at all?

I've built automations on Zapier, Make (formerly Integromat), custom Python scripts, and n8n. Each has its place. But for production automation work, n8n wins on four axes that matter more than anything else.

Self-Hosting and Data Sovereignty

This is the big one. With Zapier and Make, your data flows through their servers. Every customer record, every API key, every payload passes through infrastructure you don't control. For most hobby projects, that's fine. For anything touching PII, healthcare data, financial records, or sensitive business logic? That's a non-starter.

n8n self-hosts on your infrastructure. Your VPC. Your Docker containers. Your PostgreSQL database. The data never leaves your network. When a client asks "where does our data go?" you point at your own server rack (or your own AWS account) and say "right there." That conversation alone has won us contracts.

Cost at Scale

Zapier charges per task. Make charges per operation. These pricing models are designed to be cheap at the start and devastating at scale. I've seen teams hit $2,000/month on Zapier for workflows that cost $30/month to run on a self-hosted n8n instance.

Let me give you real numbers. A single workflow that syncs CRM data every 15 minutes, processing roughly 500 records per run:

Zapier: ~48,000 tasks/month = $599/month (Professional plan)
Make: ~48,000 operations/month = $299/month (Teams plan)
n8n self-hosted: 2 vCPU, 4GB RAM VPS = $24/month

That's not a rounding error. That's the difference between a sustainable automation strategy and a cost center that keeps growing.

Code When You Need It

Make and Zapier have "code" steps, but they're sandboxed and limited. n8n's Function node gives you full JavaScript with access to Node.js built-in modules. You can require('crypto'). You can write complex data transformations. You can use async/await. When the visual builder hits its limit, you drop into code and keep going. No switching platforms, no rewriting logic.

The Visual Builder Is Actually Good

This matters more than developers want to admit. When your marketing team needs to understand what the CRM sync does, they can look at the n8n canvas and follow the flow. Try explaining a 400-line Python script to a non-technical stakeholder. The visual representation isn't just for building -- it's documentation that stays current because it IS the workflow.

Self-Hosting Architecture

Running n8n on someone else's cloud defeats the whole purpose. Here's how to self-host it properly.

Docker Compose Setup

This is the production-grade docker-compose.yml I use as a starting point. SQLite is fine for testing. PostgreSQL is mandatory for production.

yaml

version: "3.8"
 
services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://${N8N_HOST}/
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
      - GENERIC_TIMEZONE=America/New_York
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - n8n-network
 
  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - n8n-network
 
volumes:
  n8n_data:
  postgres_data:
 
networks:
  n8n-network:
    driver: bridge

A few things to notice. The EXECUTIONS_DATA_PRUNE=true with EXECUTIONS_DATA_MAX_AGE=168 means execution data gets cleaned up after 7 days. Without this, your PostgreSQL database will grow until it fills your disk. I've seen it happen. It's not fun at 3 AM.

The N8N_ENCRYPTION_KEY is critical. This key encrypts all stored credentials. Lose it, and you lose access to every credential in your database. Generate it once, store it somewhere safe (a secrets manager, not a sticky note), and never change it.

Resource Sizing

How much hardware does n8n actually need? Here's what I've seen in practice:

Small (< 50 workflows, < 1,000 executions/day): 2 vCPU, 4 GB RAM, 20 GB disk
Medium (50-200 workflows, 1,000-10,000 executions/day): 4 vCPU, 8 GB RAM, 50 GB disk
Large (200+ workflows, 10,000+ executions/day): 8+ vCPU, 16+ GB RAM, 100+ GB disk, queue mode with workers

The biggest bottleneck isn't CPU -- it's memory. n8n loads entire datasets into memory during processing. A workflow that processes 50,000 records in a single execution will eat RAM fast. We'll cover how to handle that in the performance section.

PostgreSQL Backend: Why It Matters

SQLite is n8n's default database, and it works fine for development. In production, it will betray you. SQLite uses file-level locking. When two workflows execute simultaneously and both try to write execution data, one blocks the other. Under load, this creates cascading delays that look like random slowdowns.

PostgreSQL handles concurrent writes without breaking a sweat. It also gives you:

Point-in-time recovery: Restore your n8n state to any moment
Replication: Read replicas for reporting without hitting your primary
Better indexing: Faster execution history queries
Proper vacuuming: Automatic cleanup of dead tuples

Configure your PostgreSQL with these production-appropriate settings:

ini

# postgresql.conf additions for n8n workloads
shared_buffers = 256MB
effective_cache_size = 1GB
work_mem = 16MB
maintenance_work_mem = 128MB
max_connections = 100
checkpoint_completion_target = 0.9
wal_buffers = 16MB

Error Handling That Actually Works

The default n8n behavior stops your workflow on any error. In production, that's death. One flaky API response and your entire pipeline grinds to a halt. You need resilience -- the ability to handle failures gracefully, retry intelligently, and alert on real problems without flooding your team with noise.

Try/Catch in Function Nodes

The most basic pattern: wrap risky operations in try/catch blocks. But don't just catch the error -- capture enough context to debug it later.

javascript

// In a Function node - robust error handling
try {
  const response = await $http.request({
    method: 'POST',
    url: 'https://api.example.com/data',
    body: items[0].json,
    timeout: 10000, // Always set timeouts
  });
 
  return [{
    json: {
      success: true,
      data: response,
      processedAt: new Date().toISOString()
    }
  }];
} catch (error) {
  // Capture rich error context for debugging
  const errorContext = {
    success: false,
    error: error.message,
    statusCode: error.response?.status || null,
    responseBody: error.response?.data || null,
    originalData: items[0].json,
    timestamp: new Date().toISOString(),
    retryable: [408, 429, 500, 502, 503, 504].includes(
      error.response?.status
    )
  };
 
  // Return the error as data instead of throwing
  return [{ json: errorContext }];
}

Notice the retryable flag. Not all errors deserve a retry. A 400 Bad Request won't magically fix itself. A 429 Rate Limit or 503 Service Unavailable probably will. Tagging errors as retryable lets downstream logic decide what to do.

Error Workflows

n8n has a built-in feature most people ignore: error workflows. You can assign a dedicated workflow that fires whenever any other workflow fails. This is your global safety net.

Set it up in Settings > Error Workflow. The error workflow receives execution metadata including the workflow name, the error message, the failing node, and the execution ID. Here's a Function node that formats this into something useful:

javascript

// Error workflow - format failure context
const execution = $input.first().json;
 
const severity = determineSeverity(execution);
 
return [{
  json: {
    alertLevel: severity,
    workflow: execution.workflow?.name || 'Unknown Workflow',
    workflowId: execution.workflow?.id,
    error: execution.execution?.error?.message || 'Unknown error',
    failedNode: execution.execution?.error?.node || 'Unknown node',
    executionId: execution.execution?.id,
    timestamp: new Date().toISOString(),
    executionUrl: `https://n8n.yourdomain.com/workflow/${execution.workflow?.id}/executions/${execution.execution?.id}`,
    lastNodeExecuted: execution.execution?.lastNodeExecuted,
    mode: execution.execution?.mode // 'trigger', 'webhook', 'manual'
  }
}];
 
function determineSeverity(exec) {
  const workflowName = exec.workflow?.name || '';
  // Critical workflows get paged immediately
  if (workflowName.includes('[CRITICAL]')) return 'critical';
  // Payment and customer-facing workflows are high priority
  if (workflowName.includes('payment') || workflowName.includes('invoice'))
    return 'high';
  // Everything else is medium
  return 'medium';
}

I prefix critical workflow names with [CRITICAL] so the error handler knows to page someone instead of just sending a Slack message. Simple convention, massive impact at 2 AM.

Retry Logic with Exponential Backoff

n8n has built-in retry settings on individual nodes (Settings tab > Retry On Fail), but they're basic. For smarter retry logic -- exponential backoff with jitter -- you need a Function node:

javascript

// Retry wrapper with exponential backoff
const maxRetries = 3;
const baseDelay = 1000; // 1 second
 
const currentItem = items[0].json;
const retryCount = currentItem._retryCount || 0;
 
if (retryCount >= maxRetries) {
  // Max retries exhausted - send to dead letter queue
  return [{
    json: {
      ...currentItem,
      _status: 'dead_letter',
      _failedAt: new Date().toISOString(),
      _totalRetries: retryCount
    }
  }];
}
 
try {
  const response = await $http.request({
    method: 'POST',
    url: 'https://api.example.com/endpoint',
    body: currentItem.payload,
    timeout: 15000
  });
 
  return [{ json: { success: true, data: response } }];
} catch (error) {
  if (![408, 429, 500, 502, 503, 504].includes(error.response?.status)) {
    // Non-retryable error - fail immediately
    return [{
      json: {
        ...currentItem,
        _status: 'permanent_failure',
        _error: error.message,
        _statusCode: error.response?.status
      }
    }];
  }
 
  // Calculate delay with jitter to prevent thundering herd
  const delay = baseDelay * Math.pow(2, retryCount);
  const jitter = Math.random() * delay * 0.1;
  await new Promise(resolve => setTimeout(resolve, delay + jitter));
 
  // Increment retry count and loop back
  return [{
    json: {
      ...currentItem,
      _retryCount: retryCount + 1,
      _lastError: error.message,
      _lastAttempt: new Date().toISOString()
    }
  }];
}

The jitter is important. Without it, all your retries fire at the exact same moment, creating a thundering herd that makes the rate limit situation worse.

Dead Letter Queues

When retries are exhausted, don't just drop the data. Route it to a dead letter queue so a human can review it later. In n8n, this is usually a database table or a separate workflow:

javascript

// Dead letter queue handler
const failedItems = $input.all().filter(
  item => item.json._status === 'dead_letter'
);
 
if (failedItems.length === 0) return [];
 
// Store in PostgreSQL dead_letter_queue table
const records = failedItems.map(item => ({
  workflow_name: $workflow.name,
  execution_id: $execution.id,
  payload: JSON.stringify(item.json),
  error_message: item.json._lastError || 'Unknown',
  retry_count: item.json._totalRetries || 0,
  created_at: new Date().toISOString(),
  status: 'pending_review'
}));
 
return records.map(r => ({ json: r }));

Connect this to a PostgreSQL node that inserts into a dead_letter_queue table. Then build a simple review workflow with a manual trigger that lets you inspect and replay failed items. This pattern has saved me countless hours of forensic debugging.

Webhook Security

Every public webhook is an attack surface. If you're exposing n8n webhook URLs to the internet without authentication, you're asking for trouble. Bots will find them. Bad actors will probe them. And your workflows will process garbage data or get overwhelmed.

HMAC Signature Validation

The gold standard for webhook security is HMAC signature validation. The sender signs the payload with a shared secret, and your workflow verifies the signature before processing:

javascript

// Webhook HMAC signature validation
const crypto = require('crypto');
 
const headers = $input.first().headers;
const body = $input.first().body;
const secret = $env.WEBHOOK_SECRET;
 
// Different services use different header names
const signature = headers['x-webhook-signature']
  || headers['x-hub-signature-256']
  || headers['stripe-signature']
  || '';
 
if (!signature) {
  throw new Error('Missing webhook signature header');
}
 
const payload = typeof body === 'string' ? body : JSON.stringify(body);
 
// Compute expected signature
const expectedSignature = crypto
  .createHmac('sha256', secret)
  .update(payload)
  .digest('hex');
 
// Use timing-safe comparison to prevent timing attacks
const signatureBuffer = Buffer.from(signature, 'hex');
const expectedBuffer = Buffer.from(expectedSignature, 'hex');
 
if (signatureBuffer.length !== expectedBuffer.length ||
    !crypto.timingSafeEqual(signatureBuffer, expectedBuffer)) {
  throw new Error('Invalid webhook signature - request rejected');
}
 
// Signature valid - continue processing
return $input.all();

Two things most guides skip: First, use crypto.timingSafeEqual() instead of ===. String comparison leaks timing information that can be used to brute-force signatures. Second, different services put the signature in different headers. Stripe uses stripe-signature, GitHub uses x-hub-signature-256, custom integrations use whatever they want. Handle them all.

IP Whitelisting

If you know exactly which IPs will send you webhooks, whitelist them in a Function node at the start of your webhook workflow:

javascript

// IP whitelist validation
const allowedIPs = [
  '192.168.1.0/24',    // Internal network
  '52.31.0.0/16',      // Stripe webhook IPs
  '140.82.112.0/20',   // GitHub webhook IPs
];
 
const clientIP = $input.first().headers['x-forwarded-for']
  || $input.first().headers['x-real-ip']
  || 'unknown';
 
// Simple exact match (for production, use a CIDR library)
const isAllowed = allowedIPs.some(allowed => {
  if (allowed.includes('/')) {
    // For CIDR ranges, you'd want a proper library
    // This is simplified - use 'ip-range-check' in production
    return clientIP.startsWith(allowed.split('/')[0].split('.').slice(0, 2).join('.'));
  }
  return clientIP === allowed;
});
 
if (!isAllowed) {
  throw new Error(`Rejected request from unauthorized IP: ${clientIP}`);
}
 
return $input.all();

For proper CIDR matching in production, use the ip-range-check npm package or handle this at the reverse proxy level with nginx or Caddy.

Rate Limiting

Even authenticated webhooks should be rate-limited. A misbehaving integration can flood your n8n instance with thousands of requests per minute:

javascript

// Simple rate limiter using workflow static data
const staticData = $getWorkflowStaticData('global');
const now = Date.now();
const windowMs = 60000; // 1 minute window
const maxRequests = 100; // max 100 requests per minute
 
// Initialize or clean expired entries
if (!staticData.requestLog) staticData.requestLog = [];
staticData.requestLog = staticData.requestLog.filter(
  ts => now - ts < windowMs
);
 
if (staticData.requestLog.length >= maxRequests) {
  throw new Error(
    `Rate limit exceeded: ${staticData.requestLog.length} requests in the last minute`
  );
}
 
// Log this request
staticData.requestLog.push(now);
 
return $input.all();

This uses n8n's workflow static data -- persistent data that survives across executions but lives in memory. It's perfect for lightweight state like rate limiting counters. For heavier rate limiting, use Redis.

Batch Processing Patterns

Processing thousands of records one at a time is the fastest way to hit API rate limits, blow through memory, and create workflows that take hours to complete. Batch processing is the answer, but it's more nuanced than just "split into chunks."

Smart Batching with Rate Limiting

This pattern splits items into batches AND respects the target API's rate limits:

javascript

// Batch splitter with rate limit awareness
const items = $input.all();
const batchSize = 100;
const rateLimitPerMinute = 600; // Target API allows 600/min
const delayBetweenBatches = Math.ceil(
  (60000 / rateLimitPerMinute) * batchSize
); // ms
 
const batches = [];
 
for (let i = 0; i < items.length; i += batchSize) {
  const batch = items.slice(i, i + batchSize).map(item => item.json);
 
  batches.push({
    json: {
      items: batch,
      batchIndex: Math.floor(i / batchSize),
      totalBatches: Math.ceil(items.length / batchSize),
      totalItems: items.length,
      delayMs: delayBetweenBatches,
      isLastBatch: i + batchSize >= items.length
    }
  });
}
 
return batches;

After this node, connect a Wait node set to {{ $json.delayMs }} milliseconds. This spaces out your batches to stay within rate limits without manual calculation.

Progress Tracking

For long-running batch operations, track progress so you can monitor and resume if something fails:

javascript

// Progress tracker - runs after each batch completes
const staticData = $getWorkflowStaticData('global');
const batch = $input.first().json;
 
// Initialize tracking
if (!staticData.batchProgress) {
  staticData.batchProgress = {
    startedAt: new Date().toISOString(),
    totalBatches: batch.totalBatches,
    totalItems: batch.totalItems,
    completedBatches: 0,
    successCount: 0,
    failureCount: 0,
    errors: []
  };
}
 
const progress = staticData.batchProgress;
progress.completedBatches += 1;
progress.successCount += batch.successCount || batch.items.length;
progress.failureCount += batch.failureCount || 0;
 
if (batch.errors) {
  progress.errors.push(...batch.errors);
}
 
const percentComplete = Math.round(
  (progress.completedBatches / progress.totalBatches) * 100
);
 
// Emit progress update
const output = {
  json: {
    ...progress,
    percentComplete,
    estimatedTimeRemaining: estimateTimeRemaining(progress),
    lastUpdated: new Date().toISOString()
  }
};
 
// Clear tracking on final batch
if (batch.isLastBatch) {
  staticData.batchProgress = null;
}
 
return [output];
 
function estimateTimeRemaining(p) {
  const elapsed = Date.now() - new Date(p.startedAt).getTime();
  const avgTimePerBatch = elapsed / p.completedBatches;
  const remaining = (p.totalBatches - p.completedBatches) * avgTimePerBatch;
  return Math.round(remaining / 1000) + ' seconds';
}

Feed the progress output into a Slack or email notification on the final batch so your team knows when a large job completes.

Credential Management

n8n stores credentials encrypted in the database. That's a good start. But in production, you need to think harder about how credentials flow through your system.

Environment Variables Over Hardcoded Values

Never put API keys, passwords, or secrets directly in your workflow nodes. Use environment variables. In your docker-compose.yml or .env file:

bash

# .env file for n8n
N8N_ENCRYPTION_KEY=your-random-32-character-string
POSTGRES_USER=n8n_user
POSTGRES_PASSWORD=strong-random-password
 
# Application secrets accessed via $env in workflows
OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
WEBHOOK_SECRET=whsec_...
SLACK_BOT_TOKEN=xoxb-...
CRM_API_KEY=...

In your Function nodes, access these with $env.VARIABLE_NAME. This means your workflow JSON files contain zero secrets -- you can safely version control them, share them, and export them without redacting anything.

External Secret Stores

For enterprise deployments, environment variables aren't enough. You want a proper secret store like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. n8n supports external secret stores natively. Configure it in your environment:

yaml

# docker-compose.yml environment additions for Vault
environment:
  - N8N_EXTERNAL_SECRETS_BACKEND=vault
  - N8N_EXTERNAL_SECRETS_VAULT_URL=https://vault.yourdomain.com
  - N8N_EXTERNAL_SECRETS_VAULT_TOKEN=${VAULT_TOKEN}
  - N8N_EXTERNAL_SECRETS_VAULT_NAMESPACE=n8n
  - N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL=300

With this setup, credentials are fetched from Vault at runtime and cached for 5 minutes. If a credential gets rotated in Vault, n8n picks up the new value automatically. No redeployment, no manual updates.

Credential Encryption Key Rotation

The N8N_ENCRYPTION_KEY is the skeleton key to your entire credential store. If it's compromised, every credential in your database is exposed. Rotate it periodically:

Export all workflows (we'll cover this in version control)
Stop n8n
Update N8N_ENCRYPTION_KEY in your environment
Run n8n credential:reset to re-encrypt all credentials
Restart n8n
Verify all workflows still authenticate correctly

This is disruptive, so plan it during maintenance windows. But it's necessary. Treat your encryption key like a root password.

Sub-Workflow Patterns

As your automation estate grows, you'll have workflows that share common logic: data validation, API authentication, error formatting, notification routing. Copy-pasting this logic across 50 workflows is a maintenance nightmare. Sub-workflows solve this.

Building Reusable Sub-Workflows

Create a workflow that accepts input via the Execute Workflow Trigger node and returns output. Think of it like a function call:

javascript

// Sub-workflow: "Validate and Enrich Contact"
// Input: raw contact data
// Output: validated, enriched contact or validation errors
 
const contact = $input.first().json;
const errors = [];
 
// Validate required fields
if (!contact.email) errors.push('Missing email');
if (!contact.name) errors.push('Missing name');
 
// Validate email format
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (contact.email && !emailRegex.test(contact.email)) {
  errors.push('Invalid email format');
}
 
// Normalize data
const enriched = {
  ...contact,
  email: contact.email?.toLowerCase().trim(),
  name: contact.name?.trim(),
  normalizedPhone: normalizePhone(contact.phone),
  source: contact.source || 'unknown',
  processedAt: new Date().toISOString()
};
 
if (errors.length > 0) {
  return [{
    json: {
      valid: false,
      errors,
      originalData: contact
    }
  }];
}
 
return [{ json: { valid: true, data: enriched } }];
 
function normalizePhone(phone) {
  if (!phone) return null;
  // Strip everything except digits and leading +
  return phone.replace(/[^\d+]/g, '');
}

Now any workflow that processes contacts calls this sub-workflow via the Execute Workflow node. Update the validation logic once, and every parent workflow gets the fix.

Passing Data Between Workflows

The Execute Workflow node passes the current items to the sub-workflow and receives the output items back. But there's a gotcha: large payloads. If you're passing 10,000 items to a sub-workflow, all that data gets serialized and deserialized. For large datasets, pass a reference instead:

javascript

// Parent workflow - store data in DB and pass reference
const batchId = `batch_${Date.now()}_${Math.random().toString(36).slice(2, 9)}`;
 
// Store full data in PostgreSQL (via a preceding DB node)
// Then pass only the reference to the sub-workflow
return [{
  json: {
    batchId,
    recordCount: items.length,
    tableName: 'staging_contacts',
    processingOptions: {
      validateEmail: true,
      enrichFromCRM: true,
      deduplication: true
    }
  }
}];

The sub-workflow reads from the database using the batchId, processes the data, and writes results back. This keeps the inter-workflow payload small and prevents memory issues.

Database Integration Patterns

Most production workflows eventually need a database. Whether it's caching API responses, storing processing state, or building data pipelines, here's how to integrate databases cleanly.

PostgreSQL for Persistent State

You already have PostgreSQL running for n8n's own database. Spin up a second database (or schema) for your workflow data:

sql

-- Create a schema for workflow data (run once)
CREATE SCHEMA IF NOT EXISTS workflow_data;
 
-- Sync tracking table
CREATE TABLE workflow_data.sync_state (
  id SERIAL PRIMARY KEY,
  source_system VARCHAR(100) NOT NULL,
  entity_type VARCHAR(100) NOT NULL,
  last_sync_timestamp TIMESTAMPTZ NOT NULL,
  last_sync_record_id VARCHAR(255),
  records_processed INTEGER DEFAULT 0,
  status VARCHAR(50) DEFAULT 'completed',
  metadata JSONB,
  updated_at TIMESTAMPTZ DEFAULT NOW()
);
 
CREATE UNIQUE INDEX idx_sync_state_source_entity
  ON workflow_data.sync_state(source_system, entity_type);
 
-- Dead letter queue
CREATE TABLE workflow_data.dead_letter_queue (
  id SERIAL PRIMARY KEY,
  workflow_name VARCHAR(255) NOT NULL,
  execution_id VARCHAR(255),
  payload JSONB NOT NULL,
  error_message TEXT,
  retry_count INTEGER DEFAULT 0,
  status VARCHAR(50) DEFAULT 'pending_review',
  created_at TIMESTAMPTZ DEFAULT NOW(),
  reviewed_at TIMESTAMPTZ,
  reviewed_by VARCHAR(100)
);

Use n8n's PostgreSQL node to read and write to these tables. The sync_state table is especially powerful -- it lets you build incremental syncs that pick up where they left off instead of reprocessing everything.

Redis for Caching

When you're calling an external API repeatedly with the same parameters, cache the results in Redis. This reduces API costs, speeds up workflows, and protects you from rate limits:

javascript

// Redis caching pattern for API responses
const redis = require('redis');
 
const cacheKey = `api_cache:${$json.endpoint}:${JSON.stringify($json.params)}`;
const cacheTTL = 3600; // 1 hour
 
// Try to get from cache first
const client = redis.createClient({
  url: $env.REDIS_URL || 'redis://redis:6379'
});
await client.connect();
 
try {
  const cached = await client.get(cacheKey);
 
  if (cached) {
    await client.quit();
    return [{
      json: {
        data: JSON.parse(cached),
        source: 'cache',
        cachedAt: await client.get(`${cacheKey}:timestamp`)
      }
    }];
  }
 
  // Cache miss - make the API call
  const response = await $http.request({
    method: 'GET',
    url: $json.endpoint,
    qs: $json.params,
    timeout: 10000
  });
 
  // Store in cache
  await client.set(cacheKey, JSON.stringify(response), { EX: cacheTTL });
  await client.set(`${cacheKey}:timestamp`, new Date().toISOString(), {
    EX: cacheTTL
  });
  await client.quit();
 
  return [{
    json: {
      data: response,
      source: 'api',
      fetchedAt: new Date().toISOString()
    }
  }];
} catch (error) {
  await client.quit();
  throw error;
}

Add Redis to your docker-compose.yml:

yaml

  redis:
    image: redis:7-alpine
    restart: always
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data
    networks:
      - n8n-network

The allkeys-lru eviction policy means Redis automatically removes the least recently used entries when memory fills up. Set it and forget it.

Monitoring and Alerting

You can't manage what you can't measure. Here's how to build observability into your n8n deployment.

Error Notification Workflow

This is your global error handler. Every workflow failure routes through this:

javascript

// Global error notification formatter
const execution = $input.first().json;
 
const message = {
  blocks: [
    {
      type: 'header',
      text: {
        type: 'plain_text',
        text: `Workflow Failed: ${execution.workflow?.name || 'Unknown'}`
      }
    },
    {
      type: 'section',
      fields: [
        {
          type: 'mrkdwn',
          text: `*Error:*\n${execution.execution?.error?.message || 'Unknown error'}`
        },
        {
          type: 'mrkdwn',
          text: `*Node:*\n${execution.execution?.error?.node || 'Unknown'}`
        },
        {
          type: 'mrkdwn',
          text: `*Execution ID:*\n${execution.execution?.id}`
        },
        {
          type: 'mrkdwn',
          text: `*Mode:*\n${execution.execution?.mode}`
        }
      ]
    },
    {
      type: 'actions',
      elements: [
        {
          type: 'button',
          text: { type: 'plain_text', text: 'View Execution' },
          url: `https://n8n.yourdomain.com/workflow/${execution.workflow?.id}/executions/${execution.execution?.id}`
        }
      ]
    }
  ]
};
 
return [{ json: message }];

Send this to a Slack channel via the Slack node using "Send Block Kit Message." The button links directly to the failed execution so whoever's on-call can diagnose the issue immediately.

Execution Metrics

Build a scheduled workflow that queries n8n's own database for execution statistics:

sql

-- Query n8n's execution data for the last 24 hours
SELECT
  w.name as workflow_name,
  COUNT(*) as total_executions,
  COUNT(CASE WHEN e.finished = true AND e.status = 'success' THEN 1 END) as successes,
  COUNT(CASE WHEN e.status = 'error' THEN 1 END) as failures,
  ROUND(
    COUNT(CASE WHEN e.status = 'error' THEN 1 END)::numeric /
    NULLIF(COUNT(*), 0) * 100, 2
  ) as failure_rate,
  AVG(EXTRACT(EPOCH FROM (e."stoppedAt" - e."startedAt"))) as avg_duration_seconds
FROM execution_entity e
JOIN workflow_entity w ON e."workflowId" = w.id
WHERE e."startedAt" > NOW() - INTERVAL '24 hours'
GROUP BY w.name
ORDER BY failures DESC;

Run this daily and send the summary to your team. Any workflow with a failure rate above 5% needs investigation.

Health Check Endpoint

Create a simple webhook workflow that returns the health status of your n8n instance:

javascript

// Health check endpoint - expose as webhook at /health
const healthChecks = {
  status: 'ok',
  timestamp: new Date().toISOString(),
  uptime: process.uptime(),
  memory: {
    used: Math.round(process.memoryUsage().heapUsed / 1024 / 1024),
    total: Math.round(process.memoryUsage().heapTotal / 1024 / 1024),
    unit: 'MB'
  },
  version: $env.N8N_VERSION || 'unknown'
};
 
// Check if memory usage is concerning (over 80%)
const memRatio = process.memoryUsage().heapUsed / process.memoryUsage().heapTotal;
if (memRatio > 0.8) {
  healthChecks.status = 'degraded';
  healthChecks.warnings = ['High memory usage'];
}
 
return [{ json: healthChecks }];

Point your uptime monitor (UptimeRobot, Better Uptime, Pingdom) at this webhook URL. When it stops responding or returns degraded, you know something needs attention before it becomes an outage.

Performance Optimization

n8n is single-threaded by default. It processes one execution at a time per workflow. That's fine for light workloads. For production scale, you need to understand where the bottlenecks are and how to eliminate them.

Memory Management

The number one performance killer in n8n is memory. Every item in your workflow lives in memory. If you're processing 100,000 records, all 100,000 are loaded into RAM simultaneously.

Mitigation strategies:

Process in batches: Never load more than you can handle. Split large datasets into chunks of 500-1,000 items.
Prune unnecessary fields early: If each record has 50 fields and you only need 3, strip the rest in a Function node at the beginning.
Use streaming where possible: For file operations, stream data instead of loading it entirely into memory.

javascript

// Strip unnecessary fields to reduce memory footprint
const essentialFields = ['id', 'email', 'status', 'updated_at'];
 
return $input.all().map(item => ({
  json: Object.fromEntries(
    essentialFields
      .filter(key => key in item.json)
      .map(key => [key, item.json[key]])
  )
}));

This seems trivial, but I've seen workflows go from crashing at 10,000 records to handling 100,000 comfortably just by dropping unused fields early.

Queue Mode and Worker Scaling

For high-throughput deployments, n8n supports queue mode. Instead of the main process executing workflows directly, it enqueues them and dedicated workers pick them up. This lets you scale horizontally.

yaml

# docker-compose.yml for queue mode
services:
  n8n-main:
    image: n8nio/n8n:latest
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - QUEUE_HEALTH_CHECK_ACTIVE=true
    # ... other config
 
  n8n-worker:
    image: n8nio/n8n:latest
    command: worker
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    deploy:
      replicas: 3  # Scale workers as needed
    depends_on:
      - redis
      - postgres
    # ... other config
 
  redis:
    image: redis:7-alpine
    restart: always

With three workers, you can execute three workflows concurrently. Need more throughput? Increase the replica count. Workers are stateless -- they just pull jobs from the Redis queue and execute them.

Concurrency Control

Even in queue mode, you sometimes need to limit how many instances of a specific workflow run simultaneously. Maybe the target API only allows 5 concurrent connections, or your database can't handle 20 simultaneous bulk inserts:

javascript

// Concurrency limiter using Redis
const redis = require('redis');
const client = redis.createClient({ url: $env.REDIS_URL });
await client.connect();
 
const lockKey = `workflow_lock:${$workflow.id}`;
const maxConcurrent = 3;
const lockTTL = 300; // 5 minute timeout
 
try {
  const current = await client.incr(lockKey);
 
  if (current === 1) {
    // First execution - set TTL
    await client.expire(lockKey, lockTTL);
  }
 
  if (current > maxConcurrent) {
    await client.decr(lockKey);
    await client.quit();
    throw new Error(
      `Concurrency limit reached (${maxConcurrent}). Retry later.`
    );
  }
 
  // Continue with workflow...
  // Remember to decrement in a finally block or error handler
  return $input.all();
} catch (error) {
  await client.quit();
  throw error;
}

Pair this with the retry logic from the error handling section, and your workflows gracefully queue themselves when the system is under load.

Version Control for Workflows

Here's a truth that hurts: most n8n deployments have zero version control. Someone changes a workflow in the UI, breaks production, and there's no way to roll back. Don't be that team.

Export/Import Pipeline

Build a scheduled workflow that exports all workflows to JSON and commits them to Git:

javascript

// Export all workflows for version control
const workflows = await $http.request({
  method: 'GET',
  url: `http://localhost:5678/api/v1/workflows`,
  headers: {
    'X-N8N-API-KEY': $env.N8N_API_KEY
  }
});
 
// Format each workflow for clean Git diffs
const formatted = workflows.data.map(wf => ({
  filename: `${wf.id}_${wf.name.replace(/[^a-zA-Z0-9]/g, '_')}.json`,
  content: JSON.stringify(wf, null, 2),
  id: wf.id,
  name: wf.name,
  updatedAt: wf.updatedAt
}));
 
return formatted.map(f => ({ json: f }));

After this Function node, use an Execute Command node (or a sub-workflow) to write files to disk and commit:

bash

#!/bin/bash
# Export and commit n8n workflows
EXPORT_DIR="/data/n8n-workflows"
cd "$EXPORT_DIR" || exit 1
 
git add -A
git diff --cached --quiet && exit 0  # No changes
 
git commit -m "Auto-export: $(date '+%Y-%m-%d %H:%M:%S')"
git push origin main

Run this every hour. Now you have a full history of every workflow change, who made it (via the n8n audit log), and the ability to roll back by importing a previous version.

Promoting Workflows Between Environments

If you have staging and production n8n instances (and you should), use the API to promote workflows:

javascript

// Promote workflow from staging to production
const workflowId = $json.workflowId;
 
// Export from staging
const workflow = await $http.request({
  method: 'GET',
  url: `${$env.STAGING_N8N_URL}/api/v1/workflows/${workflowId}`,
  headers: { 'X-N8N-API-KEY': $env.STAGING_API_KEY }
});
 
// Strip staging-specific data
const exportData = workflow;
delete exportData.id;
delete exportData.createdAt;
delete exportData.updatedAt;
exportData.active = false; // Don't auto-activate in production
 
// Import to production
const result = await $http.request({
  method: 'POST',
  url: `${$env.PRODUCTION_N8N_URL}/api/v1/workflows`,
  headers: { 'X-N8N-API-KEY': $env.PRODUCTION_API_KEY },
  body: exportData
});
 
return [{
  json: {
    status: 'promoted',
    stagingId: workflowId,
    productionId: result.id,
    name: result.name,
    promotedAt: new Date().toISOString()
  }
}];

This pattern prevents the "works in staging, breaks in production" scenario where someone manually recreates a workflow and introduces subtle differences.

Real Production Patterns

Theory is great. Here are three patterns running in production right now.

CRM Sync Pipeline

This workflow keeps HubSpot and a PostgreSQL data warehouse in sync, running every 15 minutes:

Cron Trigger: Every 15 minutes
Read Sync State: Query sync_state table for last sync timestamp
Fetch Changed Records: Call HubSpot API with lastModifiedDate > last_sync_timestamp
Validate & Transform: Sub-workflow to normalize data, validate emails, parse phone numbers
Batch Upsert: Split into batches of 200, upsert to PostgreSQL with ON CONFLICT
Update Sync State: Record the new high watermark timestamp
Report: If any failures, route to dead letter queue and notify

javascript

// HubSpot incremental sync - fetch changed contacts
const lastSync = $input.first().json.last_sync_timestamp || '2024-01-01T00:00:00Z';
 
let allContacts = [];
let hasMore = true;
let after = undefined;
 
while (hasMore) {
  const response = await $http.request({
    method: 'POST',
    url: 'https://api.hubapi.com/crm/v3/objects/contacts/search',
    headers: {
      'Authorization': `Bearer ${$env.HUBSPOT_TOKEN}`,
      'Content-Type': 'application/json'
    },
    body: {
      filterGroups: [{
        filters: [{
          propertyName: 'lastmodifieddate',
          operator: 'GTE',
          value: lastSync
        }]
      }],
      properties: ['email', 'firstname', 'lastname', 'phone', 'company',
                    'lifecyclestage', 'hs_lead_status'],
      limit: 100,
      after
    }
  });
 
  allContacts.push(...response.results);
  hasMore = !!response.paging?.next?.after;
  after = response.paging?.next?.after;
}
 
return allContacts.map(c => ({
  json: {
    hubspot_id: c.id,
    email: c.properties.email,
    first_name: c.properties.firstname,
    last_name: c.properties.lastname,
    phone: c.properties.phone,
    company: c.properties.company,
    lifecycle_stage: c.properties.lifecyclestage,
    lead_status: c.properties.hs_lead_status,
    synced_at: new Date().toISOString()
  }
}));

The key insight: incremental syncs. You only fetch records that changed since your last sync. This turns a 30-minute full sync into a 10-second incremental update. The sync_state table is what makes this possible.

Invoice Processing

This workflow watches a shared Google Drive folder for new invoice PDFs, extracts data, and creates records in the accounting system:

Trigger: Google Drive watch for new files in /Invoices/Incoming
Download PDF: Fetch the file content
Extract Data: Send to an LLM or OCR service to extract invoice number, vendor, amount, line items, due date
Validate: Check extracted data against business rules (amount ranges, known vendors, duplicate detection)
Create Record: Push to accounting API (QuickBooks, Xero, etc.)
Move File: Move processed PDF to /Invoices/Processed folder
Handle Failures: Low-confidence extractions go to a review queue

javascript

// Invoice validation with business rules
const invoice = $input.first().json;
const warnings = [];
const errors = [];
 
// Required field validation
if (!invoice.invoiceNumber) errors.push('Missing invoice number');
if (!invoice.vendorName) errors.push('Missing vendor name');
if (!invoice.totalAmount) errors.push('Missing total amount');
if (!invoice.dueDate) errors.push('Missing due date');
 
// Business rule validation
if (invoice.totalAmount > 50000) {
  warnings.push('High-value invoice - requires manual approval');
}
 
// Duplicate detection
const existingInvoices = $input.all().slice(1); // Previous invoices from DB query
const isDuplicate = existingInvoices.some(
  existing => existing.json.invoice_number === invoice.invoiceNumber
    && existing.json.vendor === invoice.vendorName
);
 
if (isDuplicate) {
  errors.push('Duplicate invoice detected');
}
 
// Date validation
const dueDate = new Date(invoice.dueDate);
const today = new Date();
if (dueDate < today) {
  warnings.push('Invoice is past due');
}
 
return [{
  json: {
    ...invoice,
    valid: errors.length === 0,
    errors,
    warnings,
    confidence: invoice.extractionConfidence || 0,
    requiresReview: errors.length > 0
      || warnings.length > 0
      || (invoice.extractionConfidence || 0) < 0.85,
    processedAt: new Date().toISOString()
  }
}];

Invoices with requiresReview: true get routed to a Slack notification with approval buttons. Everything else goes straight to the accounting system. This pattern handles 80% of invoices automatically and catches the edge cases before they become accounting errors.

Automated Reporting

A daily workflow that aggregates data from multiple sources and delivers formatted reports:

javascript

// Daily metrics aggregator
const today = new Date();
const yesterday = new Date(today);
yesterday.setDate(yesterday.getDate() - 1);
 
const dateStr = yesterday.toISOString().split('T')[0];
 
// Assume previous nodes fetched data from various sources
const salesData = $node['Fetch Sales'].json;
const supportData = $node['Fetch Support Tickets'].json;
const deployData = $node['Fetch Deployments'].json;
 
const report = {
  date: dateStr,
  summary: {
    revenue: salesData.totalRevenue,
    newCustomers: salesData.newCustomers,
    churnedCustomers: salesData.churnedCustomers,
    netGrowth: salesData.newCustomers - salesData.churnedCustomers,
    supportTicketsOpened: supportData.opened,
    supportTicketsClosed: supportData.closed,
    avgResolutionTime: supportData.avgResolutionHours,
    deploymentsCompleted: deployData.successful,
    deploymentsFailed: deployData.failed
  },
  highlights: [],
  concerns: []
};
 
// Auto-detect highlights
if (report.summary.revenue > salesData.avgDailyRevenue * 1.2) {
  report.highlights.push(
    `Revenue ${Math.round((report.summary.revenue / salesData.avgDailyRevenue - 1) * 100)}% above average`
  );
}
 
// Auto-detect concerns
if (report.summary.deploymentsFailed > 0) {
  report.concerns.push(
    `${report.summary.deploymentsFailed} failed deployments need investigation`
  );
}
 
if (report.summary.avgResolutionTime > 24) {
  report.concerns.push(
    `Support resolution time (${report.summary.avgResolutionTime}h) exceeds 24h SLA`
  );
}
 
return [{ json: report }];

The magic is in the auto-detection of highlights and concerns. Nobody wants to read a wall of numbers every morning. They want to know: "Is anything on fire? Did anything amazing happen?" This pattern answers both questions in the first two lines.

Common Pitfalls and How to Avoid Them

After running n8n in production across multiple clients, these are the mistakes I see over and over.

Pitfall 1: No Execution Data Pruning

n8n stores every execution in the database by default. After a month of heavy usage, your database is 20 GB and queries are slow. Set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=168 (7 days) in your environment. For longer retention, export execution data to a separate analytics database.

Pitfall 2: Using SQLite in Production

I mentioned this earlier but it bears repeating. SQLite will work fine until it doesn't, and when it breaks, it breaks catastrophically. Migrate to PostgreSQL before you have problems, not after.

Pitfall 3: No Error Workflow

If you don't have a global error workflow configured, failures are silent. You'll find out about them when someone asks "why didn't this happen?" days later. Set up the error workflow on day one.

Pitfall 4: Hardcoded Credentials

Never put API keys directly in Function node code. Use n8n's credential system or environment variables. I've seen workflow exports with production API keys committed to public Git repositories. Don't be that person.

Pitfall 5: Ignoring Webhook Authentication

Every public webhook URL will be discovered by bots within hours. No authentication means anyone can trigger your workflows with arbitrary data. At minimum, validate a shared secret. Ideally, implement full HMAC signature verification.

Pitfall 6: Processing Everything in Memory

Loading 500,000 records into a single workflow execution will crash n8n. Always paginate API responses, batch database queries, and process data in chunks. If you can't reduce the dataset size, use queue mode with workers to distribute the load.

Pitfall 7: No Staging Environment

Testing changes directly in production is how you break things on a Friday afternoon. Run a separate staging n8n instance. It costs $12/month on a small VPS. That's cheaper than any production incident.

Security Hardening for Self-Hosted Instances

Self-hosting gives you control, but control comes with responsibility. Here's the security checklist for production n8n deployments.

Reverse Proxy with TLS

Never expose n8n directly to the internet. Put it behind a reverse proxy with TLS termination:

nginx

# nginx configuration for n8n
server {
    listen 443 ssl http2;
    server_name n8n.yourdomain.com;
 
    ssl_certificate /etc/letsencrypt/live/n8n.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.yourdomain.com/privkey.pem;
 
    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
 
    # Rate limiting
    limit_req_zone $binary_remote_addr zone=n8n_limit:10m rate=30r/m;
 
    location / {
        limit_req zone=n8n_limit burst=10 nodelay;
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
 
        # WebSocket support for the editor
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
 
    # Restrict webhook access if possible
    location /webhook/ {
        limit_req zone=n8n_limit burst=50 nodelay;
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Disable Public Registration

After creating your admin account, disable public registration:

yaml

environment:
  - N8N_USER_MANAGEMENT_DISABLED=false
  - N8N_PUBLIC_API_DISABLED=false  # Keep API for automation
  # Remove or don't set N8N_BASIC_AUTH if using user management

Network Segmentation

n8n should only be accessible from your internal network or through the reverse proxy. Use Docker networks and firewall rules to prevent direct access:

yaml

# In docker-compose.yml, don't expose port 5678 to the host
services:
  n8n:
    # Remove the ports mapping entirely
    # ports:
    #   - "5678:5678"
    networks:
      - internal
      - proxy
 
  nginx:
    ports:
      - "443:443"
    networks:
      - proxy
 
networks:
  internal:
    internal: true  # No external access
  proxy:
    driver: bridge

Now n8n is only accessible through nginx. No one can bypass the proxy to hit n8n directly.

Regular Updates

n8n releases security patches regularly. Stay current. Pin to a specific version in production (don't use latest), but review and update monthly:

yaml

services:
  n8n:
    image: n8nio/n8n:1.72.1  # Pin to specific version

Check the n8n changelog before updating. Breaking changes happen, and you want to catch them in staging before they hit production.

Summary

Building production n8n workflows isn't about dragging more nodes onto a canvas. It's about the invisible architecture: error handling that catches failures before your customers do, security that protects your data, monitoring that tells you what's happening at 3 AM, and performance tuning that keeps everything running smoothly as you scale.

The patterns in this guide come from real production systems. They've been refined through actual outages, real security audits, and genuine scaling challenges. None of them are theoretical.

Start with the basics: PostgreSQL backend, error workflows, webhook authentication. Then layer on batch processing, credential management, and monitoring as your workflow count grows. By the time you need queue mode and worker scaling, you'll have the operational foundation to support it.

n8n gives you the flexibility to build automations that rival custom code without the deployment overhead. But flexibility without discipline is just a different kind of chaos. Apply these patterns, and your automations will be the most reliable part of your infrastructure.

That's not a bad place to be.

Why n8n Over Zapier, Make, or Custom Code

Self-Hosting and Data Sovereignty

Cost at Scale

Code When You Need It

The Visual Builder Is Actually Good

Self-Hosting Architecture

Docker Compose Setup

Resource Sizing

PostgreSQL Backend: Why It Matters

Error Handling That Actually Works

Try/Catch in Function Nodes

Error Workflows

Retry Logic with Exponential Backoff

Dead Letter Queues

Webhook Security

HMAC Signature Validation

IP Whitelisting

Rate Limiting

Batch Processing Patterns

Smart Batching with Rate Limiting

Progress Tracking

Credential Management

Environment Variables Over Hardcoded Values

External Secret Stores

Credential Encryption Key Rotation

Sub-Workflow Patterns

Building Reusable Sub-Workflows

Passing Data Between Workflows

Database Integration Patterns

PostgreSQL for Persistent State

Redis for Caching

Monitoring and Alerting

Error Notification Workflow

Execution Metrics

Health Check Endpoint

Performance Optimization

Memory Management

Queue Mode and Worker Scaling

Concurrency Control

Version Control for Workflows

Export/Import Pipeline

Promoting Workflows Between Environments

Real Production Patterns

CRM Sync Pipeline

Invoice Processing

Automated Reporting

Common Pitfalls and How to Avoid Them

Pitfall 1: No Execution Data Pruning

Pitfall 2: Using SQLite in Production

Pitfall 3: No Error Workflow

Pitfall 4: Hardcoded Credentials

Pitfall 5: Ignoring Webhook Authentication

Pitfall 6: Processing Everything in Memory

Pitfall 7: No Staging Environment

Security Hardening for Self-Hosted Instances

Reverse Proxy with TLS

Disable Public Registration

Network Segmentation

Regular Updates

Summary

Need help implementing this?