Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevMauricio03/n8n-whatsapp-ai-agent/llms.txt

Use this file to discover all available pages before exploring further.

Every external service used by the n8n WhatsApp AI Agent platform maintains its own versioned documentation. Configuration options, API contracts, and deployment requirements can change between releases, so it is essential to read the documentation that matches the specific version you are deploying rather than relying on a cached or summarized version. This page collects the official documentation links for all platform dependencies in one place.

​
Official Documentation

n8n — Docker Compose Setup

Official guide for self-hosting n8n using Docker Compose, including volume mounts, networking, and initial configuration.

n8n — Environment Variables

Full reference for every environment variable supported by n8n, including encryption, execution, and webhook settings.

Chatwoot — Docker Deployment

Step-by-step instructions for deploying Chatwoot with Docker, covering database initialization and service dependencies.

Chatwoot — Environment Variables

Complete environment variable reference for Chatwoot, including storage, email, Redis, and feature-flag settings.

Caddy — Automatic HTTPS

How Caddy provisions and renews TLS certificates automatically via Let’s Encrypt, including DNS challenge and port requirements.

Docker Engine — Ubuntu Install

Official instructions for installing Docker Engine and the Compose plugin on Ubuntu, including the repository setup and post-install steps.

WhatsApp Cloud API

Meta’s developer documentation for the WhatsApp Cloud API: phone number management, message sending, media handling, and webhook verification.

OpenAI — Safety Best Practices

OpenAI’s official guidelines for building safe AI-powered applications, covering prompt design, output validation, and content moderation.

​
Version Pinning Policy

The image tags included in .env.example represent a validated baseline — a combination of versions that was known to work together at the time the template was created. They are not a guarantee of future compatibility, and they should not be treated as the latest recommended versions.
Always read the release notes for every service before updating to a new version in production. Breaking changes in Chatwoot’s webhook payload structure, n8n’s node API, or the WhatsApp Graph API version can silently break workflows without producing obvious errors at startup.
For every production deployment, follow this five-step versioning policy:
  1. Select compatible versions — cross-reference the release notes of each service to identify a combination where no component has a known breaking change against the others. Pay particular attention to PostgreSQL major versions and n8n node-library compatibility.
  2. Record the validation date — document the specific versions you tested together and the date on which you confirmed they work. This creates an audit trail and makes future upgrades easier to scope.
  3. Pin the exact tag or digest — in .env, replace symbolic tags (e.g., latest, v4) with exact version tags (e.g., chatwoot/chatwoot:v4.4.0) or image digests. This ensures that docker compose pull never silently replaces a validated image.
  4. Test in staging before production — apply all version updates to a staging environment first and run through the full test checklist before promoting to production.
  5. Update deliberately, never automatically — do not configure Watchtower, Renovate, or any other tool to automatically update container images in production. Every update is a deliberate change that requires a test cycle and a documented rollback plan.

Build docs developers (and LLMs) love

Get started for freeTalk to us