Pular para o conteúdo

Cloud bursting para lojas em VPS

Sua loja não precisa cair no dia de mais venda

Quando o movimento dispara, o SwarmBurst aluga servidor extra por hora, segura o pico e desliga quando passa. Sua loja continua na VPS onde já está.

Você conta como é sua loja hoje. A gente responde se encaixa ou não.

Seu servidor no dia de campanha

Capacidade fixa + reforço temporário
o que sua VPS aguentadaqui pra cima a loja engasgadaqui pra cima é reforço alugado
dia comumdia da campanhadia comum
Ilustração do mecanismo, não medição de cliente. O SwarmBurst ainda não passou pelo pico de uma loja de verdade, então não há número real para mostrar aqui.
Sua loja fica na VPS
Reforço cobrado por hora
Teto de gasto definido por você

As duas saídas de sempre custam caro

Falta uma terceira saída: capacidade extra só nas horas em que ela faz falta.

Contratar um servidor maior

Resolve o dia de pico e cobra por ele o ano inteiro. Nos outros 28 dias do mês a máquina fica sobrando, com a fatura igual.

Deixar como está

Funciona bem em 28 dias. No 29º a loja engasga, o carrinho trava e o cliente fecha a aba, logo depois de você ter pago anúncio pra trazer ele até ali.

Como funciona

Três passos. Nenhum deles mexe no seu site.

  1. 1

    O agente entra na sua VPS

    Uma instalação, feita junto com você. Sua loja não muda de endereço, de provedor nem de painel. Você diz até quanto pode gastar por mês e a partir de que ponto o reforço deve entrar.

  2. 2

    Ele fica de olho no movimento

    Em dia comum não acontece nada e não custa nada a mais. O agente só age quando o esforço do seu servidor passa do ponto que você marcou.

  3. 3

    No pico, sobe reforço por hora

    Servidores extras nascem na AWS e atendem junto com o seu. Quando o movimento cai, o agente esvazia cada um com calma e desliga. A cobrança termina aí.

Antes que você pergunte

O SwarmBurst é um programa instalado no servidor onde sua loja já roda. Ele acompanha o movimento e, quando o acesso dispara na Black Friday, na campanha ou no cupom que viralizou, aluga máquinas extras na nuvem da Amazon, por hora, para atenderem junto com o seu servidor. Passado o pico, ele desliga tudo sozinho e a cobrança para. Você define um teto de gasto e ele respeita esse teto.

Sua hospedagem continua a mesma
A loja fica na VPS que você já paga. Mesmo provedor, mesmo painel, mesma fatura.
Nada muda de lugar
Banco de dados, arquivos e painel não saem da VPS. Para a nuvem vai só capacidade temporária.
Não vira projeto de infraestrutura
Sem Kubernetes, sem curso, sem semana de migração. Vinte minutos de conversa bastam para saber se encaixa.
A conta da nuvem é sua e é por hora
Os servidores extras são cobrados pela própria AWS, na sua conta, e só enquanto estão ligados.

Isso encaixa na sua loja?

Melhor descobrir agora do que depois de uma reunião.

Encaixa se

  • A loja roda em VPS e o aperto aparece quando entra muita gente de uma vez.
  • Ela já roda em contêiner, ou seu dev topa colocar.
  • Você tem, ou pode abrir, uma conta na AWS.
  • Os picos dão para reconhecer: campanha, data sazonal, Black Friday, vídeo que viralizou.

Não encaixa se

  • O site é lento todo santo dia, no mesmo ritmo. Aí o problema não é pico, e reforço não conserta.
  • O aperto está no banco de dados. Subir mais aplicação não alivia banco.
  • A loja está em hospedagem compartilhada, sem servidor próprio.

O que você paga

Um mês tem 720 horas. Você paga as poucas em que a loja lota.

Um mês de operaçãoReforço ligado só no pico
As horas acesas são as que entram na conta. Ilustração, não medição.

Compare uma VPS maior com reforço temporário e veja onde o SwarmBurst pode entrar.

Comparar os custos do meu pico
  • Se por falha nossa o gasto passar do teto combinado, a diferença é nossa.
  • Se o reforço falhar, a loja continua no ar como está hoje. Ele é capacidade a mais, não peça necessária.
  • Desinstala com um comando, quando você quiser, e nada fica para trás.
A implantação da primeira loja é grátis
Em troca dos números reais do primeiro pico. Da segunda em diante, passa a ser cobrada.
As horas extras são cobradas pela AWS
Direto na sua conta, sem intermediário. Você confere a fatura com ela.
O teto do mês é você que define
Ao chegar no teto, o agente para de subir máquina nova. Antes disso, avisa por e-mail e no painel.

Um piloto por vez

Piloto do primeiro pico

Uma troca honesta: você ganha a implantação, nós ganhamos o primeiro pico real medido.

Falar no WhatsApp

O código já sobe e desliga servidor de verdade na AWS. O que falta é atravessar o pico de uma loja real, e esse primeiro caso vale mais para nós do que o dinheiro da implantação. Por isso a troca é essa.

Você recebe

  • Implantação e configuração feitas com você, sem cobrança.
  • Diagnóstico honesto: se o seu caso não encaixa, a gente diz em vez de vender.
  • Configuração do teto de gasto e dos gatilhos junto com você.
  • A gente acompanha o primeiro pico ao vivo, olhando junto.
  • Desinstalação em um comando, quando você quiser.

Em troca, pedimos

  • Autorização para medir e publicar os números reais do pico.
  • Um depoimento no fim, só se a experiência tiver sido boa.
  • Que a loja rode em contêiner. Seu dev confirma em um minuto.
  • Uma conta na AWS sua, onde os servidores extras vão nascer.

Fazemos um piloto por vez, porque acompanhamos o primeiro pico de perto. Se já tiver um em andamento quando você chamar, a gente fala isso na hora.

Para quem cuida do servidor

A parte que o dev ou a agência vai querer ler antes de dizer sim.

  • Agente no nó gerente de um cluster Docker Swarm. Sem Kubernetes e sem control plane novo.
  • Nós de reforço entram por túnel WireGuard. O estado fica preso no nó fixo por constraint de placement.
  • Scale-in drena o nó e espera a migração das réplicas antes de terminar a instância.
  • Gatilhos de CPU e memória, com cooldown e teto de orçamento configuráveis.
  • EC2 na conta do cliente, região configurável, sa-east-1 incluída. Estimativa de custo por região, histórico de eventos de burst e varredura de instância órfã.
  • Se o provisionamento falhar, o cluster segue com os nós fixos. O reforço é capacidade a mais, não dependência.

Ainda não existe: Reforço em Google Cloud e Azure, e alerta por WhatsApp. Está no roteiro, não no produto, e por isso não entra na conta do que você contrata hoje.

Perguntas frequentes

Quer entender se encaixa no seu caso?

Falar no WhatsApp
O que é cloud bursting?

Cloud bursting é usar servidor de nuvem só nas horas de pico. Sua aplicação roda normalmente nos servidores que você já tem e, quando o movimento sobe além da conta, servidores extras são alugados na nuvem por hora para dar conta do excesso. Quando o movimento cai, esses servidores extras são desligados e você para de pagar por eles. O SwarmBurst faz isso automaticamente no cluster de contêineres onde sua loja roda.

Preciso migrar meu site?

Não. Sua loja continua na VPS onde já está. O banco de dados, os arquivos enviados e o painel continuam lá, e nada permanente é movido para a nuvem. O SwarmBurst só acrescenta servidores temporários durante o pico, e eles são desligados depois. O que muda na sua VPS é a instalação do agente. Se quiser sair, a desinstalação é um comando e a loja volta exatamente ao estado de hoje.

E se a AWS cobrar demais?

Você define um teto de gasto mensal e o agente respeita esse teto: ao alcançá-lo, ele para de subir máquina nova. Antes disso, você recebe alertas por e-mail e no painel. A cobrança das horas extras é feita pela própria AWS, na sua conta, então você confere a fatura direto com ela, sem intermediário. Para não ficar máquina ligada esquecida, o agente encerra cada servidor extra depois de esvaziá-lo, e uma varredura procura instâncias que tenham sobrado. No piloto vale a garantia de teto: se por falha nossa o gasto passar do teto combinado, pagamos a diferença.

Funciona com WooCommerce ou Magento?

Funciona desde que a loja rode em contêineres, num cluster compatível. O SwarmBurst escala o serviço da aplicação; o banco de dados e os arquivos enviados ficam fixos na VPS. Se a sua loja WooCommerce ou Magento hoje roda direto na VPS sem Docker, existe um passo anterior de colocá-la em contêiner. Esse passo entra no diagnóstico do piloto, com a conclusão dita na hora. Não vendemos migração de servidor.

Preciso de conta na AWS?

Sim. Os servidores extras nascem na sua própria conta da AWS, e a cobrança é direta com ela. Você cadastra as credenciais no painel do SwarmBurst, onde ficam guardadas cifradas. A região é configurável, incluindo São Paulo (sa-east-1).

E se a nuvem falhar no meio do pico?

Sua loja não depende da nuvem para funcionar. Ela roda na VPS, que continua sendo o servidor principal e guarda todo o estado. Os servidores da nuvem são capacidade adicional: se a AWS falhar ou o agente não conseguir subir máquina, a loja segue no ar com a capacidade da VPS, como está hoje.

Vocês já têm clientes usando?

Ainda não. O SwarmBurst já provisiona e desliga instância real na AWS em teste validado, mas ainda não passou por um pico real de uma loja de verdade. É exatamente por isso que a implantação da primeira loja é gratuita: queremos o primeiro pico real medido, e você entra sabendo disso. Não temos depoimento nem número de cliente para mostrar, e não vamos inventar nenhum.

Seu próximo pico já tem data. Seu servidor ainda não tem plano.

Chame no WhatsApp e conte como é sua loja hoje. Se o SwarmBurst não resolver o seu caso, a gente diz isso na hora. Sai mais barato para os dois.

Falar no WhatsAppVocê conta como é sua loja hoje. A gente responde se encaixa ou não.