A StackZap pode ser usada em uma instalação própria ou pelo serviço gerenciado StackZap Cloud. Em ambos os casos, o modelo de conexão é independente da plataforma oficial da Meta; veja as diferenças entre API oficial e não oficial. Aqui, o foco é quem assume a infraestrutura e o trabalho operacional.
Self-hosted
Você instala a versão disponível no Docker Hub e opera a infraestrutura da instalação.
StackZap Cloud
A StackLab administra a infraestrutura do serviço conforme os termos e as condições contratadas.
Quando escolher self-hosted
Considere a instalação própria quando sua equipe quer controlar o ambiente e dispõe de conhecimento e tempo para operar serviços, armazenamento, rede e recuperação. A versão gratuita está no Docker Hub, e os manuais da StackZap explicam os passos da instalação. Planeje atualização, backup e monitoramento antes de depender do número conectado em produção.
Quando escolher StackZap Cloud
O Cloud faz sentido quando você quer usar a API sem montar e manter a infraestrutura do serviço. A StackLab administra o ambiente; você ainda configura suas instâncias, aplicação, destinatários e integrações. Cada cliente tem um serviço StackZap e um banco PostgreSQL separados, com sua própria URL; isso não significa servidor físico exclusivo.
Compare custo total e responsabilidade
Self-hosted não significa custo operacional zero: considere servidor, observabilidade, backups, segurança, atualizações e tempo de equipe. No Cloud, compare assinatura, limites de instâncias e cotas com o trabalho que deixa de ser feito internamente. Confira os detalhes atuais em stackzap.com.br/#planos e os requisitos de instalação em docs.stacklab.digital/manuais.
Compare a responsabilidade operacional
Na instalação própria, sua equipe escolhe e opera a infraestrutura. No Cloud, a StackLab administra a infraestrutura; sua equipe continua responsável pela aplicação, pelas integrações e pelo uso do número. Consulte os Termos de uso para confirmar o escopo contratado, inclusive condições de backup e recuperação.
Quem cuida de cada parte
| Responsabilidade | Self-hosted | StackZap Cloud |
|---|---|---|
| Infraestrutura | Sua equipe provisiona e opera. | Gerenciada pela StackLab; serviço de API e banco são separados por cliente. |
| Aplicação e integrações | Sua equipe configura e opera. | Sua equipe configura instâncias, credenciais e integrações. |
| Backups e recuperação | Sua equipe define, testa e mantém o processo. | Confirme as condições aplicáveis nos Termos e na contratação. |
Confira os limites e detalhes vigentes na página de planos e os requisitos de self-hosted nos manuais.
Compare pelo perfil da equipe
Self-hosted pode fazer sentido para desenvolvedores e integradores que querem assumir responsabilidade técnica e têm processo para manter serviços em produção. É também uma forma de experimentar a edição gratuita e aprender a API. Antes de colocar um número importante, verifique se há capacidade para monitorar e responder a incidentes fora do horário comercial.
Cloud pode ser conveniente para quem quer começar a integrar sem montar servidor. É útil para desenvolvedores e negócios que preferem infraestrutura gerenciada para automações e atendimento; as responsabilidades da aplicação e do número continuam com sua equipe.
Compare isolamento e credenciais
Cada cliente Cloud tem serviço de API, banco PostgreSQL e URL separados; o ambiente não é um servidor físico exclusivo. Na instalação própria, o isolamento depende de como o operador configura os serviços. Planeje permissões e nomes para evitar que uma integração acesse dados de outro projeto.
Em ambos os formatos, proteja API Keys, callbacks e informações dos contatos. Self-hosting não significa segurança automática, assim como Cloud não substitui controles da aplicação. Use autenticação no backend, valide webhooks, limite acesso e mantenha logs redigidos.
Compare continuidade e manutenção
Em self-hosted, atualizações e backups dependem do processo implementado: janela de manutenção, cópia consistente, retenção e ensaio de restauração. Um arquivo que nunca foi restaurado não comprova que a recuperação funciona. Monitore capacidade e conectividade.
No Cloud, a StackLab administra a infraestrutura. Os Termos dizem que backup e recuperação específicos só fazem parte da contratação quando definidos expressamente; confirme retenção e procedimento antes de depender deles. Sua aplicação ainda precisa tratar timeout, reconexão, filas, webhooks e recuperação das próprias bases.
Compare custos e limites
Self-hosted gratuito remove a cobrança da licença da edição, mas não custos de servidor, armazenamento, tráfego, observabilidade, segurança e trabalho humano. Cloud troca parte desse esforço por assinatura e limites de plano. Compare quantas instâncias precisa, armazenamento, cotas, suporte e custo de operação interna. Confira preços vigentes na página comercial antes de decidir.
Projete um cenário de crescimento, não só o primeiro mês. Se a operação precisar de mais números ou arquivos, considere custo e processo de migração. Uma escolha inicial não precisa ser permanente; preserve configuração e documentação para reduzir dependência de conhecimento informal.
Self-hosted
Escolha quando controle do servidor é prioridade e existe capacidade para manter e recuperar o serviço.
StackZap Cloud
Escolha quando quer reduzir o trabalho de infraestrutura e prefere ambiente gerenciado com contratação e painel próprios.
Faça um piloto com caso de uso real e de baixo risco. Meça tempo de implantação, qualidade operacional, custo total, facilidade de atualização e experiência de integração. Inclua quem atenderá falhas, não apenas quem escreve o primeiro código.
Perguntas antes de escolher
- Quem monitora a conexão e responde quando ela cai?
- Quem atualiza a imagem e testa migração de dados?
- Como backups são verificados e restaurados?
- Quantas instâncias e qual volume a operação exige?
- Qual o custo de trabalho interno comparado com assinatura?
- Que requisitos de isolamento e rede são necessários?
- Quais detalhes de retenção e suporte precisam estar em contrato?
- Como o sistema será migrado se o volume crescer?
Checklist final
- Responsabilidades operacionais foram atribuídas.
- Requisitos e custos além da licença foram estimados.
- Cotas atuais foram verificadas na página de planos.
- Processo de backup, recuperação e atualização foi avaliado.
- Credenciais e dados estão protegidos nos dois modelos.
- Um piloto validou API, suporte e rotina de trabalho.
Caminho de migração entre opções
Uma equipe pode começar no self-hosted e depois migrar para Cloud, ou testar self-hosted após usar Cloud. Antes da mudança, inventarie IDs, configurações, integrações, credenciais, URLs de webhook e filas. Confirme se os dados e sessões podem ser migrados conforme as ferramentas disponíveis; não presuma que copiar banco ou volume seja compatível. Planeje janela de transição, novo pareamento se necessário e validação com mensagens de teste.
Mantenha ambas as pontas sem envio simultâneo ao mesmo destinatário durante a troca. Atualize configurações no backend e cancele jobs antigos ou roteie-os de forma explícita. Depois de validar o destino, desative o ambiente anterior pelo procedimento correto e remova credenciais antigas. Preserve evidências e dados segundo sua política.
Caso de uso: integração com time pequeno
Se uma pessoa desenvolvedora também é responsável por produto e atendimento, Cloud pode liberar tempo ao reduzir a manutenção do host. Self-hosted pode ser adequado se a equipe já opera containers e quer incorporar a API à própria plataforma. Compare o tempo semanal esperado, cobertura fora do expediente e custo de oportunidade, não apenas o valor mensal.
Caso de uso: integrador que atende clientes
Um integrador pode preferir ambientes separados para isolar projetos. Planeje o cadastro de cada cliente, gestão de acesso, URL e chave próprias e procedimento de suporte. No self-hosted, considere como segregar bancos e recursos e como fazer backup de cada instalação. No Cloud, confirme limites do plano e como administrar os ambientes pelo portal de contas.
Decisão reversível
Comece com um piloto controlado, mantenha API client modular e armazene configuração fora do código. Isso reduz acoplamento à URL e facilita alterar o destino depois. Documente endpoints usados, eventos, campos e versão da StackZap. Assim, a decisão pode ser revisada com dados de uso em vez de depender apenas de impressão inicial.