# Multi-Instance Examples
Real-world examples and patterns for multi-instance n8n management.
---
## Example 1: Development to Production Pipeline
### Scenario
Develop workflow locally, test in staging, deploy to production.
### Workflow
```
Step 1: Create in Development
User: "Create a workflow called 'Daily Report' in development that runs at 9 AM"
Step 2: Test Locally
User: "Activate workflow in development"
User: "Show recent executions from development"
Step 3: Clone to Staging
User: "Get workflow 'Daily Report' from development"
User: "Create that workflow in staging"
Step 4: QA Testing
User: "Activate workflow in staging"
User: "Monitor executions from staging for 24 hours"
Step 5: Deploy to Production
User: "Get workflow 'Daily Report' from staging"
User: "Create that workflow in production"
User: "Activate workflow in production"
Step 6: Monitor Production
User: "Show production executions for 'Daily Report'"
```
### Benefits
- ✅ Safe testing in isolated environments
- ✅ Gradual rollout
- ✅ Easy rollback (deactivate production)
- ✅ Clear audit trail
---
## Example 2: Team Collaboration
### Scenario
Multiple team members working on different environments.
### Setup
```json
{
"environments": {
"production": {
"n8n_host": "https://prod.n8n.company.com",
"n8n_api_key": "prod_key"
},
"staging": {
"n8n_host": "https://staging.n8n.company.com",
"n8n_api_key": "staging_key"
},
"dev-alice": {
"n8n_host": "https://dev-alice.n8n.company.com",
"n8n_api_key": "alice_key"
},
"dev-bob": {
"n8n_host": "https://dev-bob.n8n.company.com",
"n8n_api_key": "bob_key"
}
},
"defaultEnv": "dev-alice"
}
```
### Usage
**Alice (Developer):**
```
List workflows in dev-alice
Create workflow in dev-alice
Test in dev-alice
Push to staging when ready
```
**Bob (Developer):**
```
List workflows in dev-bob
Create workflow in dev-bob
Test in dev-bob
Push to staging when ready
```
**QA Team:**
```
List workflows in staging
Test all staging workflows
Approve for production
```
**Ops Team:**
```
List workflows in production
Monitor executions in production
Manage production deployments
```
---
## Example 3: Geographic Load Balancing
### Scenario
Distribute workflows across regions for performance.
### Configuration
```json
{
"environments": {
"us-east": {
"n8n_host": "https://n8n-us.example.com",
"n8n_api_key": "us_key"
},
"eu-west": {
"n8n_host": "https://n8n-eu.example.com",
"n8n_api_key": "eu_key"
},
"asia": {
"n8n_host": "https://n8n-asia.example.com",
"n8n_api_key": "asia_key"
}
},
"defaultEnv": "us-east"
}
```
### Workflow Distribution
```
US Customers:
→ Create workflows in us-east
→ Lower latency for US users
EU Customers:
→ Create workflows in eu-west
→ GDPR compliance + performance
Asian Customers:
→ Create workflows in asia
→ Reduced latency
```
---
## Example 4: Blue-Green Deployment
### Scenario
Zero-downtime workflow updates using two production instances.
### Configuration
```json
{
"environments": {
"production-blue": {
"n8n_host": "https://blue.n8n.example.com",
"n8n_api_key": "blue_key"
},
"production-green": {
"n8n_host": "https://green.n8n.example.com",
"n8n_api_key": "green_key"
},
"staging": {
"n8n_host": "https://staging.n8n.example.com",
"n8n_api_key": "staging_key"
}
},
"defaultEnv": "production-blue"
}
```
### Deployment Process
```
Current: Blue is live (active workflows)
Goal: Deploy new version to Green, then switch
Step 1: Deploy to Green
→ "Create workflows in production-green"
→ "Activate workflows in production-green"
Step 2: Validate Green
→ "Monitor executions from production-green"
→ Ensure no errors
Step 3: Switch Traffic
→ Update load balancer or DNS
→ Green becomes primary
Step 4: Deactivate Blue
→ "Deactivate all workflows in production-blue"
→ Keep as backup
Step 5: Next Deployment
→ Deploy to Blue (now idle)
→ Switch back to Blue
```
---
## Example 5: Feature Flag Testing
### Scenario
Test new workflow features with percentage rollout.
### Configuration
```json
{
"environments": {
"production": {
"n8n_host": "https://prod.n8n.example.com",
"n8n_api_key": "prod_key"
},
"production-beta": {
"n8n_host": "https://beta.n8n.example.com",
"n8n_api_key": "beta_key"
}
},
"defaultEnv": "production"
}
```
### Rollout Strategy
```
Phase 1: 10% Traffic
→ Create workflow in production-beta
→ Route 10% of triggers to beta
→ Monitor error rates
Phase 2: 50% Traffic
→ If stable, increase to 50%
→ Compare metrics: beta vs production
Phase 3: 100% Migration
→ Clone workflow to production
→ Deactivate production-beta version
→ Full rollout complete
```
---
## Example 6: Disaster Recovery
### Scenario
Quick failover to backup instance on primary failure.
### Configuration
```json
{
"environments": {
"production-primary": {
"n8n_host": "https://n8n-primary.example.com",
"n8n_api_key": "primary_key"
},
"production-backup": {
"n8n_host": "https://n8n-backup.example.com",
"n8n_api_key": "backup_key"
}
},
"defaultEnv": "production-primary"
}
```
### Failover Process
```
Detection: Primary instance down
→ "List workflows from production-primary"
→ Error: Connection refused
Activation: Failover to backup
→ "List workflows from production-backup"
→ Verify workflows exist (replicated)
→ "Activate all workflows in production-backup"
Recovery: Restore primary
→ Wait for primary recovery
→ Sync workflows from backup to primary
→ Switch back to primary
→ "Deactivate workflows in production-backup"
```
---
## Best Practices
### Environment Organization
!!! tip "Naming Conventions"
**Environments:**
- `production` - Live system
- `staging` - Pre-production
- `development` - Local dev
- `qa` - QA testing
- `demo` - Customer demos
**Geographic:**
- `us-east`, `us-west`
- `eu-central`, `eu-west`
- `asia-pacific`
### Workflow Promotion
!!! tip "Safe Promotion"
```
1. Create in development
2. Test thoroughly
3. Clone to staging
4. QA validation
5. Clone to production
6. Gradual activation
7. Monitor closely
```
### Configuration Management
!!! tip "Config Organization"
**Separate Configs:**
- `.config.dev.json` - Development team
- `.config.qa.json` - QA team
- `.config.ops.json` - Operations team
**Load Appropriate Config:**
```bash
cp .config.ops.json .config.json
```
### Monitoring
!!! tip "Multi-Instance Monitoring"
```
Daily: Check all instances for failures
Weekly: Compare execution metrics
Monthly: Sync workflows across instances
```
---
## Common Patterns
### Pattern 1: Environment Parity
Keep staging identical to production:
```
1. List workflows in production
2. For each workflow:
- Get workflow from production
- Create/update in staging
3. Result: Staging mirrors production
```
### Pattern 2: Selective Deployment
Deploy specific workflows only:
```
1. Tag workflows for deployment
→ "Add tag 'deploy-next' to workflow 15"
2. List workflows with tag
→ "List workflows tagged 'deploy-next' in staging"
3. Clone to production
→ For each workflow in list, clone to production
```
### Pattern 3: Canary Testing
Test with subset of traffic:
```
1. Create workflow in production-canary
2. Route 5% traffic to canary
3. Monitor for 24 hours
4. If stable, deploy to production-main
5. If issues, deactivate canary
```
---
## Next Steps
- [Configuration Guide](configuration.md) - Setup instructions
- [Environment Manager](environment-manager.md) - Technical details
- [Instance Routing](instance-routing.md) - Routing mechanics
- [API Reference](../api/overview.md) - Tool specifications
---
!!! success "Multi-Instance Patterns"
These patterns enable professional workflow management with safety, scalability, and team collaboration.
