N8n

Introduction TL;DR: This post shows how to use n8n in production with three workflows: (1) Webhook ingestion with GitHub signature verification, (2) scheduled API ingestion with pagination + batching, and (3) standardized error workflows with Error Trigger and Stop And Error. n8n workflows are easier to operate when you design security (auth/signature), responses, and observability up front. Workflow 1: GitHub Webhook → Signature Verification → Slack → Response Key design points Enable Raw Body in the Webhook node so you can verify signatures using the exact payload. GitHub uses X-Hub-Signature-256 (HMAC-SHA256), signatures start with sha256=, and constant-time comparison is recommended. Use Respond to Webhook to control 200 vs 401 responses from your workflow. Why it matters: Webhooks are public entry points. Validating signatures prevents processing spoofed/tampered deliveries and reduces wasted compute. ...

Introduction TL;DR: Use Webhook triggers and normalize payloads early with Set, then process/merge/notify with minimal Code. Treat failures as first-class: Error Trigger + Error Workflow, and intentionally fail with Stop And Error when business rules break. Scale reliably with queue mode (Redis + Postgres), lock your encryption key, and enable metrics/audits for operations. In production, n8n isn’t about “making workflows run once.” It’s about building repeatable, observable automation around webhooks, error handling, batching, and scaling. ...

Introduction TL;DR: This post focuses on production-grade n8n self-hosting. We cover Docker Compose templates (single & queue mode), Postgres/Redis, reverse proxy TLS, webhook URL correctness, backups, and monitoring. In practice, most self-hosting incidents come from URL/webhook mismatch, lost encryption keys, and runaway execution data growth. We’ll harden those first. 1) Design decisions that matter in production n8n defaults to SQLite for credentials, executions, and workflows, and supports Postgres for self-hosted setups. n8n’s database environment variable docs also state that MySQL/MariaDB support was deprecated in v1.0, so Postgres is the safe default for new deployments. ...