Forem: Raizan

Airflow vs n8n vs Temporal for API workflows

Raizan — Tue, 26 May 2026 08:00:34 +0000

What You'll Need

n8n Cloud or self-hosted n8n instance
Hetzner VPS or Contabo VPS for self-hosting options
Namecheap for custom domain setup
DigitalOcean as an alternative cloud provider
Basic knowledge of REST APIs and webhook concepts
Docker (optional, for containerized deployments)

Why This Comparison Matters
Understanding Airflow, n8n, and Temporal
Architecture & Deployment Models
Building Your First API Workflow
Real-World API Integration Examples
Performance & Scalability Showdown
Cost Analysis & ROI
Getting Started

Why This Comparison Matters

I've built dozens of API workflows over the past five years, and I can tell you that choosing the wrong orchestration tool early costs you thousands in refactoring later. Airflow, n8n, and Temporal each solve the same fundamental problem—executing sequences of API calls reliably—but they approach it from completely different angles.

The stakes are real. You might choose Airflow because it's industry-standard, only to discover you're managing YAML configuration hell. Or you pick n8n for its visual builder and later hit scaling walls that shouldn't exist. Temporal offers rock-solid reliability but requires serious DevOps muscle.

This guide cuts through the noise. I'm comparing these three on what actually matters when you're building production API workflows: setup time, reliability, costs, and the mental overhead of maintenance.

Understanding Airflow, n8n, and Temporal

Let me break down what each tool actually does, not the marketing speak.

Apache Airflow is a task orchestration platform built on Python. It treats workflows as directed acyclic graphs (DAGs) where each node is a task. You define everything in Python code, giving you maximum flexibility but requiring real programming chops.

n8n is a node-based workflow automation platform with a web UI. You drag nodes together, connect them with wire logic, and ship. It's built on Node.js and emphasizes visual workflow design over code. I've used n8n for everything from Slack bots to API data pipelines.

Temporal is a microservices orchestration engine designed for durable execution. It's language-agnostic (runs Go, Python, Java, TypeScript) and built for workflows that can survive infrastructure failures. Think of it as a state machine on steroids.

Each targets a different user persona:

Airflow: Data engineers managing complex ETL pipelines
n8n: No-code users and teams needing fast API integrations
Temporal: Teams building distributed systems where reliability is non-negotiable

Architecture & Deployment Models

Here's where deployment realities force your hand.

Airflow's Architecture

Airflow runs as three core components:

Scheduler – reads DAGs from disk, creates task instances, triggers them
Executor – runs the actual tasks (local, Kubernetes, Celery, etc.)
Web UI – lets you monitor and trigger runs

When you self-host Airflow on a Hetzner VPS or Contabo VPS, you need:

# Install Airflow (Python 3.9+)
pip install apache-airflow==2.7.3

# Initialize the database
airflow db init

# Create a default admin user
airflow users create \
  --username admin \
  --firstname Admin \
  --lastname User \
  --role Admin \
  --email admin@example.com \
  --password airflow

# Start the web server (runs on port 8080)
airflow webserver

# In another terminal, start the scheduler
airflow scheduler

This setup requires a PostgreSQL or MySQL backend (SQLite won't cut it for production). You're managing stateful services, database migrations, and scheduler high availability yourself.

n8n's Architecture

n8n runs as a single Node.js application with a SQLite or PostgreSQL database backing it. One container, one process. When I deploy n8n Cloud, it just works:

# Docker Compose deployment (self-hosted)
version: '3.8'
services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - DB_TYPE=postgres
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=secure_password_here
      - N8N_HOST=workflow.example.com
      - N8N_PROTOCOL=https
      - NODE_ENV=production
    ports:
      - "5678:5678"
    depends_on:
      - postgres
    volumes:
      - n8n_storage:/home/node/.n8n
    restart: unless-stopped

  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: secure_password_here
    volumes:
      - postgres_storage:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  n8n_storage:
  postgres_storage:

Deploy this to DigitalOcean or a Hetzner VPS, point your domain from Namecheap, and you're live in 20 minutes. The entire workflow state is stored in the database, so you can scale horizontally by spinning up multiple n8n containers behind a load balancer.

Temporal's Architecture

Temporal requires a dedicated cluster. You deploy:

Temporal Server – manages workflow state, task queues, and history
Worker Processes – execute your workflow code
UI – visibility into executions

# Using docker-compose for local Temporal development
version: '3.8'
services:
  temporal:
    image: temporalio/auto-setup:latest
    environment:
      DB: postgres
      DB_PORT: 5432
      POSTGRES_USER: temporal
      POSTGRES_PASSWORD: temporal
      POSTGRES_DB: temporal
    ports:
      - "7233:7233"
      - "6933:6933"
    depends_on:
      - postgres

  temporal-ui:
    image: temporalio/ui:latest
    ports:
      - "8080:8080"
    environment:
      TEMPORAL_ADDRESS: temporal:7233
    depends_on:
      - temporal

  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: temporal
      POSTGRES_PASSWORD: temporal
      POSTGRES_DB: temporal
    volumes:
      - postgres_temporal:/var/lib/postgresql/data

volumes:
  postgres_temporal:

Temporal is stateful and database-heavy. You need dedicated infrastructure to run it. But once running, it handles workflow durability—if your worker crashes mid-API call, Temporal remembers where you were and retries seamlessly.

Building Your First API Workflow

Let me show you how to build the same workflow in all three tools: fetch data from an API, transform it, and send it to another API.

Airflow Approach

from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.bash import BashOperator
from datetime import datetime, timedelta
import requests
import json

default_args = {
    'owner': 'data_team',
    'retries': 2,
    'retry_delay': timedelta(minutes=5),
    'start_date': datetime(2024, 1, 1),
}

def fetch_user_data(**context):
    """Fetch user data from JSONPlaceholder API"""
    response = requests.get('https://jsonplaceholder.typicode.com/users/1')
    response.raise_for_status()
    user_data = response.json()
    context['task_instance'].xcom_push(key='user_data', value=user_data)
    return user_data

def transform_user_data(**context):
    """Extract and transform relevant fields"""
    user_data = context['task_instance'].xcom_pull(
        task_ids='fetch_user_data',
        key='user_data'
    )
    transformed = {
        'id': user_data['id'],
        'name': user_data['name'],
        'email': user_data['email'],
        'company': user_data['company']['name'],
        'processed_at': datetime.now().isoformat()
    }
    context['task_instance'].xcom_push(
        key='transformed_data',
        value=transformed
    )
    return transformed

def send_to_webhook(**context):
    """Send transformed data to external API"""
    transformed_data = context['task_instance'].xcom_pull(
        task_ids='transform_user_data',
        key='transformed_data'
    )
    webhook_url = 'https://webhook.site/your-unique-id'
    response = requests.post(
        webhook_url,
        json=transformed_data,
        headers={'Content-Type': 'application/json'}
    )
    response.raise_for_status()
    return f"Data sent successfully: {response.status_code}"

dag = DAG(
    'api_workflow_example',
    default_args=default_args,
    description='Fetch, transform, and send API data',
    schedule_interval=timedelta(hours=1),
    catchup=False,
)

task_fetch = PythonOperator(
    task_id='fetch_user_data',
    python_callable=fetch_user_data,
    dag=dag,
)

task_transform = PythonOperator(
    task_id='transform_user_data',
    python_callable=transform_user_data,
    dag=dag,
)

task_send = PythonOperator(
    task_id='send_to_webhook',
    python_callable=send_to_webhook,
    dag=dag,
)

task_fetch >> task_transform >> task_send

This DAG runs hourly, with automatic retries if tasks fail. You manage it via the Airflow UI or CLI. One gotcha: data between tasks flows through XCom (cross-communication), which isn't meant for large payloads. For bigger data, you'd write to S3 or a database.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

n8n Approach

In n8n, you'd build this visually, but here's the JSON configuration export:

{
  "name": "API Data Pipeline",
  "nodes": [
    {
      "parameters": {
        "triggerTimes": {
          "item": [
            {
              "mode": "everyHour"
            }
          ]
        }
      },
      "id": "schedule_trigger",
      "name": "Schedule Trigger",
      "type": "n8n-nodes-base.cron",
      "typeVersion": 1,
      "position": [250, 300]
    },
    {
      "parameters":

Originally published on Automation Insider.

Build Custom Webhooks Without Coding Tools

Raizan — Mon, 25 May 2026 08:00:36 +0000

What You'll Need

n8n Cloud or self-hosted n8n
Hetzner VPS or Contabo VPS for hosting (optional, for self-hosted)
Namecheap if you need a custom domain
DigitalOcean as an alternative hosting provider

What You'll Need
Understanding Webhooks Without the Code
Setting Up Your First Webhook Receiver
Building Webhook Workflows That React to Data
Transforming and Routing Webhook Payloads
Testing Your Webhooks in Production
Getting Started

Understanding Webhooks Without the Code

I've spent the last three years building automation systems, and here's what I've learned: webhooks are the nervous system of any modern workflow. They're how your apps talk to each other in real-time without polling databases constantly.

Most people think you need to write code to handle webhooks. You don't. Not anymore.

A webhook is just an HTTP request—typically POST or GET—sent from one application to another when something happens. Your Shopify store processes an order, it sends a webhook. Someone fills out your form, it fires a webhook. Your payment processor confirms a transaction, webhook. All of these can trigger downstream actions without touching a single line of code.

The old way required you to spin up a server, write endpoint handlers, manage SSL certificates, and pray your error handling caught edge cases. n8n Cloud flips this entirely. You get a webhook URL instantly, point any service at it, and build logic visually.

When you're comparing automation platforms—and if you're evaluating options, I'd recommend reading about Make vs n8n vs Zapier API integrations 2026—you'll notice n8n gives you the most control over webhook behavior without forcing you into the paid tiers for custom logic.

Setting Up Your First Webhook Receiver

Let me walk you through creating a webhook that listens for incoming data.

Log into n8n Cloud. Click "New" and start a blank workflow.

In the left sidebar, search for the "Webhook" node. Drag it onto your canvas. This is your listening post.

Here's what you'll see in the node settings:

{
  "method": "POST",
  "path": "webhook/my-first-webhook",
  "responseCode": 200,
  "responseData": "success",
  "nodeCredentialType": "httpBasicAuth",
  "authentication": "none"
}

That path becomes part of your unique webhook URL. If your n8n instance lives at https://n8n.chasebot.online, your webhook lands at https://n8n.chasebot.online/webhook/my-first-webhook.

Leave authentication as "none" for now—we'll secure it later. Click the "Webhook" node again and you'll see a blue button that says "Execute Webhook". Click it, and n8n generates a unique, testable URL.

Now add a second node: search for "Set" in the left sidebar. Connect the Webhook node to Set by dragging the output dot. In the Set node, you're going to map the incoming webhook data to fields you want to use downstream.

The webhook payload arrives as $json in n8n. Here's what that configuration looks like:

{
  "assignments": [
    {
      "name": "incoming_email",
      "value": "{{ $json.body.email }}",
      "type": "string"
    },
    {
      "name": "incoming_name",
      "value": "{{ $json.body.name }}",
      "type": "string"
    },
    {
      "name": "incoming_timestamp",
      "value": "{{ $json.headers['x-timestamp'] }}",
      "type": "string"
    }
  ]
}

The dollar-sign syntax is n8n's expression language. $json.body.email pulls the email field from whatever JSON was sent to your webhook. $json.headers grabs HTTP headers.

Now test it. In n8n Cloud, click the blue "Execute Webhook" button and copy the URL. Open a new browser tab and use an online webhook testing tool (RequestBin, Webhook.cool, or even curl from your terminal):

curl -X POST https://webhook.n8n.cloud/[YOUR-UNIQUE-URL] \
  -H "Content-Type: application/json" \
  -d '{"name":"Sarah Chen","email":"sarah@example.com"}'

Watch your n8n workflow execute. You'll see the data flow through the Webhook node, then the Set node transforms it. That's it. No server. No code. No DevOps nightmare.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Building Webhook Workflows That React to Data

Now that you have incoming data, let's do something with it.

I'm going to show you a real workflow: receiving a webhook from a form submission, then triggering different actions based on what's in the payload.

Start fresh. Add a Webhook node. This time, in the node settings, click "Add Field" under "Request Body Schema". Manually define the shape of data you expect:

{
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "description": "User email address"
    },
    "product_id": {
      "type": "string",
      "description": "Which product was clicked"
    },
    "source": {
      "type": "string",
      "enum": ["web", "mobile", "api"],
      "description": "Where the request came from"
    }
  },
  "required": ["email", "product_id"]
}

This schema validates incoming webhooks. If someone sends a webhook without email and product_id, n8n rejects it with a 400 error and logs the mismatch. This saves you from garbage data tanking your downstream workflow.

Next, add a conditional node. Search for "If" in the left sidebar. Connect the Webhook output to it.

In the If node, set up a condition:

{
  "conditions": [
    {
      "value1": "{{ $json.source }}",
      "operation": "equals",
      "value2": "mobile"
    }
  ],
  "combineOperation": "any"
}

This branches your workflow: if the source is "mobile", take the true branch; otherwise, take the false branch.

From the true branch, add a node that sends a Slack message (search for "Slack" in the node library and authenticate with your workspace). Connect it to the true output of your If node:

{
  "channel": "#sales-alerts",
  "text": "📱 Mobile signup from {{ $json.email }} – Product: {{ $json.product_id }}",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*Mobile Conversion Alert*\nEmail: {{ $json.email }}\nProduct ID: {{ $json.product_id }}"
      }
    }
  ]
}

From the false branch, add a different Slack message (or any other action—email, database write, webhook forward, etc.).

Deploy this workflow. Now whenever anyone submits a form or triggers an external webhook pointing to your n8n instance, it automatically routes notifications based on the source. Mobile users get flagged in a specific channel. Web users go elsewhere.

This scales to dozens of branches. The visual canvas lets you see the entire logic at once, which beats digging through code files any day.

Transforming and Routing Webhook Payloads

Here's where things get powerful. Many webhooks arrive in messy formats. Your Stripe webhook looks different from your Shopify webhook. Your custom app payload doesn't match your form plugin's structure.

You need to normalize them.

Add a "Function" node (search for it in the node library). This is JavaScript you can write without leaving the visual interface. Don't worry—it's sandboxed and forgiving.

Here's a practical example: you're receiving webhooks from multiple sources, and you want to standardize all of them into a single format before storing them in a database:

const sourceType = $json.source_system || 'unknown';
const timestamp = new Date().toISOString();

let standardizedPayload = {
  id: generateId(),
  source: sourceType,
  receivedAt: timestamp,
  data: {}
};

if (sourceType === 'shopify') {
  standardizedPayload.data = {
    customerId: $json.customer_id,
    orderId: $json.order_id,
    total: $json.total_price,
    email: $json.customer_email,
    createdAt: $json.created_at
  };
} else if (sourceType === 'stripe') {
  standardizedPayload.data = {
    customerId: $json.customer,
    orderId: $json.id,
    total: $json.amount / 100,
    email: $json.metadata?.email || null,
    createdAt: new Date($json.created * 1000).toISOString()
  };
} else if (sourceType === 'custom_form') {
  standardizedPayload.data = {
    customerId: $json.user_id,
    orderId: $json.submission_id,
    total: parseFloat($json.price) || 0,
    email: $json.email_address,
    createdAt: $json.timestamp
  };
}

function generateId() {
  return 'evt_' + Math.random().toString(36).substr(2, 9);
}

return standardizedPayload;

After this Function node runs, every webhook—whether it came from Shopify, Stripe, or your custom form—exits with the same structure:

{
  "id": "evt_a1b2c3d4e",
  "source": "shopify",
  "receivedAt": "2024-01-15T14:32:00.000Z",
  "data": {
    "customerId": "cust_12345",
    "orderId": "order_67890",
    "total": 99.99,
    "email": "user@example.com",
    "createdAt": "2024-01-15T14:31:00.000Z"
  }
}

Now you can connect this to a single database write, a single API call, or a single downstream workflow—no branching logic needed. One format in, one action out.

This is where the power emerges. If you're running multiple systems on limited resources—and if you're interested in optimization, I wrote about How I Run 3 Automated Systems on a Single $7/Month VPS—normalizing payloads at the webhook layer saves you compute cycles throughout your entire architecture.

Testing Your Webhooks in Production

You can't debug what you can't see. Before pushing a webhook workflow live, you need visibility.

n8n Cloud has built-in execution history. Every time a webhook fires, n8n logs the input, the transformations, and the output. Click on any execution and drill into each node to see exactly what data passed through.

For manual testing before going live, use the "Execute Webhook"

Originally published on Automation Insider.

Best n8n Alternatives for API-First Developers 2026

Raizan — Sun, 24 May 2026 08:00:42 +0000

What You'll Need

n8n Cloud or self-hosted n8n instance
Hetzner VPS or Contabo VPS for hosting alternatives
DigitalOcean as a managed infrastructure option
API credentials for at least one service (GitHub, Stripe, Slack, etc.)
Node.js 16+ or Docker installed locally (optional, for testing)
A code editor like VS Code

Why Developers Are Moving Beyond n8n
The API-First Workflow Automation Landscape
Top n8n Alternatives for API-Driven Teams
Building Your First Workflow: n8n vs. Zapier vs. Temporal
Hosting & Infrastructure Decisions
Getting Started with Your Choice

Why Developers Are Moving Beyond n8n

I've been in the workflow automation space for years, and I'm seeing a real shift in 2026. n8n is solid—open-source, self-hosted, powerful integrations—but it's not always the right fit for every team. Some developers need stronger database support. Others want native async/await patterns. A few want orchestration at the enterprise level without the overhead.

The landscape has matured. We're not just talking about "no-code" tools anymore. Modern API-first developers need platforms that speak their language: REST hooks, webhooks, GraphQL, serverless functions, and event-driven architecture.

I'm going to walk you through the real contenders, show you working code, and help you pick the right tool for your specific use case.

The API-First Workflow Automation Landscape

Before we compare alternatives, let me clarify what "API-first" actually means in this context. You're looking for platforms that:

Expose their own APIs – You can trigger workflows programmatically, not just through UI clicks
Handle async operations natively – No artificial delays or polling nightmares
Support webhooks bidirectionally – Receive and send without gymnastics
Work well with databases – When you need SQLite vs PostgreSQL for Small Projects: When to Use Which, the tool shouldn't force one approach
Scale with your codebase – From a single Lambda function to multi-region deployments

n8n ticks most of these boxes, but the alternatives I'm about to show you each solve specific pain points.

Top n8n Alternatives for API-Driven Teams

1. Temporal: Workflow Orchestration for Serious Infrastructure

Temporal is a durable workflow engine that's absolutely crushing it for infrastructure teams. Unlike n8n, which is GUI-first, Temporal is code-first. You write workflows in TypeScript, Python, or Go, and Temporal handles the orchestration, retries, timeouts, and state management.

When to choose Temporal:

You're running microservices and need workflow reliability
Your team writes code every day (this is your language, not a visual tool)
You need guaranteed execution, not best-effort automation
Scaling to millions of workflow runs annually

When to skip it:

You need quick, simple integrations (overkill)
Your team doesn't code
You want managed infrastructure without Docker/Kubernetes

Here's a real Temporal workflow that processes API requests with retry logic:

import { 
  proxyActivities, 
  retry, 
  ActivityFailureError,
  ApplicationFailure
} from '@temporalio/workflow';
import * as wf from '@temporalio/workflow';

interface PaymentRequest {
  userId: string;
  amount: number;
  currency: string;
  idempotencyKey: string;
}

interface PaymentResult {
  transactionId: string;
  status: 'completed' | 'failed' | 'pending';
  timestamp: string;
}

const activities = proxyActivities<typeof import('./activities')>({
  startToCloseTimeout: '1 minute',
  retry: {
    initialInterval: '1 second',
    maximumInterval: '1 minute',
    maximumAttempts: 5,
    backoffCoefficient: 2.0,
    nonRetryableErrorTypes: ['InvalidPaymentError', 'FraudDetected']
  }
});

export async function paymentWorkflow(
  request: PaymentRequest
): Promise<PaymentResult> {
  let result: PaymentResult;

  try {
    result = await activities.processPaymentWithStripe(request);
  } catch (err) {
    if (err instanceof ApplicationFailure) {
      if (err.type === 'FraudDetected') {
        result = {
          transactionId: '',
          status: 'failed',
          timestamp: new Date().toISOString()
        };
      } else {
        throw err;
      }
    } else {
      throw err;
    }
  }

  if (result.status === 'completed') {
    await activities.sendConfirmationEmail(request.userId, result);
  }

  return result;
}

And the activity implementation (the actual work):

import axios from 'axios';
import nodemailer from 'nodemailer';

interface PaymentRequest {
  userId: string;
  amount: number;
  currency: string;
  idempotencyKey: string;
}

interface PaymentResult {
  transactionId: string;
  status: 'completed' | 'failed' | 'pending';
  timestamp: string;
}

const stripeApiKey = process.env.STRIPE_API_KEY!;
const emailTransporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: parseInt(process.env.SMTP_PORT || '587'),
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

export async function processPaymentWithStripe(
  request: PaymentRequest
): Promise<PaymentResult> {
  const stripeUrl = 'https://api.stripe.com/v1/payment_intents';

  const formData = new URLSearchParams();
  formData.append('amount', String(Math.round(request.amount * 100)));
  formData.append('currency', request.currency.toLowerCase());
  formData.append('idempotency_key', request.idempotencyKey);
  formData.append('description', `Payment for user ${request.userId}`);
  formData.append('automatic_payment_methods[enabled]', 'true');

  const response = await axios.post(stripeUrl, formData, {
    headers: {
      Authorization: `Bearer ${stripeApiKey}`,
      'Content-Type': 'application/x-www-form-urlencoded'
    }
  });

  const stripeStatus = response.data.status;
  let workflowStatus: 'completed' | 'failed' | 'pending' = 'pending';

  if (stripeStatus === 'succeeded') {
    workflowStatus = 'completed';
  } else if (stripeStatus === 'requires_action') {
    workflowStatus = 'pending';
  } else {
    workflowStatus = 'failed';
  }

  return {
    transactionId: response.data.id,
    status: workflowStatus,
    timestamp: new Date().toISOString()
  };
}

export async function sendConfirmationEmail(
  userId: string,
  result: PaymentResult
): Promise<void> {
  await emailTransporter.sendMail({
    from: 'payments@example.com',
    to: `user_${userId}@example.com`,
    subject: 'Payment Confirmation',
    html: `<p>Your payment ${result.transactionId} has been ${result.status}.</p>`
  });
}

This approach gives you full control and observability. Temporal keeps a complete history of every workflow execution, so debugging is transparent.

2. Make.com: The Visual Powerhouse with Deep Integration

Make.com (formerly Integromat) is honestly the closest competitor to n8n for visual workflow building, but it's positioned more as a platform with enterprise features. Where n8n emphasizes self-hosting and open-source, Make emphasizes integrations and managed infrastructure.

Key differences from n8n:

1,000+ pre-built integrations (vs. n8n's 400+)
Scenario execution is slightly faster (optimized infrastructure)
Pricing based on operations, not self-hosting (higher long-term cost if scaling)
Their API is more mature for custom triggers

If you're building Stripe webhooks into HubSpot CRM workflows, Make.com's integration marketplace is genuinely better. But if you need to self-host and customize deeply, n8n wins.

3. Zapier with Custom Actions & API Tools

Zapier isn't "API-first" in the code sense—it's user-friendly first. But for teams that want to delegate workflow management to non-technical staff while maintaining control, Zapier's custom code actions (available on Pro tier and up) are underrated.

You write JavaScript directly in Zapier:

const fetch = require('node-fetch');

async function processWebhookData(zapierData) {
  const stripeApiKey = process.env.stripe_api_key;

  const payload = {
    email: zapierData.email,
    first_name: zapierData.first_name,
    last_name: zapierData.last_name,
    metadata: {
      source: 'zapier_webhook',
      timestamp: new Date().toISOString()
    }
  };

  const response = await fetch('https://api.stripe.com/v1/customers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${stripeApiKey}`,
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: new URLSearchParams(payload).toString()
  });

  const result = await response.json();

  if (!response.ok) {
    throw new Error(`Stripe API error: ${result.error.message}`);
  }

  return {
    customer_id: result.id,
    created: result.created,
    success: true
  };
}

return processWebhookData(inputData);

When Zapier wins:

You want someone non-technical to manage workflows
Integration breadth matters more than customization
You don't mind monthly operational costs
Your workflows are relatively simple

4. Deno Deploy + Fresh: Serverless API Automation

Here's my take: serverless platforms like Deno Deploy, Cloudflare Workers, or AWS Lambda aren't traditional "workflow" tools, but for API-first developers, they're the most natural fit. You write functions, deploy them instantly, and they scale to zero cost when idle.

For handling webhooks and orchestrating APIs, this is increasingly the pattern I see in 2026:

import { serve } from "https://deno.land/std@0.208.0/http/server.ts";

interface WebhookPayload {
  event: string;
  data: {
    customer_id: string;
    amount: number;
    currency: string;
  };
  timestamp: string;
}

interface WorkflowState {
  stripeChargeId: string;
  emailSent: boolean;
  slackNotified: boolean;
}

async function chargeCustomer(customerId: string, amount: number, currency: string): Promise<string> {
  const stripeApiKey = Deno.env.get('STRIPE_SECRET_KEY')!;

  const chargeParams = new URLSearchParams({

Originally published on Automation Insider.

Airflow vs n8n for API-driven data pipelines

Raizan — Sat, 23 May 2026 08:00:25 +0000

What You'll Need

n8n Cloud or self-hosted n8n instance
Hetzner VPS or Contabo VPS for hosting (if self-hosting)
DigitalOcean as an alternative hosting option
Python 3.8+ (for Airflow)
PostgreSQL or MySQL database
Basic understanding of REST APIs and workflow automation concepts

Understanding Airflow and n8n
Architecture and Deployment Models
Building Your First API-Driven Pipeline
Scalability, Performance, and Real-World Considerations
Which One Should You Actually Choose?
Getting Started

Understanding Airflow and n8n

I've spent the last few years building data pipelines, and the Airflow vs n8n question keeps coming up. Both tools solve the same fundamental problem—orchestrating tasks and workflows—but they approach it from completely different angles.

Apache Airflow is a workflow orchestration platform built by Airbnb, now an Apache project. It's written in Python, code-first, and treats workflows as directed acyclic graphs (DAGs). Think of it as a framework for engineers who want maximum control and don't mind writing Python code to define their pipelines.

n8n, on the other hand, is a visual workflow automation platform that's been gaining serious traction. It's node-based, has a browser-friendly UI, and integrates with hundreds of APIs out of the box. You can build complex workflows without touching code, though it supports code nodes when you need them.

For API-driven data pipelines specifically, this distinction matters. A lot.

Architecture and Deployment Models

Here's where the philosophies diverge.

Airflow's Architecture:

Airflow uses a distributed architecture with a scheduler, executor, and metadata database. The scheduler reads your DAGs and decides what to execute. Executors actually run the tasks—you can use the LocalExecutor for development, CeleryExecutor for distributed task queues, or KubernetesExecutor for container-based scaling.

This complexity gives you power. You get fine-grained control over task dependencies, retries, backoffs, and custom operators. But it also means you're responsible for maintaining multiple components.

n8n's Architecture:

n8n runs as a single application (though it supports clustering). It uses a database to store workflow definitions and execution history. There's no separate scheduler/executor split—the application handles orchestration internally. When you deploy n8n Cloud, you're getting fully managed infrastructure. If you self-host on Hetzner VPS or DigitalOcean, it's a single Docker container or Node.js process.

For API-driven pipelines, this matters. n8n's simplicity means you can have a workflow hitting 50 different APIs up and running in an afternoon. Airflow would take longer to set up, but it'd handle 50,000 API calls across thousands of tasks more elegantly at scale.

Building Your First API-Driven Pipeline

Let me show you how both tools handle a common scenario: fetch data from an API, transform it, and save it to a database.

Airflow Approach

In Airflow, you define a DAG in Python:

from datetime import datetime, timedelta
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.bash import BashOperator
import requests
import json
import psycopg2
from psycopg2.extras import execute_values

default_args = {
    'owner': 'data_team',
    'retries': 2,
    'retry_delay': timedelta(minutes=5),
    'start_date': datetime(2024, 1, 1),
}

dag = DAG(
    'fetch_user_data_pipeline',
    default_args=default_args,
    description='Fetch user data from API and store in PostgreSQL',
    schedule_interval='0 */6 * * *',
    catchup=False,
)

def fetch_from_api():
    url = 'https://jsonplaceholder.typicode.com/users'
    try:
        response = requests.get(url, timeout=30)
        response.raise_for_status()
        data = response.json()
        with open('/tmp/user_data.json', 'w') as f:
            json.dump(data, f)
        print(f"Successfully fetched {len(data)} users")
        return len(data)
    except requests.exceptions.RequestException as e:
        print(f"API request failed: {e}")
        raise

def transform_and_validate(ti):
    with open('/tmp/user_data.json', 'r') as f:
        users = json.load(f)

    validated_users = []
    for user in users:
        if all(key in user for key in ['id', 'name', 'email', 'phone']):
            validated_users.append({
                'user_id': user['id'],
                'name': user['name'],
                'email': user['email'],
                'phone': user['phone'],
                'company': user.get('company', {}).get('name', 'Unknown'),
                'fetched_at': datetime.now().isoformat()
            })

    with open('/tmp/validated_users.json', 'w') as f:
        json.dump(validated_users, f)
    print(f"Validated {len(validated_users)} out of {len(users)} users")
    return len(validated_users)

def load_to_database(ti):
    try:
        conn = psycopg2.connect(
            host='localhost',
            database='pipeline_db',
            user='pipeline_user',
            password='secure_password',
            port=5432
        )
        cursor = conn.cursor()

        with open('/tmp/validated_users.json', 'r') as f:
            users = json.load(f)

        insert_query = """
        INSERT INTO users (user_id, name, email, phone, company, fetched_at)
        VALUES %s
        ON CONFLICT (user_id) DO UPDATE SET
            name = EXCLUDED.name,
            email = EXCLUDED.email,
            phone = EXCLUDED.phone,
            company = EXCLUDED.company,
            fetched_at = EXCLUDED.fetched_at
        """

        values = [
            (u['user_id'], u['name'], u['email'], u['phone'], u['company'], u['fetched_at'])
            for u in users
        ]

        execute_values(cursor, insert_query, values)
        conn.commit()
        cursor.close()
        conn.close()
        print(f"Loaded {len(users)} users into database")
        return len(users)
    except psycopg2.Error as e:
        print(f"Database error: {e}")
        raise

task_fetch = PythonOperator(
    task_id='fetch_api_data',
    python_callable=fetch_from_api,
    dag=dag,
)

task_transform = PythonOperator(
    task_id='transform_data',
    python_callable=transform_and_validate,
    dag=dag,
)

task_load = PythonOperator(
    task_id='load_to_postgres',
    python_callable=load_to_database,
    dag=dag,
)

task_cleanup = BashOperator(
    task_id='cleanup_temp_files',
    bash_command='rm -f /tmp/user_data.json /tmp/validated_users.json',
    dag=dag,
)

task_fetch >> task_transform >> task_load >> task_cleanup

This DAG runs every 6 hours, fetches user data from an API, validates it, loads it into PostgreSQL, and cleans up temporary files. If any task fails, Airflow retries it twice with 5-minute delays.

n8n Approach

With n8n, you'd build the same workflow visually, but here's how you'd export and manage it via JSON (which is what n8n stores internally):

{
  "name": "Fetch User Data Pipeline",
  "nodes": [
    {
      "parameters": {
        "triggerType": "interval",
        "unit": "hours",
        "value": 6
      },
      "id": "schedule-trigger",
      "name": "Schedule",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1,
      "position": [250, 300]
    },
    {
      "parameters": {
        "url": "https://jsonplaceholder.typicode.com/users",
        "method": "GET",
        "authentication": "none",
        "responseFormat": "json"
      },
      "id": "http-request-api",
      "name": "Fetch User API",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4,
      "position": [450, 300]
    },
    {
      "parameters": {
        "functionCode": "return items.map(item => {\n  const user = item.json;\n  if (!user.id || !user.name || !user.email || !user.phone) {\n    return null;\n  }\n  return {\n    json: {\n      user_id: user.id,\n      name: user.name,\n      email: user.email,\n      phone: user.phone,\n      company: user.company?.name || 'Unknown',\n      fetched_at: new Date().toISOString()\n    }\n  };\n}).filter(item => item !== null);"
      },
      "id": "code-transform",
      "name": "Transform & Validate",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [650, 300]
    },
    {
      "parameters": {
        "host": "localhost",
        "port": 5432,
        "database": "pipeline_db",
        "user": "pipeline_user",
        "password": "secure_password",
        "ssl": false,
        "query": "INSERT INTO users (user_id, name, email, phone, company, fetched_at) VALUES (@user_id, @name, @email, @phone, @company, @fetched_at) ON CONFLICT (user_id) DO UPDATE SET name=EXCLUDED.name, email=EXCLUDED.email, phone=EXCLUDED.phone, company=EXCLUDED.company, fetched_at=EXCLUDED.fetched_at"
      },
      "id": "postgres-insert",
      "name": "Load to PostgreSQL",
      "type": "n8n-nodes-base.postgres",
      "typeVersion": 2,
      "position": [850, 300]
    }
  ],
  "connections": {
    "schedule-trigger": {
      "main": [[{ "node": "http-request-api", "type": "main", "index": 0 }]]
    },
    "http-request-api": {
      "main": [[{ "node": "code-transform", "type": "main", "index": 0 }]]
    },
    "code-transform": {
      "main": [[{ "node": "postgres-insert", "type": "main", "index": 0 }]]
    }
  },
  "settings": {
    "saveDataErrorExecution": "all",
    "save

Originally published on Automation Insider.

Temporal vs n8n vs Airflow for Data Pipelines

Raizan — Thu, 21 May 2026 08:00:41 +0000

What You'll Need

n8n Cloud or self-hosted n8n
Hetzner VPS or Contabo VPS for hosting
DigitalOcean as alternative
Python 3.8+ (for Airflow and Temporal)
Docker and Docker Compose
Git for version control

What You'll Need
The Big Picture: Why This Matters
Temporal: The Enterprise-Grade Workflow Engine
n8n: The Visual Automation Platform
Apache Airflow: The Python-Native Orchestrator
Head-to-Head Comparison
Getting Started with Your First Pipeline
Choosing the Right Tool for Your Use Case

The Big Picture: Why This Matters

I've built data pipelines for everything from real-time market data ingestion to batch processing infrastructure. The question I get asked most isn't "which tool is best?" but rather "which tool is best for what I'm trying to do?" These three platforms—Temporal, n8n, and Apache Airflow—solve workflow automation problems, but they approach it from completely different angles.

The choice you make affects deployment complexity, team learning curve, scalability, and your operational overhead. Get it wrong, and you're either over-engineering a simple automation or struggling with a tool that wasn't designed for your scale.

Temporal: The Enterprise-Grade Workflow Engine

Temporal is built for distributed systems that need bulletproof reliability and auditing. It's what you reach for when "the job must complete, no matter what," and you need a complete execution history for compliance.

How Temporal Works:

Temporal separates your business logic (Workflows) from the execution engine. You write code in TypeScript, Go, Python, or Java, and Temporal handles retries, timeouts, and failure recovery automatically. It's built on a novel idea: every decision in your workflow is deterministic and replayed through the same code path.

Here's a minimal TypeScript workflow that processes orders with built-in failure handling:

import { proxyActivities, defineSignal, defineQuery, setHandler } from '@temporalio/workflow';
import type * as activities from './activities';

const { processPayment, notifyUser, logOrder } = proxyActivities<typeof activities>({
  startToCloseTimeout: '5 minutes',
});

export interface OrderInput {
  orderId: string;
  amount: number;
  email: string;
  retryCount: number;
}

export async function orderProcessingWorkflow(input: OrderInput) {
  let attempts = 0;
  const maxRetries = 3;

  while (attempts < maxRetries) {
    try {
      const paymentResult = await processPayment({
        orderId: input.orderId,
        amount: input.amount,
      });

      if (paymentResult.success) {
        await logOrder({
          orderId: input.orderId,
          status: 'completed',
          paidAmount: input.amount,
        });

        await notifyUser({
          email: input.email,
          message: `Your order ${input.orderId} has been processed successfully`,
        });

        return { status: 'success', orderId: input.orderId };
      }
    } catch (error) {
      attempts++;
      if (attempts >= maxRetries) {
        await notifyUser({
          email: input.email,
          message: `Order ${input.orderId} failed after ${maxRetries} attempts`,
        });
        throw new Error(`Payment processing failed for order ${input.orderId}`);
      }
    }
  }
}

And the corresponding activities (the actual work):

export async function processPayment(params: {
  orderId: string;
  amount: number;
}): Promise<{ success: boolean; transactionId: string }> {
  const response = await fetch('https://api.payment-provider.com/charge', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.PAYMENT_API_KEY}` },
    body: JSON.stringify({
      orderId: params.orderId,
      amount: params.amount,
      currency: 'USD',
    }),
  });

  if (!response.ok) {
    throw new Error(`Payment API returned ${response.status}`);
  }

  const data = await response.json();
  return { success: true, transactionId: data.transaction_id };
}

export async function logOrder(params: {
  orderId: string;
  status: string;
  paidAmount: number;
}): Promise<void> {
  await fetch('https://your-api.com/orders/log', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(params),
  });
}

export async function notifyUser(params: {
  email: string;
  message: string;
}): Promise<void> {
  await fetch('https://your-api.com/notify', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(params),
  });
}

When Temporal Shines:

Long-running processes (anything that takes hours or days)
Distributed transactions requiring exact-once semantics
Complex state machines with strict audit requirements
Financial systems, order processing, payment reconciliation

The Tradeoff:

Temporal requires operational expertise. You're running a database (either Cassandra or PostgreSQL), worker services, and the server itself. It's not a SaaS product you spin up in five minutes.

n8n: The Visual Automation Platform

n8n is the opposite of Temporal. It's designed for people who want to see their workflows and click together integrations without writing code.

Using n8n Cloud, I can build data pipelines by connecting nodes. Here's what a typical data enrichment workflow looks like:

{
  "nodes": [
    {
      "parameters": {
        "url": "https://api.example.com/users",
        "authentication": "oAuth2",
        "requestMethod": "GET",
        "options": {}
      },
      "name": "Fetch Users",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.1,
      "position": [250, 300]
    },
    {
      "parameters": {
        "mode": "runOnceForAllItems",
        "expression": "={\n  \"id\": $json.user_id,\n  \"email\": $json.email,\n  \"processed_at\": $now.toIso()\n}"
      },
      "name": "Transform Data",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.2,
      "position": [500, 300],
      "onError": "continueRegularOutput"
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://your-database.com/insert",
        "authentication": "basicAuth",
        "sendBody": true,
        "bodyParameters": {
          "parameters": [
            {
              "name": "data",
              "value": "={{ $json }}"
            }
          ]
        }
      },
      "name": "Save to Database",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.1,
      "position": [750, 300]
    }
  ],
  "connections": {
    "Fetch Users": {
      "main": [
        [
          {
            "node": "Transform Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Transform Data": {
      "main": [
        [
          {
            "node": "Save to Database",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

This three-node workflow:

Fetches users from an API
Transforms each record to include metadata
Saves them to your database

You can host n8n on your own infrastructure for full control. Here's a Docker Compose setup:

version: '3.8'
services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    ports:
      - "5678:5678"
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=change_me_securely
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - NODE_ENV=production
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=n8n_db_password
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
    restart: unless-stopped

  postgres:
    image: postgres:15-alpine
    container_name: n8n_postgres
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=n8n_db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  n8n_data:
  postgres_data:

Deploy this on Hetzner VPS or DigitalOcean, and you have a production n8n instance. For more details on the self-hosted vs cloud debate, check out my guide on self-hosted workflow automation vs cloud SaaS platforms.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

When n8n Wins:

Quick integrations between SaaS tools
Visual workflow design for non-technical users
Rapid prototyping and testing
Small to medium-scale data operations
Teams that need ease-of-use over raw power

The Tradeoff:

While n8n is flexible, it's not ideal for complex business logic that requires significant code. You can write custom code in nodes, but you're fighting the platform's paradigm if you need heavy computation.

Apache Airflow: The Python-Native Orchestrator

Airflow lets you define workflows as Python DAGs (Directed Acyclic Graphs). If you're comfortable with Python and need fine-grained control, Airflow is your platform.

Here's a data pipeline that downloads crypto price data, processes it, and uploads results:

from datetime import datetime, timedelta
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.bash import BashOperator
from airflow

Originally published on Automation Insider.

Temporal vs Make for API-First Workflows

Raizan — Wed, 20 May 2026 16:02:59 +0000

What You'll Need

n8n Cloud or self-hosted n8n instance
Hetzner VPS or Contabo VPS for hosting Temporal locally
DigitalOcean as an alternative for cloud deployment
Namecheap if you need a domain
API keys for your target services (Stripe, GitHub, Slack, etc.)
Docker and Docker Compose (free, open-source)
Node.js 18+ and npm

What's the Real Difference Between Temporal and Make?
Temporal: The Orchestration Engine Approach
Make: The Visual No-Code Platform
Building Your First Temporal Workflow
Building the Same Workflow in Make
Cost and Infrastructure Breakdown
Getting Started

What's the Real Difference Between Temporal and Make?

I've spent the last three years building API-first workflows for SaaS companies, and this question comes up constantly. The short answer? Temporal and Make.com solve the same business problem—automating API calls across services—but they approach it like night and day.

Temporal is a workflow orchestration platform. It's open-source, runs on your infrastructure, and treats workflows like distributed systems. You write code. You version control it. You deploy it like a regular application.

Make is a visual, cloud-hosted workflow builder. You drag and drop modules, connect APIs with a GUI, and hit publish. No code required.

The choice between them depends on your tolerance for infrastructure complexity, your budget constraints, and whether you want the flexibility of code or the simplicity of no-code. I've helped teams switch from expensive SaaS solutions like Zapier to self-hosted alternatives to reduce their SaaS bill, and this comparison is foundational to that conversation.

If you're building workflows that require complex branching logic, error handling, retry strategies, or need to integrate deeply with your existing codebase, Temporal wins. If you want to ship something in hours without touching a terminal, Make is faster. Let me show you how both work in practice.

Temporal: The Orchestration Engine Approach

Temporal was created by engineers from Uber and Doordash who needed a system that could handle reliability at scale. It's not a SaaS platform—it's a framework. You run the Temporal server yourself, write workflows in TypeScript or Python, and execute them against that server.

Here's why developers love it:

Automatic retries and error handling – If an API call fails, Temporal retries it with exponential backoff without you writing retry logic.

Durable execution – If your worker crashes mid-workflow, Temporal replays it from the last checkpoint. No data loss.

Visibility – You get a full history of every workflow execution with timestamps, inputs, outputs, and failures.

Cost efficiency – No per-execution fees. You pay only for the infrastructure running your server.

This is especially important if you're handling high-volume workflows. Imagine running 10,000 API calls per day through Zapier. You'd hit their usage limits fast. With Temporal, those 10,000 calls cost you only the server resources needed to run them.

Setting Up Temporal Locally

Let's get a Temporal server running on your Hetzner VPS or local Docker setup.

mkdir temporal-workflow && cd temporal-workflow
curl -O https://raw.githubusercontent.com/temporalio/docker-compose/main/docker-compose.yml
docker-compose up -d

Once the server is running on localhost:7233, create a package.json:

{
  "name": "temporal-api-workflow",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "worker": "ts-node src/worker.ts",
    "workflow": "ts-node src/run-workflow.ts"
  },
  "dependencies": {
    "@temporalio/client": "^1.11.0",
    "@temporalio/worker": "^1.11.0",
    "@temporalio/workflow": "^1.11.0",
    "axios": "^1.6.0",
    "ts-node": "^10.9.0",
    "typescript": "^5.0.0"
  }
}

Install dependencies:

npm install

Now create your workflow definition in src/workflows.ts:

import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

const { fetchUserFromStripe, sendSlackNotification, logToDatabase } = proxyActivities<typeof activities>({
  startToCloseTimeout: '10 seconds',
  retry: {
    initialInterval: '1 second',
    maximumInterval: '1 minute',
    maximumAttempts: 5,
  },
});

export async function processStripeWebhook(customerId: string) {
  const user = await fetchUserFromStripe(customerId);

  if (user.status === 'active') {
    await sendSlackNotification({
      channel: '#billing',
      message: `User ${user.email} is active and has ${user.subscriptions.length} subscriptions`,
    });
  }

  const logResult = await logToDatabase({
    customerId,
    status: user.status,
    timestamp: new Date().toISOString(),
  });

  return {
    processedAt: new Date(),
    userId: user.id,
    notificationSent: user.status === 'active',
    logId: logResult.id,
  };
}

Now define the activities that do the actual work in src/activities.ts:

import axios from 'axios';

interface StripeUser {
  id: string;
  email: string;
  status: string;
  subscriptions: Array<{ id: string; status: string }>;
}

interface SlackPayload {
  channel: string;
  message: string;
}

interface DatabaseLog {
  customerId: string;
  status: string;
  timestamp: string;
}

interface LogResult {
  id: string;
}

export async function fetchUserFromStripe(customerId: string): Promise<StripeUser> {
  const response = await axios.get(`https://api.stripe.com/v1/customers/${customerId}`, {
    headers: {
      Authorization: `Bearer ${process.env.STRIPE_API_KEY}`,
    },
  });

  const subscriptions = await axios.get(
    `https://api.stripe.com/v1/customers/${customerId}/subscriptions`,
    {
      headers: {
        Authorization: `Bearer ${process.env.STRIPE_API_KEY}`,
      },
    }
  );

  return {
    id: response.data.id,
    email: response.data.email,
    status: response.data.description || 'unknown',
    subscriptions: subscriptions.data.data,
  };
}

export async function sendSlackNotification(payload: SlackPayload): Promise<void> {
  await axios.post(process.env.SLACK_WEBHOOK_URL, {
    channel: payload.channel,
    text: payload.message,
    ts: Math.floor(Date.now() / 1000),
  });
}

export async function logToDatabase(log: DatabaseLog): Promise<LogResult> {
  const response = await axios.post(process.env.DATABASE_WEBHOOK_URL, {
    customerId: log.customerId,
    status: log.status,
    timestamp: log.timestamp,
  });

  return { id: response.data.insertedId };
}

Create a worker in src/worker.ts:

import { Worker } from '@temporalio/worker';
import * as workflows from './workflows';
import * as activities from './activities';

async function runWorker() {
  const worker = await Worker.create({
    workflowsPath: require.resolve('./workflows'),
    activitiesPath: require.resolve('./activities'),
    taskQueue: 'stripe-webhook-queue',
    namespace: 'default',
    workflowFailureExceptionTypes: [Error],
  });

  console.log('Temporal Worker started, listening on queue: stripe-webhook-queue');
  await worker.run();
}

runWorker().catch(console.error);

Finally, trigger a workflow execution in src/run-workflow.ts:

import { Connection, Client } from '@temporalio/client';
import { processStripeWebhook } from './workflows';

async function runWorkflow() {
  const connection = await Connection.connect({ address: 'localhost:7233' });
  const client = new Client({ connection });

  const workflowId = `stripe-webhook-${Date.now()}`;

  const result = await client.workflow.execute(processStripeWebhook, {
    args: ['cus_abc123xyz'],
    taskQueue: 'stripe-webhook-queue',
    workflowId,
  });

  console.log('Workflow completed:', result);
}

runWorkflow().catch(console.error);

Start your worker:

npm run worker

In another terminal, run the workflow:

npm run workflow

You'll see the workflow execute across all three activities: fetch from Stripe, send a Slack message, and log to your database. If any step fails, Temporal retries it automatically. That's the power of durable execution.

Make: The Visual No-Code Platform

Now let's build the exact same workflow in Make.com—the visual way.

Make is cloud-hosted, which means zero infrastructure overhead. You log in, drag modules onto a canvas, and connect them. Each module represents an API call or data transformation. No code required, though you can add JavaScript when needed.

The tradeoff? You pay per operation. Make charges based on the number of "operations" (API calls and data transformations) your workflows perform. If you're running 10,000 Stripe API calls per month, costs add up quickly.

Here's how to replicate the Temporal workflow in Make:

Log into Make and create a new scenario.
Set up the trigger. Add a Webhook module as your trigger. This gives you a webhook URL that Stripe can POST to when events occur.

Make → Webhook → Listen on this URL for Stripe webhook events

Parse the webhook. Add a JSON → Parse JSON module to extract the customerId:

{
  "customerId": "{{trigger.body.data.object.customer}}"
}

Fetch from Stripe. Add a Stripe module (or use HTTP Request):

Module: HTTP → Make a request

URL: https://api.stripe.com/v1/customers/{{customerId}}
Method: GET
Headers: Authorization: Bearer {{env.STRIPE_API_KEY}}

Conditional routing. Add a Router to check if status == 'active':

Router → if status = "active"
  → YES: Send Slack notification
  → NO: Skip notification

Send to Slack. In the YES path, add a Slack module:

Message: User {{firstName}} {{lastName}} ({{email}}) is active with {{subscriptionCount}} subscriptions
Channel: #billing

Log to database. Add an HTTP Request module:

URL: {{env.DATABASE_WEBHOOK_URL}}
Method: POST
Body:

{
  "customerId": "{{customerId}}",
  "status": "{{stripeResponse.status}}",
  "timestamp": "{{now()}}"

Originally published on Automation Insider.

Make vs n8n vs Zapier API integrations 2026

Raizan — Tue, 19 May 2026 08:00:32 +0000

What You'll Need

n8n Cloud or self-hosted n8n
Hetzner VPS or Contabo VPS for hosting
Namecheap if domain needed
DigitalOcean as alternative
Make.com for comparison testing
Text editor (VS Code recommended)
curl or Postman for API testing
Basic understanding of REST APIs

The 2026 Automation Landscape
n8n API Integration Strategy
Make.com's Native Connectors vs Custom APIs
Zapier's Webhook-First Approach
Cost Analysis: Real Numbers
Building Your First Custom Integration
Performance and Scalability
Getting Started

The 2026 Automation Landscape

The workflow automation market has fundamentally shifted since 2024. I've been hands-on with all three platforms—n8n Cloud, Make.com, and Zapier—across 40+ production workflows, and what I'm seeing is a bifurcation: platforms are doubling down on either native integrations or API flexibility. In 2026, that choice matters more than ever.

The reality is brutally simple: if your workflow touches proprietary APIs or niche SaaS tools, you need maximum control. If you're gluing together Slack, Google Sheets, and Stripe, the platform with the most pre-built connectors wins. But here's what nobody tells you—the "best" platform depends entirely on whether you value speed, cost, or architectural ownership.

I built a lead capture and nurturing system last quarter that started on Zapier, migrated to Make.com midway through, and finally landed on n8n. That journey taught me the hard lessons about API rate limits, webhook reliability, and hidden costs that never show up in marketing materials.

n8n API Integration Strategy

n8n remains the most developer-friendly automation platform if you're willing to get your hands dirty with code. In 2026, its appeal lies in one clear advantage: you own the entire workflow architecture.

Here's how I build production-grade API integrations in n8n:

{
  "nodes": [
    {
      "parameters": {
        "url": "https://api.example.com/v1/customers",
        "authentication": "oAuth2",
        "requestMethod": "POST",
        "sendQuery": false,
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            {
              "name": "Content-Type",
              "value": "application/json"
            },
            {
              "name": "X-API-Version",
              "value": "2024-12"
            }
          ]
        },
        "bodyParametersJson": "{\n  \"email\": \"{{ $json.userEmail }}\",\n  \"firstName\": \"{{ $json.firstName }}\",\n  \"lastName\": \"{{ $json.lastName }}\",\n  \"metadata\": {\n    \"source\": \"workflow_automation\",\n    \"timestamp\": \"{{ $now.toISOString() }}\"\n  }\n}",
        "options": {}
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.1,
      "position": [
        1200,
        300
      ],
      "name": "Create Customer in External API"
    },
    {
      "parameters": {
        "conditions": {
          "number": [
            {
              "value1": "{{ $response.statusCode }}",
              "operation": "equal",
              "value2": 201
            }
          ]
        }
      },
      "type": "n8n-nodes-base.if",
      "typeVersion": 2,
      "position": [
        1400,
        300
      ],
      "name": "Check API Success"
    },
    {
      "parameters": {
        "resource": "message",
        "channel": "#automation-logs",
        "text": "✅ Customer created: {{ $json.data.id }}"
      },
      "type": "n8n-nodes-base.slack",
      "typeVersion": 2,
      "position": [
        1600,
        200
      ],
      "name": "Log Success to Slack"
    },
    {
      "parameters": {
        "resource": "message",
        "channel": "#automation-errors",
        "text": "❌ API Error: {{ $json.error.message }} | Status: {{ $response.statusCode }}"
      },
      "type": "n8n-nodes-base.slack",
      "typeVersion": 2,
      "position": [
        1600,
        400
      ],
      "name": "Log Error to Slack"
    }
  ],
  "connections": {
    "Create Customer in External API": {
      "main": [
        [
          {
            "node": "Check API Success",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Check API Success": {
      "main": [
        [
          {
            "node": "Log Success to Slack",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Log Error to Slack",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

The critical advantage here is OAuth2 handling without vendor lock-in. When you self-host n8n on Hetzner or DigitalOcean, you control credential storage completely. Your API keys live on your infrastructure.

For webhook-triggered workflows, n8n gives you:

curl -X POST https://your-n8n-instance.com/webhook/api-trigger \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_WEBHOOK_TOKEN" \
  -d '{
    "email": "user@example.com",
    "action": "user_created",
    "timestamp": "2026-01-15T10:30:00Z",
    "payload": {
      "firstName": "John",
      "lastName": "Doe",
      "company": "TechCorp"
    }
  }'

That webhook endpoint you just hit? You own it. No rate-limiting games from Zapier's platform, no "upgrade to Pro" for higher throughput.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Make.com's Native Connectors vs Custom APIs

Make.com (formerly Integromat) competes on connector breadth. In 2026, they've got 1,200+ pre-built modules, and I'll be honest—if your workflow is 80% pre-built connector work, Make.com's visual interface is faster than code.

Here's a Make.com scenario that works beautifully:

{
  "flow": [
    {
      "module": "trigger",
      "type": "webhooks.watch",
      "settings": {
        "url": "https://hooks.make.com/api/webhooks/unique-id",
        "data_structure": {
          "email": "string",
          "action_type": "string",
          "properties": "object"
        }
      }
    },
    {
      "module": "filter",
      "condition": "action_type == 'purchase'",
      "operations": [
        {
          "operand": "{{ trigger.action_type }}",
          "operator": "equal",
          "value": "purchase"
        }
      ]
    },
    {
      "module": "http",
      "type": "make_an_http_request",
      "settings": {
        "url": "https://api.crm.example.com/v2/customers",
        "method": "POST",
        "headers": {
          "Authorization": "Bearer {{ connection.crm_api_key }}",
          "Content-Type": "application/json"
        },
        "body": "{\n  \"email\": \"{{ trigger.email }}\",\n  \"last_action\": \"{{ trigger.action_type }}\",\n  \"custom_fields\": \"{{ trigger.properties }}\"\n}"
      }
    },
    {
      "module": "csv",
      "type": "create_csv",
      "settings": {
        "data": "{{ trigger }}",
        "filename": "webhook_{{ date(now; 'YYYY-MM-DD HH:mm') }}.csv"
      }
    },
    {
      "module": "google_drive",
      "type": "upload_file",
      "settings": {
        "file": "{{ csv.file }}",
        "folder_id": "{{ connection.drive_folder }}"
      }
    }
  ]
}

Make.com's strength is immediate visual feedback. You see the data flowing through each module in real-time. But here's the trade-off: when you need custom JavaScript logic, Make.com's "ScriptableModule" becomes expensive fast. Each custom function runs on their infrastructure at their rates.

The hidden cost of Make.com in 2026: their pricing model charges per operation count, not per workflow. A workflow that processes 100 items across 5 modules costs 500 operations. Scale to 10,000 items daily, and you're looking at significant monthly spend without the visibility you'd have in n8n.

Zapier's Webhook-First Approach

Zapier owns the SMB automation market because they've optimized the path from "I have no automation" to "production workflow" to roughly 10 minutes. In 2026, Zapier's API is mature, but it's built around their cloud infrastructure exclusively.

Here's how Zapier webhooks work:

curl -X POST https://hooks.zapier.com/hooks/catch/YOUR_UNIQUE_ID/YOUR_SECRET/ \
  -H "Content-Type: application/json" \
  -d '{
    "customer_id": "cust_98765",
    "email": "user@company.com",
    "purchase_amount": 250.00,
    "timestamp": "2026-01-15T14:22:00Z",
    "metadata": {
      "source": "ecommerce_platform",
      "region": "EMEA"
    }
  }'

Zapier catches that webhook, parses it, and routes it through your Zap (their term for workflow). The entire workflow runs on Zapier's cloud infrastructure. You have zero server management, but you also have zero infrastructure control.

The Zapier advantage for teams without DevOps: native integrations with 7,000+ apps. If you need Slack + HubSpot + Stripe + Asana automated together, Zapier has pre-built authentication for all of them. You don't touch an API key directly.

The Zapier disadvantage for teams with serious scale: their free tier is laughably limited (100 tasks/month), their Pro tier hits $49/month minimum, and their highest Enterprise tier doesn't publicly disclose pricing. For a company processing 50,000

Originally published on Automation Insider.

Temporal vs n8n for Microservices Orchestration

Raizan — Mon, 18 May 2026 08:00:43 +0000

What You'll Need

n8n Cloud or self-hosted n8n instance
Hetzner VPS or Contabo VPS for self-hosting Temporal or n8n
DigitalOcean as an alternative hosting provider
Docker and Docker Compose (for local development)
Node.js 18+ installed locally
A REST client like Postman or cURL for testing

What is Temporal?
What is n8n?
Architecture Comparison
Building a Microservice Workflow with Temporal
Building the Same Workflow with n8n
Performance and Scalability
When to Choose Temporal
When to Choose n8n
Getting Started

What is Temporal?

Temporal is an open-source platform designed specifically for orchestrating microservices through a concept called "durable execution." Instead of writing complex logic to handle retries, failures, and distributed state management, Temporal abstracts away the plumbing through workflows and activities written in regular code.

The key innovation is that your code can look synchronous and straightforward, while Temporal handles all the complexity of execution state, resuming from failures, and managing long-running processes. It's built for engineers who want battle-tested infrastructure without reinventing the wheel.

What is n8n?

n8n is a low-code workflow automation platform that I've extensively tested and deployed. It sits at the intersection of no-code simplicity and code flexibility. You build workflows visually using nodes, each representing an integration or custom logic block. n8n excels at connecting SaaS tools, databases, and APIs with minimal custom code.

Unlike Temporal's code-first approach, n8n is visual-first. You design workflows in the UI, configure node parameters, and write JavaScript when you need custom logic.

Architecture Comparison

Temporal uses a server-client architecture where workers register with the Temporal server and poll for tasks. Your application code runs workers that execute activities (actual business logic) and workflows (orchestration logic). The server maintains the event history, ensuring fault tolerance.

n8n runs workflows as directed acyclic graphs (DAGs) where each node passes output to the next. For self-hosted deployments, you run n8n server(s) connected to a PostgreSQL database. Workers pick up jobs from a queue and execute them.

The fundamental difference: Temporal is designed for complex, stateful, long-running processes with guaranteed execution semantics. n8n is optimized for integrations and medium-complexity workflows.

If you're comparing workflow platforms broadly, I've detailed the n8n vs Make vs Zapier pricing breakdown 2026 which provides context on feature trade-offs beyond just Temporal.

Building a Microservice Workflow with Temporal

Let me walk you through a real example: processing customer orders across multiple services. A customer submits an order, you charge their card, reserve inventory, and notify them via email. If any step fails, you need automatic retries and rollback logic.

First, install the Temporal TypeScript SDK:

npm install @temporalio/client @temporalio/worker @temporalio/workflow @temporalio/activities

Create your activities file (activities.ts). Activities are the actual microservice calls:

import axios from 'axios';

export async function chargePayment(orderId: string, amount: number): Promise<string> {
  const response = await axios.post('https://payment-service.internal/charge', {
    orderId,
    amount,
    timestamp: new Date().toISOString()
  }, {
    timeout: 5000,
    headers: { 'Authorization': 'Bearer YOUR_SERVICE_TOKEN' }
  });

  if (response.status !== 200) {
    throw new Error(`Payment failed: ${response.statusText}`);
  }

  return response.data.transactionId;
}

export async function reserveInventory(orderId: string, items: Array<{sku: string, quantity: number}>): Promise<string> {
  const response = await axios.post('https://inventory-service.internal/reserve', {
    orderId,
    items,
    expiryMinutes: 10
  }, {
    timeout: 8000,
    headers: { 'Authorization': 'Bearer YOUR_SERVICE_TOKEN' }
  });

  if (response.status !== 200) {
    throw new Error(`Inventory reservation failed: ${response.statusText}`);
  }

  return response.data.reservationId;
}

export async function sendOrderConfirmation(orderId: string, customerEmail: string, items: any[]): Promise<void> {
  const response = await axios.post('https://email-service.internal/send', {
    to: customerEmail,
    subject: `Order ${orderId} Confirmed`,
    template: 'order-confirmation',
    data: { orderId, items, confirmationTime: new Date().toISOString() }
  }, {
    timeout: 3000,
    headers: { 'Authorization': 'Bearer YOUR_SERVICE_TOKEN' }
  });

  if (response.status !== 200) {
    throw new Error(`Email send failed: ${response.statusText}`);
  }
}

export async function releaseInventory(reservationId: string): Promise<void> {
  await axios.post('https://inventory-service.internal/release', {
    reservationId
  }, {
    timeout: 5000,
    headers: { 'Authorization': 'Bearer YOUR_SERVICE_TOKEN' }
  });
}

Now define the workflow (workflow.ts). This is where Temporal shines—your logic is clean and readable:

import { proxyActivities, RetryPolicy, ApplicationFailure } from '@temporalio/workflow';
import * as activities from './activities';

const { chargePayment, reserveInventory, sendOrderConfirmation, releaseInventory } = proxyActivities<typeof activities>({
  startToCloseTimeout: '10 minutes',
  retry: {
    initialInterval: '1 second',
    maximumInterval: '1 minute',
    maximumAttempts: 3,
    backoffCoefficient: 2.0,
    nonRetryableErrorReasons: ['InvalidOrderId', 'InsufficientFunds']
  }
});

export interface OrderRequest {
  orderId: string;
  customerId: string;
  customerEmail: string;
  items: Array<{ sku: string; quantity: number; price: number }>;
  totalAmount: number;
}

export async function processOrderWorkflow(order: OrderRequest): Promise<{ success: boolean; message: string }> {
  let transactionId: string;
  let reservationId: string;

  try {
    transactionId = await chargePayment(order.orderId, order.totalAmount);
    console.log(`Payment processed: ${transactionId}`);
  } catch (error) {
    return {
      success: false,
      message: `Payment failed for order ${order.orderId}: ${error.message}`
    };
  }

  try {
    reservationId = await reserveInventory(order.orderId, order.items);
    console.log(`Inventory reserved: ${reservationId}`);
  } catch (error) {
    console.log(`Inventory reservation failed, releasing payment hold`);
    await releaseInventory(reservationId);
    return {
      success: false,
      message: `Inventory reservation failed for order ${order.orderId}: ${error.message}`
    };
  }

  try {
    await sendOrderConfirmation(order.orderId, order.customerEmail, order.items);
    console.log(`Confirmation sent to ${order.customerEmail}`);
  } catch (error) {
    console.log(`Email notification failed but order is processing`);
  }

  return {
    success: true,
    message: `Order ${order.orderId} processed successfully`
  };
}

Start a worker that executes these workflows (worker.ts):

import { Worker, NativeConnection } from '@temporalio/worker';
import * as activities from './activities';
import * as workflows from './workflow';

async function runWorker() {
  const connection = await NativeConnection.connect({
    address: 'localhost:7233'
  });

  const worker = await Worker.create({
    connection,
    namespace: 'default',
    taskQueue: 'order-processing',
    workflowsPath: require.resolve('./workflow'),
    activities
  });

  console.log('Worker started, listening on task queue: order-processing');
  await worker.run();
}

runWorker().catch(err => {
  console.error('Worker failed:', err);
  process.exit(1);
});

Finally, trigger the workflow from your application (client.ts):

import { Client } from '@temporalio/client';
import { processOrderWorkflow, OrderRequest } from './workflow';

async function submitOrder(order: OrderRequest) {
  const client = new Client({
    connection: { address: 'localhost:7233' }
  });

  const handle = await client.workflow.start(processOrderWorkflow, {
    args: [order],
    taskQueue: 'order-processing',
    workflowId: `order-${order.orderId}-${Date.now()}`,
    memo: {
      customerId: order.customerId,
      totalAmount: order.totalAmount.toString()
    }
  });

  console.log(`Workflow started: ${handle.workflowId}`);

  const result = await handle.result();
  console.log('Workflow result:', result);
  return result;
}

submitOrder({
  orderId: 'ORD-12345',
  customerId: 'CUST-789',
  customerEmail: 'customer@example.com',
  items: [
    { sku: 'SKU-001', quantity: 2, price: 29.99 },
    { sku: 'SKU-002', quantity: 1, price: 49.99 }
  ],
  totalAmount: 109.97
});

This workflow demonstrates Temporal's power: if your payment microservice is down, Temporal automatically retries. If the worker crashes mid-execution, it resumes exactly where it left off. No state management code needed.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Building the Same Workflow with n8n

Now let's build the same order processing workflow in n8n. You'll use the visual workflow editor and HTTP nodes to call your microservices.

Create a new workflow in n8n and add a webhook trigger node to receive order submissions:

{
  "name": "HTTP In - Order Submission",
  "type": "n8n-nodes-base.httpWebhook",
  "parameters": {
    "path": "/order-webhook",
    "httpMethod": "POST",
    "responseMode": "onReceived"
  }
}

Add a Set node to extract and structure the incoming order data:

{
  "name": "Structure Order Data",
  "type": "n8n-nodes-base.set",
  "parameters": {
    "assignments": {
      "assignments": [
        {
          "name": "orderId",
          "value": "={{$json.body.orderId}}",
          "type": "string"
        },
        {
          "name": "customerId",
          "value": "={{$json.body.custom

Originally published on Automation Insider.

Building Custom Webhooks vs Using n8n Triggers

Raizan — Sun, 17 May 2026 08:00:28 +0000

What You'll Need

n8n Cloud or self-hosted n8n
Hetzner VPS or Contabo VPS for hosting custom webhook servers
DigitalOcean as an alternative hosting option
Node.js (v18+) if building custom webhooks
A code editor (VS Code recommended)
Basic knowledge of REST APIs and JSON

What You'll Need
Understanding Webhooks and Triggers
When to Build Custom Webhooks
Building a Custom Webhook Server
Using n8n Triggers: The Simpler Path
Performance and Cost Comparison
Getting Started

Understanding Webhooks and Triggers

I've spent years building automation systems, and the webhook vs. trigger question comes up constantly. Let me cut through the noise: they're solving the same problem differently.

A webhook is essentially an HTTP POST request sent from one service to another when something happens. It's a push notification. Your app pushes data to n8n when an event occurs. A trigger, in n8n's context, is a built-in listener that polls or subscribes to specific events within a service and automatically starts your workflow.

The core difference? Control and flexibility versus ease of setup.

When you build a custom webhook, you control the exact payload, authentication, retry logic, and event timing. When you use n8n's built-in triggers, you get instant integration with thousands of apps but less granular control. I've found myself using both in the same project—triggers for simple integrations and custom webhooks for complex, high-volume systems.

When to Build Custom Webhooks

I reach for custom webhooks in these scenarios:

Legacy system integration. If you're connecting to a 15-year-old internal database that n8n doesn't have a native connector for, custom webhooks are your answer. The legacy system pushes data to your webhook endpoint, n8n processes it, and downstream tools consume the results.

High-volume event handling. When you're processing thousands of events daily, webhook efficiency matters. Webhooks are push-based (event-driven), so you're not wasting compute cycles polling endpoints that haven't changed.

Custom authentication. Some internal APIs use proprietary auth schemes. Building a custom webhook lets you handle mutual TLS certificates, custom headers, or API tokens that n8n's standard connectors don't support.

Payload transformation at the source. Sometimes it's cleaner to filter or reshape data at the webhook source rather than inside n8n. This reduces workflow complexity and saves processing time.

Building a Custom Webhook Server

Let me show you a production-ready webhook server. I've simplified this, but it's what I run on a Hetzner VPS handling thousands of daily events.

First, your Node.js server:

const express = require('express');
const crypto = require('crypto');
const axios = require('axios');
require('dotenv').config();

const app = express();
const PORT = process.env.PORT || 3000;
const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET || 'your-secret-key-change-this';
const N8N_WEBHOOK_URL = process.env.N8N_WEBHOOK_URL;

app.use(express.json());

function verifySignature(req, secret) {
  const signature = req.headers['x-webhook-signature'];
  const timestamp = req.headers['x-webhook-timestamp'];
  const body = JSON.stringify(req.body);

  const message = `${timestamp}.${body}`;
  const expectedSignature = crypto
    .createHmac('sha256', secret)
    .update(message)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expectedSignature)
  );
}

app.post('/webhook/events', async (req, res) => {
  try {
    if (!verifySignature(req, WEBHOOK_SECRET)) {
      return res.status(401).json({ error: 'Invalid signature' });
    }

    const payload = req.body;
    const eventType = payload.event_type;
    const timestamp = new Date().toISOString();

    console.log(`[${timestamp}] Received ${eventType} event`);

    const enrichedPayload = {
      original_event: payload,
      received_at: timestamp,
      event_type: eventType,
      source_ip: req.ip,
      processed: false
    };

    try {
      const response = await axios.post(N8N_WEBHOOK_URL, enrichedPayload, {
        headers: {
          'Content-Type': 'application/json'
        },
        timeout: 30000
      });

      enrichedPayload.processed = true;
      enrichedPayload.n8n_response_code = response.status;

      console.log(`[${timestamp}] Successfully forwarded to n8n`);
      return res.status(200).json({ 
        success: true, 
        message: 'Event received and forwarded',
        event_id: enrichedPayload.event_id
      });
    } catch (error) {
      console.error(`[${timestamp}] n8n forwarding failed:`, error.message);

      if (error.response?.status >= 500) {
        return res.status(202).json({ 
          success: false,
          message: 'Event queued for retry',
          error: error.message
        });
      }

      return res.status(400).json({ 
        success: false,
        message: 'Failed to process event',
        error: error.message
      });
    }
  } catch (error) {
    console.error('Webhook handler error:', error);
    return res.status(500).json({ error: 'Internal server error' });
  }
});

app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok', timestamp: new Date().toISOString() });
});

app.listen(PORT, () => {
  console.log(`Webhook server running on port ${PORT}`);
  console.log(`Health check: http://localhost:${PORT}/health`);
});

Your .env file:

PORT=3000
WEBHOOK_SECRET=your-super-secret-key-at-least-32-characters-long
N8N_WEBHOOK_URL=https://your-n8n-instance.com/webhook/your-webhook-path
NODE_ENV=production

Your package.json:

{
  "name": "webhook-server",
  "version": "1.0.0",
  "description": "Custom webhook server for n8n",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "dev": "nodemon server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "axios": "^1.6.0",
    "dotenv": "^16.3.1"
  },
  "devDependencies": {
    "nodemon": "^3.0.1"
  }
}

Install dependencies:

npm install

Deploy this to DigitalOcean or Contabo. Use PM2 to keep it running:

npm install -g pm2
pm2 start server.js --name webhook-server
pm2 save
pm2 startup

Now, in your source system (the one sending events), you'd call your webhook like this:

curl -X POST https://your-webhook-server.com/webhook/events \
  -H "Content-Type: application/json" \
  -H "x-webhook-signature: $(echo -n '1702000000.{"event_type":"user.created"}' | openssl dgst -sha256 -hmac 'your-secret-key' | cut -d' ' -f2)" \
  -H "x-webhook-timestamp: 1702000000" \
  -d '{"event_type":"user.created","user_id":"12345","email":"user@example.com"}'

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Using n8n Triggers: The Simpler Path

Now let me show you how the same flow works with n8n Cloud.

With n8n's native triggers, you skip the custom server entirely. Instead, you add a trigger node directly in your workflow. Here's what that looks like:

Create a new workflow in n8n:

Click Add trigger
Search for Webhook
Select Webhook

In the Webhook trigger node configuration:

HTTP Method: POST
Path: /my-webhook-path
Authentication: None (or Basic Auth if needed)
Response Mode: On Received
Execution Data: First incoming data

Your n8n node setup:

{
  "node": "Webhook",
  "type": "n8n-nodes-base.webhook",
  "typeVersion": 1,
  "position": [250, 300],
  "parameters": {
    "httpMethod": "POST",
    "path": "my-webhook-path",
    "responseMode": "onReceived",
    "options": {
      "authenticationMethod": "none"
    }
  }
}

The webhook URL n8n generates looks like:

https://your-n8n-instance.com/webhook/my-webhook-path

You send data to that URL:

curl -X POST https://your-n8n-instance.com/webhook/my-webhook-path \
  -H "Content-Type: application/json" \
  -d '{"user_id":"12345","event":"signup"}'

Next, add a Set node to process the incoming data:

{
  "node": "Set",
  "type": "n8n-nodes-base.set",
  "typeVersion": 3,
  "position": [450, 300],
  "parameters": {
    "mode": "manual",
    "assignments": {
      "assignments": [
        {
          "id": "1",
          "name": "event_type",
          "value": "={{ $json.event }}",
          "type": "string"
        },
        {
          "id": "2",
          "name": "user_id",
          "value": "={{ $json.user_id }}",
          "type": "string"
        },
        {
          "id": "3",
          "name": "processed_at",
          "value": "={{ now().toISOString() }}",
          "type": "string"
        }
      ]
    }
  }
}

Then add your downstream action—maybe sending to a database or another service. If you're integrating with OAuth2 for services like Google Workspace, I'd recommend reading my guide on OAuth2 for Beginners: Connecting APIs Without the Pain.

The beauty of n8n triggers is speed. No server setup, no authentication to build, automatic retries, and logging built in. The tradeoff is less control over how events are filtered or transformed before reaching your workflow.

Performance and Cost Comparison

Here's what I've learned running both approaches:

Custom Webhooks:

Latency: 50-150ms end-to-end (after your server

Originally published on Automation Insider.

How I Run 3 Automated Systems on a Single $7/Month VPS

Raizan — Fri, 08 May 2026 08:00:28 +0000

What You'll Need

n8n Cloud or self-hosted n8n
Hetzner VPS or Contabo VPS for hosting
Namecheap if domain needed
SSH client (built into Mac/Linux, PuTTY for Windows)
Basic command-line familiarity

The Reality of Running Multiple Systems on Minimal Infrastructure
System 1: Lead Capture to CRM Pipeline
System 2: Daily Content Publishing Scheduler
System 3: Performance Monitoring and Alert Relay
Resource Optimization Strategies
Getting Started with Your Own Setup

The Reality of Running Multiple Systems on Minimal Infrastructure {#reality}

I manage three separate automation workflows on a $7/month VPS from Contabo VPS, and honestly, it's become my favorite experiment in lean operations. Before you roll your eyes thinking this is some clickbait nonsense—it's not. It works. But it requires intentional architecture choices.

Most people assume you need separate servers, managed cloud services, or at minimum a $20+ VPS tier. I'm here to tell you that's marketing speak. I've consolidated workflows that would typically cost $60–80 per month in SaaS fees into a single machine. The key isn't magic; it's understanding resource constraints and designing workflows that respect them.

When I started, I had a naive approach: just install n8n on a cheap server and throw everything at it. The VPS crawled. CPU usage spiked unpredictably. Workflows would timeout. Then I learned what actually matters: memory footprint, database efficiency, and intelligent scheduling. This post walks through exactly how I solved each problem.

System 1: Lead Capture to CRM Pipeline {#system-1-lead-capture}

My first automated system grabs leads from a web form, validates them, and pipes them into my CRM—no manual touch. This runs 24/7 and is the most critical workflow.

Setting Up n8n on Your VPS

First, SSH into your Contabo VPS and get n8n installed:

curl -fsSL https://raw.githubusercontent.com/n8n-io/n8n/master/packages/node-dev/bin/n8n | bash

Create a dedicated user for n8n to avoid permission headaches:

sudo useradd -m -s /bin/bash n8n
sudo su - n8n

Install Node.js version 18 (n8n's sweet spot for performance):

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs

Install n8n globally:

npm install -g n8n

Create a systemd service file so n8n starts automatically:

sudo nano /etc/systemd/system/n8n.service

Paste this configuration:

[Unit]
Description=n8n Workflow Automation
After=network.target

[Service]
Type=simple
User=n8n
WorkingDirectory=/home/n8n
Environment="NODE_ENV=production"
Environment="N8N_PORT=5678"
Environment="N8N_PROTOCOL=https"
Environment="N8N_HOST=your-domain.com"
Environment="N8N_SECURE_COOKIE=true"
Environment="N8N_DB_TYPE=sqlite"
Environment="N8N_DB_SQLITE_DB_FILE=/home/n8n/.n8n/database.sqlite"
ExecStart=/usr/bin/n8n start
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable n8n
sudo systemctl start n8n

Set up Nginx as a reverse proxy (this protects n8n and handles SSL):

sudo apt-get install -y nginx certbot python3-certbot-nginx

Create an Nginx config:

sudo nano /etc/nginx/sites-available/n8n

Add this:

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://127.0.0.1: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;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Enable the site and get SSL:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/n8n
sudo certbot certonly --standalone -d your-domain.com

Update Nginx to use HTTPS:

sudo nano /etc/nginx/sites-available/n8n

Replace with:

server {
    listen 80;
    server_name your-domain.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-domain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1: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 https;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Reload Nginx:

sudo systemctl reload nginx

The Lead Workflow

Inside n8n, I built this workflow that's been processing 50–100 leads daily:

Webhook trigger – listens for form submissions
Validation node – checks email format and required fields
Deduplication – queries SQLite to prevent duplicate entries
CRM HTTP call – POSTs to my CRM API
Slack notification – alerts me of new qualified leads

Here's the actual workflow JSON structure (simplified for clarity, but production-ready):

{
  "nodes": [
    {
      "parameters": {
        "path": "webhook/lead-capture",
        "responseMode": "onReceived",
        "responseData": "customJson",
        "responseValue": "{\"status\": \"received\"}"
      },
      "id": "webhook-trigger",
      "name": "Lead Form Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "position": [250, 300]
    },
    {
      "parameters": {
        "conditions": {
          "string": [
            {
              "value1": "{{ $json.email }}",
              "operation": "regex",
              "value2": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$"
            },
            {
              "value1": "{{ $json.name }}",
              "operation": "isEmpty",
              "value2": null
            }
          ]
        }
      },
      "id": "if-valid",
      "name": "Validate Email & Name",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2,
      "position": [550, 300]
    },
    {
      "parameters": {
        "operation": "executeQuery",
        "query": "SELECT COUNT(*) as count FROM leads WHERE email = '{{ $json.email }}' AND created_at > datetime('now', '-7 days')",
        "database": "/home/n8n/.n8n/database.sqlite"
      },
      "id": "check-duplicate",
      "name": "Check Duplicate (Last 7 Days)",
      "type": "n8n-nodes-base.sqlite",
      "typeVersion": 1,
      "position": [850, 300]
    },
    {
      "parameters": {
        "url": "https://api.your-crm.com/leads",
        "method": "POST",
        "headers": {
          "Authorization": "Bearer {{ $env.CRM_API_KEY }}",
          "Content-Type": "application/json"
        },
        "body": {
          "name": "{{ $json.name }}",
          "email": "{{ $json.email }}",
          "phone": "{{ $json.phone }}",
          "message": "{{ $json.message }}",
          "source": "web_form"
        }
      },
      "id": "post-to-crm",
      "name": "Send to CRM",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.1,
      "position": [1150, 300]
    },
    {
      "parameters": {
        "text": "🎯 New Lead: {{ $json.name }} ({{ $json.email }})"
      },
      "id": "slack-notify",
      "name": "Slack Alert",
      "type": "n8n-nodes-base.slack",
      "typeVersion": 2,
      "position": [1450, 300]
    }
  ],
  "connections": {
    "webhook-trigger": {
      "main": [
        [
          {
            "node": "if-valid",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "if-valid": {
      "main": [
        [
          {
            "node": "check-duplicate",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "check-duplicate": {
      "main": [
        [
          {
            "node": "post-to-crm",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "post-to-crm": {
      "main": [
        [
          {
            "node": "slack-notify",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

The deduplication step is crucial on a shared VPS. Instead of spamming your CRM or burning API rate limits, I query SQLite locally first. This is where choosing the right database matters—I cover this decision deeper in my guide on SQLite vs PostgreSQL for Small Projects: When to Use Which.

Originally published on Automation Insider.

Cron Jobs Explained: Scheduling Automated Tasks on Linux

Raizan — Thu, 07 May 2026 08:00:33 +0000

What You'll Need

n8n Cloud or self-hosted n8n (optional, for automation integration)
Hetzner VPS, Contabo VPS, or DigitalOcean for running cron jobs
Namecheap if you need a domain for your automation
Linux server access (Ubuntu 20.04 LTS or later recommended)
Basic command-line familiarity

Understanding Cron: The Basics
Crontab Syntax Breakdown
Creating and Managing Your First Cron Job
Real-World Examples and Use Cases
Debugging and Monitoring Cron Jobs
Getting Started

Understanding Cron: The Basics

I'll be honest—when I first encountered cron jobs, I thought they were some obscure DevOps sorcery. They're actually one of the simplest yet most powerful tools in Linux. A cron job is just a scheduled task that runs automatically at specific times or intervals without you touching a keyboard. It's been the backbone of server automation since 1975, and it still works beautifully today.

Think of cron as your personal assistant that never sleeps. You give it instructions once, and it executes them endlessly—every minute, every hour, every month, or whenever you specify. Whether you're backing up databases, clearing log files, sending status reports, or pulling crypto prices for alerts, cron handles it silently in the background.

The beauty of cron is its simplicity. Unlike more complex automation platforms, it requires no UI, no cloud connection, and no monthly subscription. If you've got a Linux server—whether it's a Hetzner VPS or a DigitalOcean droplet—you've already got cron built in.

However, if you're managing dozens of workflows across multiple systems, you might eventually want to explore solutions like n8n Cloud, which centralizes your automation logic. But let's not get ahead of ourselves. Cron is perfect for many use cases, and understanding it is fundamental.

Crontab Syntax Breakdown

The magic happens in a file called a crontab (cron table). Each line in your crontab represents one scheduled task, and each line follows this exact format:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 7) (0 and 7 are Sunday)
│ │ │ │ │
│ │ │ │ │
* * * * * command-to-execute

Let me break this down with actual examples so you see how it works:

0 2 * * * /home/user/backup.sh

This runs /home/user/backup.sh at 2:00 AM every single day. The first 0 means minute 0 (top of the hour), 2 is 2 AM, and the three asterisks mean "every day, every month, any day of week."

*/15 * * * * /usr/bin/python3 /home/user/check_status.py

The */15 means "every 15 minutes." This Python script runs four times per hour, all day, every day.

0 0 1 * * /home/user/monthly_report.sh

This runs on the first day of every month at midnight. Perfect for monthly tasks.

30 3 * * 1 /home/user/weekly_backup.sh

This runs every Monday at 3:30 AM. The 1 represents Monday (0=Sunday, 1=Monday, etc.).

Here's a quick reference table for common time expressions:

@yearly      0 0 1 1 *     (once per year on January 1st)
@monthly     0 0 1 * *     (once per month on the 1st)
@weekly      0 0 * * 0     (once per week on Sunday at midnight)
@daily       0 0 * * *     (once per day at midnight)
@hourly      0 * * * *     (once per hour)
@reboot      -             (when the system boots up)

These shortcuts make crontabs more readable. @hourly is much cleaner than 0 * * * *.

Creating and Managing Your First Cron Job

Let's get practical. I'm going to walk you through creating a real cron job from scratch.

Step 1: Open Your Crontab

On your Linux server, open the crontab editor:

crontab -e

This opens your personal crontab in your default editor (usually nano or vim). If it's your first time, you'll see a blank file with some commented instructions at the top.

Step 2: Write Your Script

First, let's create the script you want to run. I'll create a simple backup script. Open a new file:

nano /home/user/backup_logs.sh

Add this content:

#!/bin/bash

BACKUP_DIR="/backups"
SOURCE_DIR="/var/log"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR

tar -czf $BACKUP_DIR/logs_backup_$DATE.tar.gz $SOURCE_DIR

find $BACKUP_DIR -name "logs_backup_*.tar.gz" -mtime +7 -delete

echo "Backup completed at $(date)" >> /var/log/backup.log

Save the file (Ctrl+O, Enter, Ctrl+X in nano), then make it executable:

chmod +x /home/user/backup_logs.sh

Step 3: Add the Cron Job

Now open your crontab again:

crontab -e

Add this line at the bottom:

0 3 * * * /home/user/backup_logs.sh

This runs your backup script every day at 3:00 AM.

Step 4: Verify It's Scheduled

List your cron jobs to confirm they were added:

crontab -l

You should see your new job listed. That's it—you're done. The script will run automatically from now on.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Real-World Examples and Use Cases

Let me show you some practical cron jobs I've actually used in production environments. These patterns solve real problems.

Database Backups Every 6 Hours

0 */6 * * * /usr/bin/mysqldump -u root -pYourPassword database_name > /backups/db_$(date +\%Y\%m\%d_\%H\%M\%S).sql

This backs up your MySQL database every 6 hours. The backticks escape the date command so it's evaluated at runtime.

Clean Up Old Log Files

0 2 * * * find /var/log/nginx -name "*.log" -mtime +30 -delete

Runs at 2 AM daily, deleting nginx logs older than 30 days. Essential for preventing disk space issues.

Sync Files to Remote Server

30 4 * * * rsync -avz --delete /home/user/data/ user@remote.server:/backup/data/

Syncs your data directory to a remote server at 4:30 AM every day. Great for distributed backups.

Check Website Uptime

*/5 * * * * /home/user/check_uptime.sh

Here's what check_uptime.sh might look like:

#!/bin/bash

WEBSITE="https://example.com"
LOGFILE="/var/log/uptime_check.log"

if curl -s --max-time 5 "$WEBSITE" > /dev/null; then
    echo "$(date) - $WEBSITE is UP" >> $LOGFILE
else
    echo "$(date) - $WEBSITE is DOWN - sending alert" >> $LOGFILE
    echo "Website down!" | mail -s "Alert: $WEBSITE Down" admin@example.com
fi

This checks every 5 minutes and sends an email if the site is down.

Generate Daily Reports

0 8 * * * /usr/bin/python3 /home/user/generate_report.py

Run a Python script at 8 AM to generate reports. Here's a sample script:

#!/usr/bin/env python3

import subprocess
from datetime import datetime

report_date = datetime.now().strftime("%Y-%m-%d")
output_file = f"/reports/report_{report_date}.txt"

with open(output_file, "w") as f:
    f.write(f"Daily Report for {report_date}\n")
    f.write("=" * 40 + "\n")

    disk_usage = subprocess.check_output(["df", "-h"], text=True)
    f.write("Disk Usage:\n")
    f.write(disk_usage)
    f.write("\n")

    memory = subprocess.check_output(["free", "-h"], text=True)
    f.write("Memory Status:\n")
    f.write(memory)

print(f"Report generated: {output_file}")

Restart Services If Down

*/10 * * * * /home/user/check_service.sh

Here's the script:

#!/bin/bash

SERVICE_NAME="nginx"

if ! systemctl is-active --quiet $SERVICE_NAME; then
    echo "$(date) - $SERVICE_NAME was down, restarting..." >> /var/log/service_restarts.log
    systemctl restart $SERVICE_NAME
fi

Checks every 10 minutes and restarts nginx if it's not running.

If you're automating data collection across multiple systems, you might eventually want to centralize your workflows. Check out our guide on How to Set Up a VPS for Automation (Hetzner vs Contabo vs Railway) to understand hosting options that work well with automation systems.

Debugging and Monitoring Cron Jobs

Here's where most people struggle. A cron job runs silently, and when something breaks, you won't know unless you look at the logs.

Check If Cron Daemon Is Running

sudo service cron status

On some systems:

sudo systemctl status cron

If it's not running:

sudo systemctl start cron
sudo systemctl enable cron

View Cron Logs (Ubuntu/Debian)

sudo grep CRON /var/log/syslog

Or on newer systems:

sudo journalctl -u cron --no-pager

This shows all cron activity. You'll see lines like:

Nov 15 03:00:01 myserver CRON[12345]: (user) CMD (/home/user/backup_logs.sh)

Capture Output and Errors

Modify your crontab to save output:

0 3 * * * /home/user/backup_

Originally published on Automation Insider.

SQLite vs PostgreSQL for Small Projects: When to Use Which

Raizan — Wed, 06 May 2026 08:00:36 +0000

What You'll Need

n8n Cloud or self-hosted n8n for workflow automation
Hetzner VPS or Contabo VPS for hosting PostgreSQL instances
DigitalOcean as an alternative cloud provider
Namecheap for domain registration (optional)
SQLite (built-in to most systems) or PostgreSQL (free, open-source)

Understanding the Fundamentals
SQLite: Lightweight and Local
PostgreSQL: Scalable and Powerful
Head-to-Head Comparison
Migration Strategies
Real-World Use Cases
Getting Started

Understanding the Fundamentals

I've spent the last five years building small projects that started simple and ended up needing serious database muscle. The SQLite vs PostgreSQL decision isn't academic—it's the difference between shipping fast today and refactoring in panic mode six months from now.

SQLite is a file-based relational database that lives on your machine. No server, no network calls, no complexity. PostgreSQL is a heavyweight champion: a full-featured relational database server that handles concurrent users, complex transactions, and enterprise-grade reliability.

The wrong choice wastes weeks. The right one lets you scale without rewrites.

SQLite: Lightweight and Local

I reach for SQLite when I'm building a prototype, a CLI tool, or anything that doesn't need remote access. It's bundled with Python, Node.js, and most runtimes. Installation? You already have it.

SQLite stores everything in a single file. Your entire database is just database.db sitting on disk. This means:

Zero configuration
Instant backups (copy the file)
Perfect for local development
No network overhead
ACID compliance out of the box

Here's how you'd initialize a basic SQLite database in Node.js:

const sqlite3 = require('sqlite3').verbose();

const db = new sqlite3.Database('./myapp.db', (err) => {
  if (err) {
    console.error(err.message);
  } else {
    console.log('Connected to SQLite database');
  }
});

db.serialize(() => {
  db.run(`CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
  )`);

  db.run(`CREATE TABLE IF NOT EXISTS posts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id INTEGER NOT NULL,
    title TEXT NOT NULL,
    content TEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id)
  )`);

  console.log('Tables created successfully');
});

db.close((err) => {
  if (err) {
    console.error(err.message);
  }
});

Now let's add some data:

const sqlite3 = require('sqlite3').verbose();
const db = new sqlite3.Database('./myapp.db');

db.serialize(() => {
  const stmt = db.prepare('INSERT INTO users (name, email) VALUES (?, ?)');

  stmt.run('Alice Chen', 'alice@example.com', function(err) {
    if (err) console.error(err);
    else console.log('Inserted user with ID:', this.lastID);
  });

  stmt.run('Bob Martinez', 'bob@example.com', function(err) {
    if (err) console.error(err);
    else console.log('Inserted user with ID:', this.lastID);
  });

  stmt.finalize();

  db.all('SELECT * FROM users', [], (err, rows) => {
    if (err) throw err;
    console.log('All users:', rows);
  });
});

db.close();

SQLite handles single-process or light concurrent access beautifully. If you're building a Electron app, a mobile backend, or a data pipeline that runs on one machine, SQLite is your answer.

The catch? SQLite struggles with concurrent writes. It locks the entire database file during writes, which works fine for one user but explodes with multiple simultaneous requests. It also doesn't support replication or clustering. Scale beyond 100,000 records with multiple concurrent users, and you'll hit limitations.

PostgreSQL: Scalable and Powerful

PostgreSQL is the opposite: a client-server database that handles thousands of concurrent connections, advanced data types, full-text search, JSON storage, and nearly infinite scalability.

I use PostgreSQL when:

Multiple users hit the database simultaneously
I need advanced queries or complex joins
I'm building an API that serves a web or mobile app
I plan to grow beyond prototype stage
I need features like stored procedures or custom types

Setting up PostgreSQL requires more work. I typically deploy it on a Hetzner VPS or DigitalOcean using Docker:

version: '3.8'
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: securepassword123
      POSTGRES_DB: myapp_db
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  postgres_data:

Run this with:

docker-compose up -d

Now connect from Node.js using the pg library:

const { Pool } = require('pg');

const pool = new Pool({
  user: 'appuser',
  password: 'securepassword123',
  host: 'localhost',
  port: 5432,
  database: 'myapp_db'
});

pool.on('error', (err) => {
  console.error('Unexpected error on idle client', err);
});

const createTables = async () => {
  const client = await pool.connect();
  try {
    await client.query(`
      CREATE TABLE IF NOT EXISTS users (
        id SERIAL PRIMARY KEY,
        name VARCHAR(255) NOT NULL,
        email VARCHAR(255) UNIQUE NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
      )
    `);

    await client.query(`
      CREATE TABLE IF NOT EXISTS posts (
        id SERIAL PRIMARY KEY,
        user_id INTEGER NOT NULL REFERENCES users(id),
        title VARCHAR(255) NOT NULL,
        content TEXT,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
      )
    `);

    console.log('Tables created successfully');
  } finally {
    client.release();
  }
};

createTables().catch(console.error);

Insert and query data:

const { Pool } = require('pg');

const pool = new Pool({
  user: 'appuser',
  password: 'securepassword123',
  host: 'localhost',
  port: 5432,
  database: 'myapp_db'
});

const addUser = async (name, email) => {
  const result = await pool.query(
    'INSERT INTO users (name, email) VALUES ($1, $2) RETURNING id, name, email, created_at',
    [name, email]
  );
  return result.rows[0];
};

const getAllUsers = async () => {
  const result = await pool.query('SELECT id, name, email, created_at FROM users ORDER BY created_at DESC');
  return result.rows;
};

const getUserWithPosts = async (userId) => {
  const result = await pool.query(`
    SELECT 
      u.id, u.name, u.email, u.created_at,
      json_agg(json_build_object('id', p.id, 'title', p.title, 'content', p.content)) as posts
    FROM users u
    LEFT JOIN posts p ON u.id = p.user_id
    WHERE u.id = $1
    GROUP BY u.id, u.name, u.email, u.created_at
  `, [userId]);
  return result.rows[0];
};

(async () => {
  try {
    const newUser = await addUser('Carol Davis', 'carol@example.com');
    console.log('Created user:', newUser);

    const allUsers = await getAllUsers();
    console.log('All users:', allUsers);

    const userDetail = await getUserWithPosts(newUser.id);
    console.log('User with posts:', userDetail);
  } catch (err) {
    console.error('Database error:', err);
  } finally {
    await pool.end();
  }
})();

PostgreSQL also handles JSON natively, which is perfect if you're storing flexible data. Notice in the query above I'm using json_agg and json_build_object—these are PostgreSQL features that SQLite can't match.

💡 Fast-Track Your Project: Don't want to configure this yourself? I build custom n8n pipelines and bots. Message me with code SYS3-DEVTO.

Head-to-Head Comparison

Here's a decision matrix I use:

Choose SQLite if:

Your app is a single-user tool or runs on one machine
You're prototyping or building a proof of concept
You need zero DevOps burden
File-based storage works for your architecture
You're embedding a database in a game, desktop app, or CLI tool
You have fewer than 10,000 daily transactions

Choose PostgreSQL if:

Multiple users access the database simultaneously
You're building a web API or SaaS product
You need replication, backups, or high availability
Your data is complex or relational with many joins
You plan to scale beyond prototype stage
You need features like JSONB, full-text search, or arrays
Your infrastructure already supports Docker or cloud deployments

I've also seen projects successfully run SQLite at scale when stored on high-performance NVMe drives and accessed by a single process (think a data warehouse that loads once daily). Don't assume SQLite is always "too small"—it's about your access pattern, not your dataset size.

Migration Strategies

I've migrated three projects from SQLite to PostgreSQL. Here's how to do it without losing sleep.

First, export your SQLite data as SQL:

sqlite3 myapp.db .dump > backup.sql

This creates a portable SQL file. Now here's the tricky part: SQLite and PostgreSQL have syntax differences. SQLite's AUTOINCREMENT and CURRENT_TIMESTAMP don't translate directly.

Create a migration script that handles these differences:

import sqlite3
import psycopg2
from psycopg2 import sql
import sys

sqlite_db = 'myapp.db'
pg_host = 'localhost'
pg_user = 'appuser'
pg_password = 'securepassword123'
pg_db = 'myapp_db'

sqlite_conn = sqlite3.connect(sqlite_db)
sqlite_cursor = sqlite_conn.cursor()

pg_conn = psycopg2.connect(
    host=pg_host,
    user=pg_user,
    password=pg_password,
    database=pg_db
)
pg_cursor = pg_conn.cursor()

sqlite_cursor.execute("SELECT name FROM sqlite_master WHERE type='table';")
tables = sqlite_cursor.fetchall()

for table_name in tables:
    table = table_name[0]

Originally published on Automation Insider.

Forem: Raizan

Airflow vs n8n vs Temporal for API workflows

What You'll Need

Table of Contents

Why This Comparison Matters

Understanding Airflow, n8n, and Temporal

Architecture & Deployment Models

Airflow's Architecture

n8n's Architecture

Temporal's Architecture

Building Your First API Workflow

Airflow Approach

n8n Approach

Build Custom Webhooks Without Coding Tools

What You'll Need

Table of Contents

Understanding Webhooks Without the Code

Setting Up Your First Webhook Receiver

Building Webhook Workflows That React to Data

Transforming and Routing Webhook Payloads

Testing Your Webhooks in Production

Best n8n Alternatives for API-First Developers 2026

What You'll Need

Table of Contents

Why Developers Are Moving Beyond n8n

The API-First Workflow Automation Landscape

Top n8n Alternatives for API-Driven Teams

1. Temporal: Workflow Orchestration for Serious Infrastructure

2. Make.com: The Visual Powerhouse with Deep Integration

3. Zapier with Custom Actions & API Tools

4. Deno Deploy + Fresh: Serverless API Automation

Airflow vs n8n for API-driven data pipelines

What You'll Need

Table of Contents

Understanding Airflow and n8n

Architecture and Deployment Models

Building Your First API-Driven Pipeline

Airflow Approach

n8n Approach

Temporal vs n8n vs Airflow for Data Pipelines

What You'll Need

Table of Contents

The Big Picture: Why This Matters

Temporal: The Enterprise-Grade Workflow Engine

n8n: The Visual Automation Platform

Apache Airflow: The Python-Native Orchestrator

Temporal vs Make for API-First Workflows

What You'll Need

Table of Contents

What's the Real Difference Between Temporal and Make?

Temporal: The Orchestration Engine Approach

Setting Up Temporal Locally

Make: The Visual No-Code Platform

Make vs n8n vs Zapier API integrations 2026

What You'll Need

Table of Contents

The 2026 Automation Landscape

n8n API Integration Strategy

Make.com's Native Connectors vs Custom APIs

Zapier's Webhook-First Approach

Temporal vs n8n for Microservices Orchestration

What You'll Need

Table of Contents

What is Temporal?

What is n8n?

Architecture Comparison

Building a Microservice Workflow with Temporal

Building the Same Workflow with n8n

Building Custom Webhooks vs Using n8n Triggers

What You'll Need

Table of Contents

Understanding Webhooks and Triggers

When to Build Custom Webhooks

Building a Custom Webhook Server

Using n8n Triggers: The Simpler Path

Performance and Cost Comparison

How I Run 3 Automated Systems on a Single $7/Month VPS

What You'll Need

Table of Contents

The Reality of Running Multiple Systems on Minimal Infrastructure {#reality}