Set Up a Development Instance with Mock Data

Testing against production APIs risks real emails, real charges, and polluted CRM data. Run a separate n8n development instance on its own port with sandbox or test credentials, mock API workflows for services that have no sandbox, and all workflows inactive by default. This eliminates accidental production side effects and keeps test costs at zero while you build and iterate.

Why run a separate n8n development instance?

Never test against production APIs when you can avoid it. Run a separate n8n development instance that uses mock data, test credentials, and sandbox API endpoints. This eliminates accidental production side effects and keeps test costs at zero.

Real-world example: Your team builds workflows that interact with Stripe, SendGrid, and Salesforce. Testing against production risks sending real emails, charging real cards, and polluting CRM data.

How do you set up a dev instance with mock data?

# docker-compose.dev.yml -- Development n8n instance

version: '3.8'
services:
  n8n-dev:
    image: n8nio/n8n:latest
    ports:
      - "5679:5678"    # Different port from production

    environment:
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - WEBHOOK_URL=http://localhost:5679/
      - NODE_ENV=development
      # Use sandbox/test API keys

      - STRIPE_API_KEY=sk_test_xxxxxxxxxxxx
      - SENDGRID_API_KEY=SG.test_xxxxxxxxxxxx
    volumes:
      - n8n_dev_data:/home/node/.n8n

Create mock API endpoints using a simple n8n workflow on the dev instance:

// Code node in a "Mock API" workflow
// Webhook path: mock/stripe/charges
const mockResponses = {
  'charges': {
    id: 'ch_mock_' + Date.now(),
    amount: 2000,
    currency: 'usd',
    status: 'succeeded',
    created: Math.floor(Date.now() / 1000)
  },
  'customers': {
    id: 'cus_mock_' + Date.now(),
    email: 'test@example.com',
    name: 'Test Customer'
  }
};

const resource = $input.first().json.params.resource || 'charges';
return [{
  json: mockResponses[resource] || { error: 'Unknown resource' }
}];

Credential management strategy:
  Production instance:
    - Real API keys stored in n8n credentials
    - Workflows activated and processing live data

  Development instance:
    - Test/sandbox API keys only
    - Mock workflows for services without sandboxes
    - All workflows default to inactive
    - Pinned test data for common scenarios

How should you manage dev versus production credentials?

Tip: Use n8n's environment variable credentials Store API keys as environment variables (STRIPE_API_KEY, etc.) and reference them in credentials. Switching between dev and prod is then just a matter of which environment file is loaded -- the workflows themselves do not change.

This prevents the "I accidentally emailed 10,000 customers from my test workflow" disaster.

Related: Use Structured Output (JSON Mode) for Parseable Responses · Configure Payload Size and Binary Data Mode for Large Files