TelegramPlugin architectureBullMQMulti-tenant

Plataforma Telegram com 41 Plugins e Multi-Tenancy SaaS

Perfil:Produto interno Tyber.io

Construí uma plataforma de bot Telegram que roda 41 plugins independentes em um único runtime grammY, com cofre de credenciais por tenant e modelo de plugin-como-produto. O próprio bot é a superfície de deploy, distribuição e cobrança de apps de operação alimentados por IA.

DuraçãoInternal product, ongoing since 2024
Categoriaplatform
TecnologiasTypeScript · grammY · BullMQ + Redis · PostgreSQL · pnpm workspaces · Turborepo · Docker Compose · GitHub Actions self-hosted runners

Resultados

41
Plugins independentes em produção
905+
Testes automatizados no core do bot
Multi-tenant
Cofre de credencial por usuário, sem chaves compartilhadas

O problema

O operador moderno aumentado por IA precisa de cerca de 30 ferramentinhas — agenda, tarefas, monitoramento, deploy automation, geração de conteúdo, geração de imagem, code review com IA. Comprar 30 SaaS é desperdício, construir 30 dashboards é exaustivo, e cada ferramenta quer o próprio login.

A pergunta interessante: um único bot Telegram pode ser a superfície unificada para tudo isso, com isolamento de tenant, empacotamento de plugin e caminho real de cobrança?

A abordagem

Um monorepo com runtime fino e 41 plugins independentes:

Plugin SDK (`@tyber/plugin-sdk`) — define `TyberPlugin`, `PluginContext` e contrato de dependency injection. Cada plugin é um pacote npm, dentro ou fora do monorepo.

Thin wrappers do bot — o app do bot tem módulos de 1 arquivo que importam um plugin e o registram no composer do grammY. Zero lógica de negócio no core do bot.

Cofre de credencial por usuário — todo plugin que fala com API externa (Jira, GitHub, ClickUp, Spotify, Cloudflare, etc.) lê credenciais de um cofre criptografado por usuário, nunca de env vars globais. Novos usuários passam por wizard `/setup`.

Fila BullMQ para jobs que podem levar minutos (rodadas de Claude CLI, automação de browser). O bot se mantém responsivo; o worker mastiga jobs com retry e DLQ.

Análise estática como gate de CI — `gate-app-coverage.test` força que todo command de plugin passe pelo gate SaaS, todo callback siga o padrão de navegação, e nenhum `// Legacy` callback exista sem data de remoção.

Caminho de plugin externo — plugins podem viver em repo próprio no GitHub, depender do `@tyber/plugin-sdk` via GitHub Packages e ser instalados da app store da Tyber.io. Plugins são produtos.

O resultado

41 plugins em produção, 905+ testes automatizados no core do bot, ~3.800 testes no monorepo inteiro. CI completa em ~35 segundos para mudanças incrementais graças ao cache do Turbo. Multi-tenant desde o dia um, sem chaves compartilhadas, sem vazamento entre tenants.

O bot é a superfície de GTM: cada plugin pode ser vendido standalone, em bundle, ou de graça. O problema de deploy, cobrança e distribuição é resolvido pelo próprio Telegram.

Por que isso importa

A maioria das "plataformas de agente IA" é demo-ware que desmorona quando alguém pede garantias de produção. Esta foi construída production-first: testes, filas, isolamento de tenant, graceful shutdown, deploy guards, observabilidade. A arquitetura de plugin faz uma feature subir em horas, não semanas. O custo de um app novo é um arquivo de plugin mais um thin wrapper, não uma nova empresa SaaS.

Um engajamento parecido para o seu time?

Todo engajamento da Tyber.io começa pela mesma pergunta: qual problema dói mais e qual é o mais resolvível. Fale direto com o technical lead — sem funil de SDR, sem repasse pra júnior.

Falar com o technical lead