Revisado em 12/11/2026. A data de publicação original foi preservada.
O SwarmBurst é um agente instalado na infraestrutura do cliente para adicionar capacidade AWS a um cluster Docker Swarm durante picos e retirar os nós temporários depois. O ponto de partida é uma aplicação que funciona na VPS no dia a dia, mas precisa de mais capacidade em períodos específicos. O atendimento começa por uma avaliação técnica pelo WhatsApp; não há cadastro self-service ou conta gratuita em um painel público.
Se a lentidão vem de uma consulta sem índice, de um plugin ou de uma API de pagamento, adicionar máquinas pode não resolver. A proposta depende de descobrir primeiro qual recurso limita a aplicação.
Qual problema queremos atender
Uma campanha pode levar a uma escolha de infraestrutura: aumentar a VPS o mês inteiro, ajustar a aplicação, preparar mais capacidade fixa ou contratar recursos temporários. A escolha depende da duração do pico, da arquitetura e do custo de operar cada alternativa.
O SwarmBurst atende o recorte em que a aplicação pode ganhar réplicas em outros nós e o pico exige mais capacidade computacional. Um nó é uma máquina do cluster; uma réplica é outra instância do serviço da aplicação. Criar uma réplica na mesma VPS não cria CPU ou memória adicional.
Veja como distinguir réplicas de capacidade de máquina e como medir o limite com um teste de carga.
Como funciona a arquitetura
No cenário de implantação atual, a VPS permanece como manager do Docker Swarm e mantém os componentes permanentes. Nós EC2 temporários entram como workers por uma rede WireGuard, que conecta as máquinas por túnel. O serviço escolhido pode ganhar réplicas conforme a capacidade adicionada.
| Componente | O que avaliar |
|---|---|
| VPS fixa | Mantém a operação base e os componentes permanentes; continua sendo uma dependência da arquitetura. |
| Aplicação replicável | Precisa atender em outros nós sem depender de sessão ou arquivo exclusivo do disco local. |
| Banco e arquivos | Precisam continuar acessíveis, consistentes e dimensionados para a nova carga. |
| Nós AWS temporários | Acrescentam capacidade computacional; precisam receber tráfego e alcançar as dependências. |
| Redução de capacidade | Precisa concluir requisições, retirar os nós e conferir os recursos remanescentes. |
O Docker Swarm não redistribui automaticamente todas as tarefas existentes só porque uma máquina nova entrou. A expansão precisa coordenar os nós e o serviço da aplicação. Esse comportamento é descrito na documentação de administração do Swarm.
Pré-requisitos antes de considerar o piloto
- Acesso técnico à VPS e uma janela para mudanças, com backup restaurável.
- Aplicação em Docker Swarm ou avaliação do trabalho necessário para chegar a essa arquitetura.
- Imagem da aplicação acessível aos nós e configuração adequada de rede e permissões.
- Banco, uploads e sessões preparados para múltiplas réplicas.
- Conta AWS do cliente, região e permissões definidas para a implantação.
- Critérios de desempenho e custo acordados antes de gerar carga.
Uma instalação comum de WooCommerce diretamente na VPS não se torna compatível só pela instalação do agente. É preciso examinar a aplicação e suas dependências. Veja o que muda ao colocar uma loja em containers e por que estado local precisa ser tratado.
Limites de custo ajudam a controlar a operação
O agente dispõe de controles de orçamento e quantidade de nós. Eles orientam suas decisões de expansão e encerramento, mas não são uma garantia de teto absoluto da fatura AWS. Outros recursos, tráfego, armazenamento, impostos e compromissos da conta podem continuar sendo cobrados.
A própria AWS distingue cobrança da instância e de recursos associados, como volumes, no ciclo de vida da EC2. O diagnóstico deve comparar o custo completo, incluindo implantação e operação, e não apenas o preço horário de uma máquina.
O estágio atual do produto
O SwarmBurst está em fase de validação com implantação assistida. Não apresentamos economia medida de clientes, depoimentos ou percentual universal de ganho. O piloto deve produzir evidência do ambiente avaliado, sem transformar uma simulação em resultado comercial.
A implantação tratada aqui utiliza AWS. GCP e Azure não são provedores operacionais oferecidos neste fluxo; eventual evolução precisa ser apresentada como roadmap.
Como avaliar se faz sentido para sua aplicação
Antes da conversa, reúna o tamanho da VPS, a arquitetura, o sintoma observado, o horário dos picos e os gráficos ou logs disponíveis. Não envie senhas, chaves AWS ou dados de clientes pelo contato inicial.
A avaliação deve responder: qual serviço precisa crescer, qual dependência pode limitar a expansão, quanto tempo a capacidade leva para ficar útil e como retornar à operação base. O artigo sobre implantação de cloud bursting no Docker Swarm organiza esse checklist.
