Cloud para Software House: Como Escolher a Infraestrutura Certa

Se você tem uma software house ou agência de desenvolvimento, sabe que infraestrutura é aquela coisa que ninguém nota quando funciona e todo mundo nota quando falha. O cliente não quer saber se o servidor tá com pico de CPU. Ele quer saber por que o sistema dele tá lento.

E se você é como a maioria das software houses brasileiras, provavelmente já passou por isso: fatura em dólar que explodiu por causa do câmbio, suporte da AWS em inglês que não resolve nada rápido, aquele deploy que derrubou o servidor de outro cliente porque tava tudo no mesmo lugar. Soa familiar?

Esse artigo é pra você que precisa de cloud pra rodar projetos de clientes e quer parar de sofrer com infraestrutura.

As necessidades específicas de uma software house

Software house não é uma empresa normal quando se trata de cloud. Você tem demandas que uma empresa que usa só um ERP não tem:

Múltiplos clientes, múltiplos ambientes

Cada cliente é um projeto diferente. Cada projeto tem no mínimo dois ambientes: staging e produção. Alguns têm dev, staging, homologação e produção. Multiplica por 10 clientes e você tem 30-40 ambientes pra gerenciar.

Stacks diferentes

Um cliente roda em Node.js, outro em PHP/Laravel, outro em Python/Django, outro em .NET. Cada um com sua versão de banco, suas dependências, suas manias. Padronizar é sonho — na prática, você gerencia um zoológico de tecnologias.

Deploy constante

Toda semana tem deploy. Às vezes todo dia. O processo precisa ser rápido, seguro e não pode afetar outros clientes. Se o deploy do cliente A derruba o ambiente do cliente B, você tem dois problemas ao invés de zero.

Previsibilidade de custo

Você cobrou R$ 500/mês de hospedagem do cliente. Se a infra custa US$ 100 e o dólar sobe 20%, seu lucro evaporou. Software house precisa de custo previsível pra poder precificar com segurança.

Os problemas mais comuns de infra em software houses

Fatura em dólar que come a margem

Você fechou o contrato com o cliente em Real. Sua infra é em dólar. O câmbio variou e sua margem encolheu. Pra reajustar o cliente, precisa de negociação, justificativa, desgaste. Enquanto isso, o custo já subiu.

Suporte em inglês quando o servidor cai às 3h

Servidor do cliente caiu. Você precisa de ajuda do provedor. Abre ticket em inglês, espera 6 horas por resposta, recebe uma mensagem genérica pedindo mais detalhes. Enquanto isso, o cliente te liga perguntando por que o sistema dele tá fora do ar.

Sem isolamento entre clientes

Pra economizar, você botou 5 clientes no mesmo servidor. O cliente A fez upload de um arquivo de 2GB, encheu o disco. O site do cliente B saiu do ar. Todo mundo sofre junto.

Processo de provisioning lento

Fechou contrato com cliente novo. Precisa de servidor. Cria a conta, configura VPC, Security Groups, IAM roles, instala SO, configura firewall... 2 dias depois o servidor tá pronto. 2 dias que você poderia estar desenvolvendo.

O que procurar num provedor de cloud pra software house

Nem todo provedor serve pra quem gerencia múltiplos projetos. Aqui tá o que importa de verdade:

• API completa: você precisa automatizar. Criar servidor, configurar DNS, gerenciar firewall — tudo via API. Se precisa clicar em 47 botões num painel pra subir um servidor, não serve
• Painel em português: parece bobagem? Não é. Quando você delega tarefas pra um estagiário ou junior, um painel em português reduz erros. Muito
• Provisioning rápido: servidor novo em minutos, não em horas ou dias. O ideal é ter máquina rodando em menos de 2 minutos
• Root access: você precisa de controle total. Instalar o que quiser, configurar como quiser. Sem restrição
• Preço em Real: pra poder precificar pro cliente com segurança, sem risco cambial
• Suporte que fala português: e que responde rápido. Em horário comercial brasileiro, no mínimo

Como estruturar ambientes de clientes

Existem duas abordagens principais:

Um servidor por cliente

Cada cliente tem seu próprio servidor virtual. Isolamento total: se um cliente tiver pico de uso, não afeta os outros. Mais seguro, mais previsível, mas mais caro.

Quando usar: clientes que pagam bem, aplicações com requisitos específicos, clientes que exigem isolamento contratual.

Infraestrutura compartilhada com isolamento lógico

Um servidor mais robusto rodando Docker, com containers separados por cliente. Cada cliente tem seu container, seu banco, seu domínio — mas compartilham a mesma máquina física.

Quando usar: sites institucionais, landing pages, aplicações leves, clientes com orçamento menor.

Stack prática: Docker + Portainer + Traefik

Se você gerencia múltiplos projetos e ainda não usa essa stack, tá perdendo tempo. Aqui vai o setup que a maioria das software houses brasileiras que a gente atende usa:

Docker

Cada projeto roda num container isolado. Se o projeto do cliente A quebrar, o container do cliente B nem percebe. Você define a stack do projeto no docker-compose.yml e tem reprodutibilidade garantida.

Portainer

Interface web pra gerenciar Docker. Em vez de ficar no terminal toda hora, você vê status dos containers, logs, consumo de recursos — tudo pelo browser. Seu time junior consegue gerenciar sem precisar decorar comandos Docker.

Traefik

Reverse proxy e load balancer automático. O Traefik detecta novos containers, configura o roteamento por domínio e gera certificado SSL via Let's Encrypt automaticamente. Você sobe um container novo com a label certa e em 30 segundos ele tá acessível pelo domínio do cliente, com HTTPS.

Essa combinação roda tranquilamente num VPS com 4 vCPUs e 8GB de RAM, servindo 10-15 projetos de pequeno/médio porte. Custo na Audaks? Uma fração do que você pagaria em AWS.

Otimizando custos: right-sizing e evitando desperdício

O erro mais caro em cloud é over-provisioning: pagar por recursos que você não usa. Dicas práticas:

• Monitore o uso real: a maioria dos servidores usa menos de 30% da CPU e RAM contratadas. Se seu servidor de 8GB nunca passa de 3GB de uso, você tá pagando por 5GB que não precisa
• Comece pequeno, escale depois: é muito mais fácil aumentar um servidor na nuvem do que diminuir. Comece com o mínimo e suba conforme a demanda real
• Ambientes de staging menores: staging não precisa ter a mesma capacidade de produção. Use máquinas menores pra ambientes que não recebem tráfego real
• Desligue o que não usa: ambiente de demonstração que só roda quando tem reunião com cliente? Desligue no resto do tempo. Na Audaks, você pode ligar e desligar pelo painel

Como a Audaks atende software houses

A gente conhece a rotina porque muitos dos nossos clientes são software houses. O que oferecemos especificamente pra esse perfil:

• Marketplace com 1-click deploy: Docker, Portainer, Traefik, bancos de dados — tudo instalável com um clique. Seu servidor novo sai pronto pra receber projetos
• API completa: provisione servidores, gerencie DNS, configure firewall — tudo via API REST. Integre com seu pipeline de CI/CD
• Preço em Real: precifique pro seu cliente com segurança. Sem IOF, sem câmbio, sem surpresa
• Suporte em português: quando precisar, a gente responde rápido e no seu idioma
• Kubernetes gerenciado: pra quando Docker Compose não dá mais conta e você precisa de orquestração de verdade

Perguntas frequentes pra software houses

Quantos clientes posso rodar num servidor?

Depende do tipo de projeto. Sites institucionais e landing pages: 15-20 tranquilamente num VPS com 4GB de RAM. Aplicações web com banco de dados: 5-8 num servidor com 8GB. Aplicações pesadas (SaaS, e-commerce com muito tráfego): 1-2 por servidor, ou parta pra Kubernetes.

VPS ou Kubernetes para múltiplos projetos?

Se você tem até 20 projetos e uma equipe pequena, VPS com Docker + Portainer + Traefik é a escolha certa. Simples, barato e funcional. Kubernetes faz sentido quando você tem dezenas de projetos, precisa de auto-scaling, tem equipe com conhecimento de K8s e está disposto a investir em complexidade operacional em troca de flexibilidade. Não use Kubernetes só porque é hype.

Como cobrar infraestrutura do meu cliente?

Existem dois modelos comuns: incluir no valor do contrato mensal (mais simples, cliente nem sabe que tá pagando infra separado) ou cobrar à parte com markup (transparente, mas precisa justificar o valor). A maioria das software houses opta pelo primeiro modelo — embute o custo de infra no valor do serviço mensal de manutenção.

Próximo passo

Se você tem uma software house e tá insatisfeito com sua infra atual — seja pelo custo em dólar, suporte em inglês ou complexidade desnecessária — dá uma olhada no que a Audaks oferece. Confira as tabelas de preço, teste um VPS por alguns dias e veja se faz sentido pro seu negócio.

Se quiser conversar sobre como estruturar a infra pra seus clientes, chama a gente. A conversa é sem compromisso e a gente entende a sua dor porque já viveu ela.