n8n is the workflow-automation layer behind several personal AI and reporting projects. It runs scheduled pipelines, coordinates Dockerised jobs, calls external services, and sends results to email, messaging, or downstream AI tools.
This post captures reusable lessons shared across projects rather than duplicating every workflow node and internal identifier.
Architecture Pattern
- n8n starts a workflow from a schedule or explicit trigger.
- The workflow connects to the Docker host through SSH.
- A disposable container runs the project command.
- The command reads or writes project data, such as PostgreSQL or an external API.
- n8n checks the process exit code and captures output.
- Successful results continue to reporting or AI analysis.
- Failures follow a controlled notification or retry path.
Shared Lessons
Check Exit Codes, Not stderr
Docker and Python can write normal informational output to stderr. Treating any stderr output as failure creates false alarms. Workflow success should primarily follow the process exit code, with exitCode > 0 treated as failure.
SSH from n8n to the Docker Host
When n8n runs inside its own container, it may not have direct access to the host Docker daemon. The reliable pattern is to SSH to the host and run the required Docker Compose command there.
Use Disposable Containers
Scheduled scripts run with docker compose run --rm. Each job gets a clean container, and completed containers are removed automatically instead of accumulating between runs.
Stagger Workflows Sharing One Service
Two scheduled workflows that launch the same named Compose service can collide. Staggering their start times prevents container-name conflicts and makes resource use more predictable.
Garmin Training Management
The Garmin project uses several scheduled workflows:
- store daily health and training metrics;
- generate a daily coaching report;
- prepare morning training readiness;
- monitor heart-rate data collection health;
- create a weekly trainer report.
These workflows combine wearable data, Dockerised processing, stored history, AI-supported analysis, and scheduled delivery.
Activity Tracking and Reporting
A second system synchronises completed Notion activity records into PostgreSQL, then creates daily and weekly reports. Notion provides tamper-resistant system timestamps, while n8n handles scheduled synchronisation and delivery.
- Midnight sync copies completed, unsynchronised records into PostgreSQL.
- Daily reporting compares current activity against a rolling baseline.
- Weekly reporting produces totals and subject/day breakdowns.
- Successful synchronisation marks source records to prevent duplicate processing.
Where MCP Fits
An n8n MCP server can let an AI coding agent inspect and manage workflow definitions during development. MCP is the development connection; n8n remains the production orchestrator. Publishing, scheduling, retries, credentials, and execution monitoring should remain explicit operational concerns rather than being hidden inside prompts.
Design Principles
- Keep schedules and side effects visible in n8n.
- Keep deterministic data processing inside versioned scripts.
- Use AI for analysis and drafting, not as the only production control mechanism.
- Make retries bounded and idempotent.
- Preserve execution evidence and failure reasons.
- Test notification paths separately from processing logic.
- Separate private operational configuration from public architecture documentation.