n8nticket – Secure Telegram → Ticket Automation with n8n, Postgres & Caddy

1. From Noisy Telegram Chats to Real Tickets

If you’ve ever handled support or internal IT through a Telegram group, you know the pattern: someone drops a problem, a short discussion happens, and then the message gets buried under GIFs and “thanks 🙏”.

It works for a while, but as soon as you want to answer questions like “how many tickets did we close this week?” or “what issues hit the VPN most often?”, you’re stuck scrolling.

n8nticket is my attempt to keep the convenience of chat while adding just enough structure:

• Users talk to a Telegram bot instead of flooding a group.
• The bot collects a few fields (name, ID, title, description, priority).
• n8n validates and enriches the data.
• A ticket is written into PostgreSQL with a real ticket_id, timestamps, and status.

The result: your workflow still feels like ChatOps, but you can now build dashboards, reports, and automations on top of a clean database.

2. Architecture & Stack Overview

The repository lives at github.com/ciscoAnass/n8nticket , and it’s intentionally small: one docker-compose.yml, a Caddyfile, an init.sql for the database, a shell script to set the Telegram webhook, and an n8n workflow to import.

At a high level:

• Telegram Bot – the user talks to this instead of a noisy group.
• Caddy – public HTTPS reverse proxy, takes traffic on :443.
• n8n – automation engine with a Telegram Trigger + Postgres nodes.
• PostgreSQL – stores a tickets table with constraints and a trigger.

Here’s the repo tree you get after cloning:

.
├── Caddyfile
├── docker-compose.yml
├── n8n/
│   └── workflows/
│       └── telegram_inbound.json
├── scripts/
│   └── set_webhook.sh
├── sql/
│   └── init.sql
└── ssl/
    ├── ca.crt
    ├── ca.key
    ├── ca.srl
    ├── n8n.crt
    ├── n8n.csr
    └── n8n.key

3. Implementation – From Clone to First Ticket

Let’s go step by step: clone the repo, configure the stack, and send the first test ticket.

3.1 Clone, configure .env and bring up the stack

First, clone the repository and copy the example environment file:

git clone https://github.com/ciscoAnass/n8nticket.git
cd n8nticket

cp .env.example .env
# Edit .env with your values

Key things to check inside .env:

• Postgres settings: user, password, database name.
• N8N_HOST and N8N_WEBHOOK_URL: the public hostname that Caddy will serve (can be an ngrok URL while testing).
• N8N_ENCRYPTION_KEY: a secret for n8n (32 chars).
• Telegram details: TELEGRAM_BOT_TOKEN and ADMIN_CHAT_ID.
• CADDY_EMAIL for automatic TLS certificates.

Then generate the internal TLS material for the hop between Caddy and n8n:

mkdir -p ssl

# 1) Internal CA
openssl genrsa -out ssl/ca.key 4096
openssl req -x509 -new -key ssl/ca.key -days 3650 -sha256 \
  -subj "/CN=n8n-internal-ca" -out ssl/ca.crt

# 2) n8n server cert (CN=n8n)
openssl genrsa -out ssl/n8n.key 2048
openssl req -new -key ssl/n8n.key -subj "/CN=n8n" -out ssl/n8n.csr
openssl x509 -req -in ssl/n8n.csr -CA ssl/ca.crt -CAkey ssl/ca.key -CAcreateserial \
  -days 825 -sha256 -extfile <(printf "subjectAltName=DNS:n8n") -out ssl/n8n.crt

Now start everything with Docker:

docker compose up -d
docker compose ps

At this point:

• Postgres is initialized with a tickets table and a trigger that maintains resolving_date based on status.
• n8n is running behind Caddy on HTTPS.
• The n8n UI should be reachable at https://$N8N_HOST.

3.2 Telegram bot, webhook and n8n workflow

The second piece is connecting Telegram and n8n so chat messages can trigger the ticket workflow.

1. Create a bot with @BotFather and copy the bot token into TELEGRAM_BOT_TOKEN in .env.
2. Get your admin chat ID by sending /start to the bot and calling Telegram’s getUpdates API.
3. Run the provided script (or call the API yourself) to set the bot’s webhook to your public N8N_WEBHOOK_URL.

Inside the n8n UI:

• Import n8n/workflows/telegram_inbound.json.
• Configure the Telegram and Postgres credentials using the same values from .env.
• Activate the workflow.

From the user’s perspective, the flow is simple:

1. They send a message to the Telegram bot.
2. The bot walks them through a few questions (who you are, what’s broken, priority).
3. Optionally, a language model suggests a quick fix or context.
4. n8n writes a new row into the tickets table and sends a summary back.

4. Design Choices & Lessons Learned

• Keep it self-hosted. Running n8n and Postgres yourself means your ticket data never leaves your infra.
• Make AI optional. The automation works even if you drop the LLM node; the “proposed fix” is a nice-to-have, not a hard dependency.
• Secure by default. Caddy terminates public TLS, but there’s a second TLS hop to n8n inside the Docker network with its own internal CA.
• Use the database as the source of truth. The schema, constraints, and trigger logic make sure tickets stay consistent even if the workflow changes.
• Scripts beat long docs. A small set_webhook.sh script is easier to reuse than copying curl commands every time.

5. Next Steps & Ideas to Extend

n8nticket is meant as a starting point. Here are a few directions I’m considering (and that you might want to explore too):

• Small web dashboard to browse, filter and update tickets (e.g. with a minimal FastAPI + HTMX UI).
• Metrics and observability: export counts and timings to Prometheus and build a Grafana dashboard for ticket SLAs.
• Multi-channel intake: add email, web forms, or Slack as extra entry points that all end in the same tickets table.
• Asset/context enrichment: enrich tickets with device, VPN gateway, office site or user group based on IDs.
• Multiple environments: dev / staging / prod stacks for n8n with different bots and databases but identical workflows.

The core pattern stays the same: reverse proxy → n8n → Postgres. You can swap the “ticket” concept for almost anything that starts in chat.