标签：#n8n

n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job. How much server it actually needs Honest numbers first, so you don't over- or under-buy: ~2 GB RAM is the sweet spot — n8n plus its Postgres database plus normal workflows sit comfortably here. 1 GB works if your workflows are light, but you'll notice it on bigger runs. 4 GB if you do heavy parallel executions or push large payloads through. n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide .) The Docker setup On a fresh Ubuntu/Debian box, install Docker: curl -fsSL https://get.docker.com | sudo sh Make a folder and a docker-compose.yml — n8n with a persistent volume and Postgres: services : n8n : image : docker.n8n.io/n8nio/n8n restart : always ports : - " 127.0.0.1:5678:5678" environment : - N8N_HOST=n8n.yourdomain.com - N8N_PROTOCOL=https - WEBHOOK_URL=https://n8n.yourdomain.com/ - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=db - DB_POSTGRESDB_PASSWORD=change-me volumes : - ./n8n-data:/home/node/.n8n depends_on : [ db ] db : image : postgres:16 restart : always environment : - POSTGRES_PASSWORD=change-me - POSTGRES_DB=n8n volumes : - ./db-data:/var/lib/postgresql/data sudo docker compose up -d Two things worth pointing out: the volumes ( n8n-data , db-data ) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1 , not 0.0.0.0 — it's not exposed to the internet directly. That's deliberate; the next step handles access safely. Access: HTTPS or a tunnel Public URL (needed for OAuth nodes and webhooks): point a subdomain at the server and run

For 13 years I have worked in production at a steel-tube manufacturer. Not in an office — on the floor, with the machines, the night shifts, the handovers at 6 a.m. A few years ago I started building software in my free time. Not tutorials for their own sake — tools that solve problems I actually see every day. Why a factory worker writes code In production you learn one thing fast: it does not matter what looks good on a slide. It matters what works at shift handover. That perspective turned out to be my biggest advantage as a self-taught developer — I know the problem before I write the first line. What I have built PIPEZ — a shift & part-count PWA. Offline-capable, running on Cloudflare Workers + D1, live in production to capture shift and piece-count data that used to live on paper. A tool-management app. A multi-user client-server app with optimistic concurrency and a local AI assistant, used daily in the office to manage the lifecycle of dies in tube production. DeepCode — an agentic AI coding client. Electron + React + TypeScript, with its own tool loop, a swarm mode, and CI/tests. The project I am proudest of. Plus multi-agent systems, RAG pipelines, and n8n automations that run every day. The stack Python/FastAPI, TypeScript/React, Node, Docker, PostgreSQL + pgvector, Cloudflare Workers, MCP, computer vision. Writing in public I will be writing here about the bridge I keep coming back to: real production experience plus building with AI. If you are automating something messy and real, I would love to compare notes.

The first two articles in this series each showed one technique. Implementation notes #001 was a dynamic dropdown — a form field that fills itself from an API. Implementation notes #002 was a dynamic credential — an API key that arrives from the form and threads through to the HTTP nodes. This article is the capstone. It walks through all-services-demo , the example workflow that ships with n8n-nodes-ldxhub , where those two techniques combine with a Switch node to host five different AI document-processing services inside one workflow — structured extraction, translation refinement, OCR, PDF conversion, and text extraction. The screenshots and the workflow JSON below come from the n8n-nodes-ldxhub package. The patterns themselves are generic — they work for any set of services you want to consolidate into a single template. This is not a "follow these steps" article. It's a parts catalog. No two readers are solving the same problem, and templates rarely fit anyone's situation as-is. Take what fits. Drop the rest. You don't need to understand all 46 nodes to reuse the patterns. The shape The workflow has 46 nodes — large enough to look intimidating in the editor, but structurally it's just five repeated paths plus a small routing section. The entry section is two nodes: On form submission — the trigger. Asks the user which service they want and collects an API key. Route by Service — a Switch node with five outputs, one per service. Everything to the right of the Switch is service-specific. Five paths fan out: StructFlow, RefineLoop, RenderOCR, CastDoc, ExtractDoc. Each path ends in two Form Ending nodes — one for success (auto-downloads the result), one for error. That's the spine: form → switch → service path → ending. The complexity is pushed into the service paths. The spine: routing by static comparison The Switch node ("Route by Service") uses Rules mode. Each rule reads the same expression from the form — {{ $json.service }} — and compares it to a static serv

You built a workflow worth sharing — and it works perfectly. Until someone else imports it. The bottleneck is the API key. Use yours, and every user is billed against your account. Use theirs, and they each have to find the credential UI, paste their key, and reconnect every time. Both are friction. The cleaner option is to let the workflow ask for the key on the form, then thread it through to the HTTP nodes that need it. It's simpler than it sounds. This post walks through the pattern with a working credential setup, an alternative for single-node simple cases, the gotchas, and a note on what this enables for custom node authors. The screenshots below come from n8n's built-in Bearer Auth credential and from the n8n-nodes-ldxhub package's own credential schema. The technique itself is generic — what's shown here works for any HTTP-node workflow and any custom node that supports expression-mode credentials. The form asks, the credential listens The simplest case: a Form Trigger collects an API key, then an HTTP node hits an authenticated endpoint with that key. Two nodes, one bridge between them — but the bridge isn't a direct expression. It runs through a credential. The flow: Form Trigger collects api_key (use the Password element type for masking) A Bearer Auth credential references that form input via expression HTTP node picks the credential The Form Trigger is straightforward. Add one field: Form Trigger Form Fields : - Label : API Key - Element Type : Password - Custom Field Name : api_key - Required Field : yes Element type matters. Use Password instead of Text and the input gets masked on screen — the key isn't readable to someone glancing at the browser. Here's the rendered form a user sees when they open the workflow URL: Wiring the credential to expression mode For a Bearer token (which is what most modern APIs use), create a new credential of type Bearer Auth — a generic credential built into n8n that's purpose-built for Authorization: Bearer ... header

In the hyper-competitive landscape of modern B2B outbound sales, speed-to-lead and outreach capacity are the ultimate drivers of pipeline volume . Yet, traditional Sales Development Representative (SDR) teams face a exhausting bottleneck: reaches and qualifications are limited by human bandwidth . A typical outbound SDR spends up to 80% of their day dialing numbers, navigating IVR phone trees, hitting voicemail, and dealing with incorrect contact records. When an inbound lead submits a form requesting a product demo, the average company takes 42 minutes to respond. By that time, prospect engagement has cooled by over 400%. To shatter this operational limit, modern revenue operations (RevOps) teams are transitioning from rigid auto-dialers and static voice bots to autonomous voice AI sales agents . By pairing the hyper-realistic conversational engine of ElevenLabs with the visual orchestration power of n8n , you can deploy a scalable, context-aware calling agent that handles inbound qualification and outbound follow-up calls in real-time. This technical blueprint provides an end-to-end guide to designing, securing, and deploying a production-grade Voice AI Sales Agent using ElevenLabs Conversational AI and n8n . We will cover how to manage conversation state, execute live database tool calls, secure webhook communication, route calls dynamically, and configure infrastructure to achieve sub-second response latency . The Architecture of an Enterprise Voice Agent Building a conversational voice agent requires a multi-layered system that operates in near real-time. When a human speaks over a telephony network, their voice must be digitized, transcribed, processed by a large language model (LLM), synthesized back into audio, and sent back down the line—all within a fraction of a second. To ensure stability, scalability, and absolute separation of concerns, our architecture decouples the telephony and voice generation layer from the logic and database integration layer . [

Every time a course batch completes, you have a list of students who need certificates. The manual way: open Canva, duplicate the template, change the name, export, repeat — for every single student. If you have 10 students, that's annoying. If you have 200, that's a full afternoon. The better way A single n8n workflow that: Reads student names from Google Sheets Calls the RenderPix batch API Gets back 200 certificate images Emails each student their certificate Total time: ~2.5 minutes. Total manual work: zero. What you'll need A RenderPix account (free tier works for testing, Starter plan for production) n8n (self-hosted or cloud) n8n-nodes-renderpix community node A Google Sheet with student data Install the n8n node: npm install n8n-nodes-renderpix Or search "RenderPix" in n8n's community node panel. Step 1 — Design your certificate template Write your certificate in plain HTML. Here's a clean starting point: <div style= "width:1200px;height:850px;background:white; display:flex;flex-direction:column;align-items:center; justify-content:center;border:20px solid #0f172a; font-family:Georgia,serif;padding:60px;box-sizing:border-box" > <div style= "font-size:16px;letter-spacing:5px;color:#64748b; text-transform:uppercase;margin-bottom:24px" > Certificate of Completion </div> <div style= "width:80px;height:2px;background:#22d3ee;margin-bottom:32px" ></div> <div style= "font-size:52px;font-weight:700;color:#0f172a;margin-bottom:16px" > {{name}} </div> <div style= "font-size:18px;color:#475569;text-align:center;max-width:600px" > has successfully completed </div> <div style= "font-size:28px;font-weight:600;color:#1e293b;margin:16px 0 40px" > {{course}} </div> <div style= "font-size:14px;color:#94a3b8" > {{date}} </div> </div> Notice the {{name}} , {{course}} , {{date}} placeholders — RenderPix replaces these at render time. Step 2 — Set up Google Sheets Create a sheet with these columns: name course date Jane Smith Advanced n8n Automation June 2026 John Doe Advanced n8n