Estrelas, commits, datas, licença e árvore de arquivos foram lidos da API do GitHub hoje, autenticado com o seu token. Nada foi clonado e nada foi executado.
Os dois falam com a API oficial do Instagram. Nenhum dos dois scrapeia, automatiza navegador ou pede senha. Isso é a melhor notícia do levantamento e também o problema: os dois passam pelo mesmo App Review da Meta, que é trabalho de formulário e screencast, não de código. A escolha entre eles decide o que acontece depois que a Meta abre a porta. Ela não abre a porta mais cedo.
Comecei por aqui de propósito. Se você só ler esta seção, já dá pra conversar com quem for tocar isso.
Os dois projetos são construídos em cima do mesmo mecanismo oficial: a private reply do Instagram. Alguém comenta a palavra-chave no seu Reel, a Meta chama um webhook seu, e o sistema responde no Direct daquela pessoa por endpoint oficial.
Pra isso funcionar fora do modo de teste, a exigência é a mesma nos dois casos: app criado no portal da Meta, conta do Instagram no modo Business ou Creator, domínio seu, webhook registrado nesse domínio e App Review aprovado pra ganhar Advanced Access nos escopos de mensagem. Sem isso, a automação só responde a perfis cadastrados como usuários de teste do app.
App próprio na Meta, conta Business ou Creator, domínio, webhook e App Review. Janela de 24h pra responder livremente depois que a pessoa escreve. Private reply com janela própria de 7 dias e uma chamada só por comentário. Teto de 750 private replies por hora, por conta.
O que o sistema faz com o lead depois do primeiro DM, quanto de infra ele exige de pé, quem conserta quando quebrar, e sob qual licença o código está na sua mão.
Verificado As regras de janela, o teto de 750 por hora e a exigência de App Review estão escritas na documentação dos dois repositórios, que eu li hoje. O prazo do App Review em si eu não medi.
Números lidos da API do GitHub em 08/09/2026. O da direita é privado, e só abre logado como você.
Os 2 contribuidores da direita são o Renato Cardoso, autor de 18 commits, e você, com 2 commits em 15/08. Os seus não estão na main. Está detalhado mais abaixo.
Só as linhas que mudam decisão. O núcleo é idêntico nos dois, e é por isso que ele abre a tabela e sai do caminho.
Comparativo lido do código e dos metadados dos dois repositórios, em 08/09/2026.
| Item | OpenReply | manychat (cópia) |
|---|---|---|
| Núcleo | Comentário vira DM por API oficial | Igual, mesmo mecanismo |
| Fila de envio | BullMQ sobre Redis, com worker dedicado | Não existe na main. Só na sua branch parada |
| Sequência multi-passo | Follow-up com atraso configurável | Sequência que avança sozinha quando a pessoa responde |
| Gate de seguidor | Sim, e libera o link mesmo se a Meta não devolver o status | Sim |
| Multiconta | Várias contas, com workspaces e papéis de owner, admin e membro | Várias contas, com filtro por conta. Sem papéis nem convite |
| Banco | Postgres próprio, via Prisma, com migrations versionadas | Supabase compartilhado com outros sistemas, separado só por prefixo de tabela |
| Testes | 18 suítes automatizadas, incluindo webhook e limite de envio | Nenhuma |
| Documentação | Guia de setup longo, guia de App Review, política de segurança | README bom e 9 guias dentro do próprio painel, em português |
| Licença | MIT, uso comercial liberado por escrito | Nenhuma. Vale a autorização que o Renato te deu de viva voz |
| Quem sustenta | Diwen Huang com 99 commits, mais 17 pessoas de fora | Renato sozinho, e parado desde 23/07 |
| Infra pra rodar | Web na Vercel, mais Postgres, mais Redis, mais uma máquina pro worker | App na Vercel e Supabase. Só isso |
| Esforço pra subir | Maior, são dois processos que precisam ficar de pé | Menor, é um app Next só |
O resto é empate técnico. Estes quatro pontos existem de um lado e não existem do outro, então é aqui que a escolha significa alguma coisa.
Ele tem workspace com papéis de owner, admin e membro, e link de convite. Dá pra colocar um cliente ou um operador dentro de um espaço isolado sem entregar a conta inteira.
O da cópia é single-tenant na prática. Serve pra rodar as suas contas, não pra rodar a conta dos outros com separação de acesso.
Ele manda o link tudo na primeira mensagem, porque a private reply só aceita uma chamada por comentário. As mensagens seguintes só saem depois que a pessoa responde, porque é a resposta dela que abre a janela de 24h. O webhook detecta isso e avança a sequência sozinho.
Quem monta funil de conversa vai sentir a diferença. No OpenReply o equivalente é um follow-up com atraso, que é outra coisa.
Tem Dockerfile, docker-compose e guia de deploy em Dokploy. Cabe na nossa VPS sem depender de plataforma de terceiro.
A cópia é casada com Vercel mais Supabase. Tirar ela de lá é reescrever a camada de banco.
Interface, textos e os 9 guias internos estão em PT-BR, escritos pra quem opera aqui. O OpenReply é todo em inglês, e as contribuições recentes da comunidade foram justamente pra fazer palavra-chave funcionar em árabe, cirílico e com acento latino.
Se quem vai mexer no painel no dia a dia não for você, isso deixa de ser detalhe.
Achei isso procurando outra coisa. Vale mais que metade da tabela acima.
Em 15/08 você escreveu dois commits que consertam exatamente as duas fraquezas mais sérias da cópia. Eles ficaram numa branch chamada feat/fila-de-envio que nunca foi mergeada.
2 commits à frente da main, 0 atrás, 33 arquivos tocados. Não há conflito impedindo o merge.
Quem clonar a main pega uma versão sem controle de teto por hora, sem nova tentativa em caso de falha, e com o token do Instagram guardado sem cifra no banco.
Suposição Não sei se a branch ficou fora da main por decisão sua ou por esquecimento. Só li que ela está lá, pronta e sem conflito.
Sem poupar nenhum dos dois. É o que eu quereria saber antes de assinar embaixo.
Nenhum dos dois usa API não oficial, nenhum automatiza navegador e nenhum pede senha do Instagram. O que derruba conta em automação de DM é justamente o caminho que os dois recusaram.
Não estou escolhendo. Estou dizendo onde o peso cai, pra você decidir com o cenário que só você conhece.
Nenhum desses cenários vale mais que o outro sem você dizer qual é o de verdade. E nenhum deles muda o prazo do App Review, que é o mesmo nos dois.
O buraco principal tem solução simples, e ela não está do nosso lado.
Não apurei
O original renatodpaula/manychat é privado. Testei com o seu próprio token do GitHub e ele devolve 404, ou seja você não é colaborador lá. Sem enxergar o original, não tenho como dizer se a cópia está atrasada nem quantos commits atrás ela está.
A conta do Renato existe e está ativa: github.com/renatodpaula, com 12 repositórios públicos, incluindo as skills project-maker e humantext que já rodam aqui em casa. O repositório manychat simplesmente não é um deles.
Isso só se resolve de um jeito: pedir a ele acesso de leitura ao repositório. Com isso eu comparo os dois históricos em minutos e te digo o número exato.
/opt, /home/mari e /root, por nome de pasta e por endereço de origem no git. Não existe cópia local de nenhum dos dois.Tudo lido em 08/09/2026 pela API do GitHub, autenticado com o token que estava no servidor. Só leitura, nada criado nem alterado.
O OpenReply tem uma issue aberta chamada Upgrade to payable model, que à primeira vista parece o dono anunciando que vai cobrar. Abri e li: é pedido de um usuário por mais tipos de campanha. Não há sinal de fechamento do código. Deixo registrado porque eu quase repassei o título sem abrir.