Não é birra com ferramenta. É superfície de ataque — e a sua é bem maior do que você imagina no dia em que alguém atira no vizinho.
Resposta rápida: eu não uso esses serviços em produção por três motivos, nessa ordem. Custo — eu tenho ambiente on-premises e ele tem um custo que eu controlo. Segurança — eu já fui invadido, já criptografaram o banco de dados de um sistema nosso e já me pediram resgate; gato escaldado tem medo de água fria. E o principal: superfície de ataque. Quando você entra num ambiente compartilhado gigante, o alvo deixa de ser o seu sistema e passa a ser a plataforma inteira — e você está dentro dela. Se atacarem o vizinho, você cai junto, sem ter feito nada errado. Essas ferramentas são excelentes pra aprender, prototipar e testar MVP. Só não são pra sustentar o sistema que paga a sua conta.
13 minutos, sem edição — do canal @josimarjmv, publicado em 27/08/2026. Se preferir ler, está tudo abaixo.
Eu comecei o vídeo com uma bolinha na mão e uma pergunta boba: o que é mais fácil de acertar — a bolinha ou a parede atrás de mim? Pois é. A superfície que você oferece pra ser acertado muda tudo. E é exatamente essa a conversa quando o assunto é ambiente de produção.
Eu sou CEO de uma empresa de tecnologia de verdade — a mesma desde 2003 —, coordeno equipes de desenvolvimento, suporte e vendas, e boto a mão na massa em infraestrutura que serve milhões de views por dia, pra cliente grande, médio e pequeno. Falo daqui, não de tese. E um dos motivos de eu ter feito o canal é que tem gente demais arrotando conselho sobre montar empresa sem nunca ter tido uma.
Superfície de ataque é o tamanho do alvo. Uma bolinha é difícil de acertar; uma parede, não. Quando você coloca a sua produção dentro de um serviço usado por milhões de projetos, você não é mais uma bolinha: você é um pedacinho de uma parede enorme — e quem atira nem precisa estar mirando em você.
Se o Supabase cair, cai você e uma galera junto. Se alguém atacar o Supabase pra catar dados, o vazamento leva os seus dados junto. Se atacarem o Google, a Microsoft ou qualquer sistema gigante que muita gente usa, você vai de tabela. É o fumante passivo: você não fuma, mas está do lado de quem fuma — e o pulmão que vai embora é o seu.
O caso mais didático dos últimos tempos é o do GitHub Actions. Uma ação de terceiros muito usada, a tj-actions/changed-files, foi comprometida: o atacante reescreveu as tags de versão pra apontarem pra um commit malicioso, e o código passou a despejar segredos da memória do runner dentro do log público do workflow. A CISA emitiu alerta sobre o comprometimento e o caso virou o CVE-2025-30066 no próprio banco de avisos do GitHub: chaves de acesso, tokens pessoais, tokens de npm e chaves privadas expostas em milhares de repositórios.
Repare no que aconteceu ali. Ninguém invadiu a sua empresa. Ninguém mirou em você. Você só estava usando uma peça que todo mundo usa, dentro de um ambiente que todo mundo usa — e o tiro pegou. É disso que eu estou falando quando digo que a superfície não é sua, mas a conta é. Tem jeito certo de usar essas ferramentas, convenhamos; só que "jeito certo" vira responsabilidade sua de vigiar um ambiente que não é seu.
"Ah, Josimar, que absurdo, em que época você vive, você é contra a nuvem." Sou, e tenho a minha. Nuvem pra testar MVP e tocar coisa pequena está ótimo — é pra isso que serve. O problema é o que a gente faz com produção.
Aqui no Brasil a conta é simples: a nuvem falha. A Amazon fica fora. A Cloudflare fica fora. Serviço gerenciado vaza e cai. E o GitHub caiu de novo esses dias, sem nem ter sido ataque — foi problema interno mesmo. Lembra da lei de Murphy? Tudo que tiver que dar errado vai dar errado. Quando a gente trabalha com infraestrutura de verdade, a mentalidade muda: você aprende a ter medo e passa a saber que as coisas vão cair.
Você subiu na Amazon. Um dia a Amazon vai cair. Pode demorar, ela é mais confiável, tudo bem — mas vai cair. O que você vai fazer quando o seu cliente sair do ar? Vai correr pra Azure? Pra Cloudflare? Vai fazer o quê, na hora, no susto? Já escrevi sobre o outro lado desse mesmo medo em medo de subir em produção: o medo saudável é o que vira processo.
Anota esse pensamento: vai cair. Bota na cabeça. A sua VM vai cair. E a hora de responder "o que eu faço agora" é antes, não durante. Isso tem nome: plano de contingência. É obrigatório fazer o papel de advogado do diabo e questionar tudo.
O backend caiu. O que assume? Em quanto tempo? Quem é avisado?
O front caiu. O cliente vê o quê? Página de erro sua ou erro cru do provedor?
Caiu tudo. Qual é a ordem de subida? Alguém já ensaiou essa ordem?
O banco corrompeu. O que estava só em memória — o arquivo de append do Redis, do Valkey, o Kafka, o que você usar — sobreviveu?
Tem backup? Ótimo. Você já restaurou esse backup pra testar? Backup nunca restaurado não é backup, é esperança.
Backup, rollback e a resposta escrita pra cada peça que cai. Isso é o mínimo — e é o que separa quem tem um sistema de quem tem um sustinho hospedado.
Redundância de link todo mundo entende: se o seu link cair, você tem outro. Agora responde sincero, meu amigo vibe coder: você tem redundância de infraestrutura? Você tem duas VMs, em empresas diferentes, e se uma cair a outra assume?
Isso é o básico do básico pra colocar um software online e vender. Dois ambientes redundantes, um cai, o outro assume. Você está ganhando dinheiro com isso — não dá pra confiar o seu faturamento a uma VM só. Se cair, não é só o prejuízo do dia: queima o seu filme. E SaaS hoje é mato. O cara vai embora e tchau. Já detalhei essa conta inteira — do protótipo à operação — em o golpe do microSaaS de 2 dias.
E aqui vai a visão de CEO que raramente passa pela cabeça de quem só escreve código. Às vezes o cliente não vai embora mesmo tendo opção melhor e mais barata. Sabe por quê? Porque está funcionando redondo, não está dando problema.
A dor da migração não é o software do concorrente ser melhor que o seu: é treinar a equipe inteira de novo. Trocar sistema em supermercado é um caos. Um caos. O dono sabe disso. Se está funcionando direitinho, ele não mexe — pode ter software em COBOL rodando lá (e a galera do COBOL já me xingou uma vez por eu falar isso), e ele não vai mexer.
Vira a moeda e você tem a sua régua: o seu software tem que funcionar redondo, sem dar problema. Porque se o cliente for obrigado a migrar por instabilidade sua, ele nunca mais volta. E como se mantém um sistema funcionando redondo? Não tendo uma superfície gigante de ataque que você não controla.
Pra não ficar só na crítica, o que eu faço hoje:
E tem um número que fecha o argumento. Só de link, uma das unidades tem 140 Gb. Pra um ataque começar a me afetar, tem que passar disso — e aí já é um ataque grande, não é moleque com script. Agora compara: se você tem uma VM numa hospedagem compartilhada, um ataquezinho de 10 Gb — que sai de um único servidor com placa de 10 Gb — arranca a sua VM do ar e tchau, sistema fora. Proteção contra negação de serviço é outra conversa, bem mais longa; o ponto aqui é anterior: tem que saber até onde você contrata VM.
Nenhuma dessas escolhas te dispensa do dever de casa. Ambiente próprio sem redundância e sem backup testado é tão frágil quanto o compartilhado — só que aí a culpa é toda sua.
Sobre a imersão de infraestrutura. Quem quiser entender esse assunto inteiro — superfície de ataque, ambiente on-premises, VM, virtualização, instalação, data center, DNS autoritativo e recursivo, comprar ou alugar infraestrutura e o momento certo de cada coisa — é isso que eu vou destrinchar em três dias presenciais em São Paulo. Não é transmitida ao vivo e não vai ter gravação: só está lá quem for selecionado, porque antes de abrir venda eu converso com cada pessoa pra entender o ramo de negócio dela e ver se a gente consegue gerar valor de verdade. No vídeo eu falo em algo entre R$ 15 mil e R$ 20 mil de investimento e uma turma inicial bem restrita, de umas 30 pessoas; data, valor e condição finais saem na página. Pré-inscrição em Imersão de Infraestrutura — as outras três estão em todas as imersões.
Baseado no vídeo do canal @josimarjmv publicado em 27/08/2026, com transcrição própria das legendas do próprio vídeo. O caso do GitHub Actions foi conferido nas fontes primárias: alerta da CISA (18/03/2025) e CVE-2025-30066 no GitHub Advisory Database. Relatos de invasão, capacidade de link e escolhas de infraestrutura são da operação da JMV Technology, ditos pelo Josimar no vídeo. Este texto é relato de experiência e leitura técnica, não consultoria de segurança.