Signal Replaces Telegram in Our Automation Stack

Until now, automated notifications from our AI workflows arrived on Telegram. It’s convenient, but it isn’t private: Telegram bot messages travel through Telegram’s servers in plaintext, with no end-to-end encryption at any point. We’ve now built our own Signal Messenger integration — self-hosted, running locally on our own server — to move these notifications, and increasingly our AI conversations, onto a channel that actually protects the message on the wire.

The system uses signal-cli wrapped in a REST layer, orchestrated by n8n automation workflows, and exposed through an MCP connector so AI clients can send Signal messages directly — no third-party bot platform involved anywhere in the chain.

Simplified diagram of the Signal architecture: phones connect to signal-api, which feeds n8n and the MCP connector on our own server, alongside Open WebUI and the chat bots, with Claude and the Venice AI TEE model as external services

A simplified view of the setup: signal-api, n8n, Open WebUI and the chat bots all run on our own server; only Claude and the Venice AI model sit outside it.

Why We Moved Off Telegram

Telegram’s bot API is plaintext by design — messages transit Telegram’s infrastructure unencrypted, regardless of what happens on the client. Signal, by contrast, is end-to-end encrypted between devices: its servers never see the content of a message. That’s a substantial privacy upgrade for anything an AI agent sends or reads on our behalf, and it’s a channel we already trust for personal use.

Self-Hosted On Our Own Server

The whole stack runs on infrastructure we control: signal-cli and the automation logic live on our own server, not on any external vendor’s platform. The system has its own dedicated Signal account and phone number — entirely separate from any personal account — so automation traffic never mixes with personal messaging. New workflows are being built against Signal going forward, and existing Telegram notifications are being gradually migrated over as each one is moved across.

Open WebUI, Claude, and Beyond

The Signal integration is exposed as an MCP (Model Context Protocol) tool, so any MCP-compatible AI client can send messages through it. In practice, that’s mostly Open WebUI — our day-to-day interface for local and private models — which can now message over Signal directly, alongside Claude and any other MCP-aware client we connect in future. Only trusted, explicitly authorized users can interact with the bot this way; nobody else can reach it, request it, or use it to relay a message.

Chat Bots for DMs and Groups

Beyond simple sending, we’ve built conversational chat bots on top of the same integration — one for direct messages, one for group chats — running on Venice AI’s private TEE (trusted execution environment) models. The bot has no direct access from the outside internet: it sits behind server-side filters and rules, and answers only conversations from allowlisted, trusted senders. Everyone else is silently ignored.

Together, this gives our automated workflows and our AI clients a genuinely encrypted messaging channel, without relying on anyone else’s bot infrastructure.

Key Takeaways

  • We built a self-hosted Signal Messenger integration (signal-cli + n8n) with its own dedicated Signal account, replacing Telegram for new automated notifications.
  • An MCP connector lets AI clients — Open WebUI foremost, plus Claude and other MCP-compatible tools — send Signal messages, but only for trusted, authorized users.
  • The bot has no direct exposure to the outside internet; it’s protected by server-side filters, rules, and an allowlist of trusted senders.
  • Conversational chat bots for direct messages and group chats run on Venice AI’s private TEE models.
  • Not for confidential matters: messages are end-to-end encrypted in transit, but the last 30 days of message history are stored in the server’s own chat database.

Photo: Brett Jordan via Pexels

Scroll to Top