Se o seu pipeline depende do “grátis”, você não tem um pipeline — você tem um cupom. Surgiram relatos este mês de que o Xilinx Vivado 2026.1 está removendo o suporte a Linux no free tier, mantendo-o para usuários pagos. Isso não é nota de rodapé. É um lembrete de que o free tier é uma rubrica de orçamento de marketing, não um contrato. Quando o fornecedor pisca, sua equipe sangra tempo.
Já vi esse filme: os dynos gratuitos do Heroku foram descontinuados. A mudança de licença do Docker Desktop obrigou empresas a pagar. A mudança da HashiCorp para a BSL desencadeou o OpenTofu. As concessões “gratuitas” do GitHub mudaram conforme o uso cresceu. Nada disso foi malicioso; foram decisões de negócio. Seu trabalho, como CTO, é garantir que isso não vire a sua indisponibilidade.
O risco é maior do que uma mudança de preço
A maioria dos CTOs enxerga o risco do free tier como volatilidade de custo. É uma visão estreita. Os riscos mais existenciais são:
- Bloqueio de plataforma: Suporte a SO ou arquitetura removido justamente no único tier que você usa (ex.: o free tier perde suporte a Linux; Apple Silicon não é suportado; builds apenas com CUDA). Sua equipe nearshore no Brazil rodando Ubuntu e Fedora vira, de repente, cidadã de segunda classe.
- Restrições de distribuição: Alterações de licença que impedem você de incorporar ou distribuir ferramentas na sua plataforma interna (ex.: termos ao estilo BSL bloqueando ofertas como serviço gerenciado ou uso multi-tenant).
- Imposição de direitos de uso (entitlements): Contagem de assentos, exigência de SSO ou verificações de licença online que quebram em builds air-gapped ou durante indisponibilidade do fornecedor.
- Cativeiro de formato: Formatos proprietários de projeto ou artefatos de build que não fazem ida e volta limpa para padrões abertos, tornando a migração cara ou com perdas.
Quando o free tier do Vivado supostamente remove Linux, um estudante perde conveniência. Uma startup com time de hardware Linux-first perde dias. Multiplique isso pelo seu toolchain: IDEs, depuradores, ferramentas de contêiner, IaC, SDKs de IA, ferramentas de design, testes em navegador — e sua pilha “gratuita” vira um campo minado.
Um framework de continuidade do toolchain que você consegue executar neste trimestre
Aqui está o playbook que implementamos com clientes que não podem se dar ao luxo de surpresas. Ele é opinativo porque as surpresas não ligam para seus sentimentos.
1) Faça o inventário e depois pontue a substituibilidade
Liste todas as ferramentas no caminho crítico do desenvolvedor. Não é tudo — apenas o que bloqueia de PR a produção. Para cada ferramenta, atribua notas de 1–5 em três eixos (1 é ruim):
- Portabilidade: Usa formatos abertos e interfaces padrão? (ex.: Terraform HCL vs. um DSL fechado; ELF/PE vs. um contêiner binário proprietário)
- Reprodutibilidade: Você consegue construir e ativar offline em um ambiente hermético? (builds determinísticos, dependências fixadas, instaladores em cache, tokens de licença offline)
- Neutralidade de SO: Há suporte de primeira classe em Linux, Windows e macOS no tier que você usa?
Qualquer coisa com pontuação total ≤7 é um sinal vermelho. Essas são as ferramentas que entram primeiro no plano de continuidade.
2) Estabeleça um orçamento de “continuidade de entitlements”
Separe de 0,5–1,5% da folha de pagamento de engenharia como um orçamento carimbado para “transformar o grátis em pago” sem teatro de aprovações. Se você lidera uma equipe de 20 engenheiros com custo total médio de $200k, isso é $4M. Um por cento dá $40k/ano. Isso compra de 40–80 assentos profissionais de muitas ferramentas, ou alguns poucos licenciamentos enterprise, sem corre-corre.
Por que a faixa? Se sua pilha pende para closed-source (EDA, labs de dispositivos móveis, SDKs proprietários), puxe para 1–1,5%. Se você é majoritariamente OSS com licenças permissivas e boa reprodutibilidade, 0,5–0,75% é realista.
3) Construa caminhos duplos no CI para os 3 maiores riscos
Escolha as três ferramentas com menor nota. Crie um job agendado no CI (semanal) que execute um caminho alternativo de ponta a ponta. Não busque paridade no dia um; busque “conseguimos enviar na próxima semana se precisar”. Exemplos:
- IaC: Mantenha um plano OpenTofu em paralelo ao Terraform. Se os termos de licença mudarem de novo, você aciona um switch, não reescreve o mundo.
- Contêineres: Construa imagens tanto via Docker BuildKit quanto via uma alternativa como Podman/Buildah. Publique no mesmo registry; verifique equivalência byte a byte ou no nível de metadados.
- SDKs de IA: Mantenha um adaptador que consiga chamar pelo menos dois provedores de inferência ou backends self-hosted. Rode testes de contrato noturnos para afirmar contratos de resposta idênticos (não o conteúdo).
Sim, é trabalho extra. Não, você não vai amortizar isso com “migramos em um sprint”. Migrações nunca acontecem em um sprint; acontecem durante um incidente com cliente, quando você menos quer.
4) Normalize os formatos de projetos e artefatos
Onde você não puder trocar de ferramenta, torne seus outputs portáveis:
- Manifests de projeto: Exporte e armazene junto ao código-fonte em formatos abertos (JSON, YAML). Se a ferramenta primária guarda um arquivo de projeto binário, mantenha um passo de exportação scriptado a cada release.
- Relatórios de teste e cobertura: Emita JUnit XML, LCOV, SARIF. Não fique acorrentado ao visualizador do fornecedor.
- Artefatos de design: Para CAD/EDA, mantenha uma cópia de referência (gold) em um formato de intercâmbio aberto além do formato nativo.
O objetivo é simples: seu repositório contém o suficiente para trocar de ferramenta sem engenharia reversa.
5) Neutralidade de SO por construção
Pare de assumir que “funciona no meu laptop” cobre sua equipe. No Brazil, uma fatia grande de engenheiros seniores usa Linux como máquina do dia a dia. Se um fornecedor remove o suporte a Linux justamente no único tier que você usa, você tem três opções:
- Pague pelo tier que suporta o SO. Planeje o orçamento agora (veja o passo 2). Não litigue isso no Slack após o anúncio.
- Centralize a ferramenta em boxes de desenvolvimento remotos que executem o SO suportado pelo fornecedor. Exponha via remote desktop/X11/VNC ou GUI web, com controle de acesso por função. Investir 6–8 horas por desenvolvedor para onboard é um seguro barato.
- Substitua a ferramenta por uma alternativa OSS ou paga que suporte o SO da sua equipe. Isso raramente é trabalho de “tempo livre”; trate como projeto, com janela de migração e critérios de saída.
Seja qual for a escolha, garanta o mesmo resultado no CI. Se o seu CI ainda depende de um caminho de SO não suportado, você não tem continuidade.
6) Simulados de licença e autenticação
Serviços SaaS e servidores de licença caem. O SSO quebra. Tokens expiram. Treine de verdade:
- Teste de ativação offline: Trimestralmente, rode seu build e ferramentas críticas com a internet bloqueada. Documente o que falha. Capture os passos e credenciais necessários para ativação offline ou chaves de emergência.
- RTO de reatribuição de assento: Cronometre quanto tempo leva para recuperar um assento e reatribuir a um engenheiro que começa hoje. Se passar de 15 minutos, você precisa de processo ou suporte do fornecedor melhores.
- Fallback de autenticação do fornecedor: Mantenha uma conta de emergência (break-glass) com autenticação local para plataformas críticas onde o SSO é ponto único de falha.
O tempo médio para restaurar importa mais do que o tempo médio até a falha. Crie um placar. Melhore-o.
7) Vigie a EULA como você vigia a produção
Crie um processo leve de “monitor de termos”:
- Monitore URLs de páginas de preços, licenças e termos em busca de diffs. Você não precisa de ferramenta sofisticada; um diff HTTP diário com normalização de HTML-para-texto funciona.
- Rodízio de DRI: Designe um DRI mensal para revisar mudanças e resumir o impacto em 3 bullets no #eng-leadership.
- Pré-negocie com os fornecedores de que você depende. Peça aviso prévio de 90 dias sobre mudanças materiais no seu MSA, chaves offline para CI e linguagem sobre estabilidade de suporte a SO.
É mais barato negociar quando você não está em pânico.
8) Quantifique o custo de não fazer nada
Líderes financiam o que é medido. Para cada ferramenta sinal vermelho, estime:
- Tempo de troca: Horas para colocar um caminho alternativo de pé até “pronto para enviar”. Inclua CI, documentação, onboarding e testes de aceitação de paridade.
- Impacto de um congelamento: Se o free tier ou o suporte a SO sumisse hoje, quantos PRs por dia seriam bloqueados e por quanto tempo?
- Custo de licença: Custo anual para migrar para um tier pago que elimine o risco. A maioria das ferramentas de dev cai na faixa de USD $200–$600 por assento por ano ou $5–$25 por assento por mês, com tiers enterprise mais altos.
Quando você coloca “$40k compram continuidade vs. $250k de tempo de engenharia perdido durante duas semanas de congelamento” em um único slide, os CFOs dizem sim.
Exemplos concretos (e o que é “o bom”)
A guinada de licenciamento do Docker Desktop
Quando o Docker mudou o licenciamento para uso empresarial, as equipes que já haviam separado “conveniência do desenvolvedor” de “necessidade do CI” mal pestanejaram. Elas tinham workers BuildKit no lado do servidor no CI e alternativas locais ou Desktop licenciado para devs. Os retardatários sustentaram um thread de 700 mensagens no Slack debatendo gasto de cinco dígitos vs. “vamos só desinstalar”, e perderam uma semana.
O que é bom: Seus builds de CI rodam em workers Linux headless com containerd/buildx. Devs locais têm Desktop pago ou um setup documentado com Podman/nerdctl. O sistema de build não liga.
A mudança de licença da HashiCorp e o OpenTofu
Quando a HashiCorp migrou para a Business Source License, algumas empresas descobriram obrigações que não conseguiam cumprir para suas plataformas internas. As que tinham um plano OpenTofu em paralelo conseguiram mudar em dias, não em trimestres.
O que é bom: Um “drift check” noturno que planeja tanto Terraform quanto OpenTofu contra uma conta não produtiva e afirma zero deltas de recursos. Seu registry de módulos e pipelines são compatíveis com ambos.
Free tier do Vivado supostamente removendo Linux
Equipes de hardware e embarcados em Linux vão ou orçar assentos pagos, ou centralizar a ferramenta em hosts Windows remotos. A pior opção é status quo com esperança.
O que é bom: Um pequeno pool de VMs Windows ou Linux suportado rodando o Vivado com licenças flutuantes, encaminhadas para dentro da sua rede privada. Engenheiros desenvolvem localmente, mas sintetizam no farm. O CI roda jobs headless usando o mesmo farm. O procurement conhece o teto: “Mantemos 10 licenças flutuantes; estourar para 20 custa $X/dia.”
Checagem de realidade do nearshore: Brazil roda Linux
Se você trabalha com equipes nearshore no Brazil, aposte que Linux é a máquina do dia a dia. Por que isso importa:
- Atrito aparece na velocidade de merge: Cada gambiarra por SO não suportado custa 1–2 horas por dev por semana. Em um squad de 10 pessoas, isso dá ~400 horas por ano — $60k–$80k de custo total em termos dos EUA.
- Assentos pagos vencem sprints desperdiçados: Se uma licença pro custa $25/mês por assento e economiza 1 hora/semana, você está recomprando $400–$600 de produtividade por engenheiro por mês por $25. É um ROI de 16–24x.
- Farms remotos de ferramentas fecham o gap: Coloque ferramentas apenas GPU/EDA/Windows em VMs com proxy em sa-east-1 (São Paulo) ou on-prem no Brazil para manter latência abaixo de 50 ms para sua equipe. Engenheiros ficam no SO preferido; o CI fica estável.
Nearshore não é “engenheiro barato”. É sobre sobreposição de fuso e senioridade. Não apague essas vantagens com atrito de toolchain que você poderia ter pago para eliminar.
Execute isso em 30/60/90 e encerre o assunto
Dia 0–30: Enxergue seu risco
- Faça o inventário. Pontue portabilidade, reprodutibilidade, neutralidade de SO.
- Escolha os três piores. Rascunhe alvos de migração e alternativas.
- Crie a linha de orçamento. 0,5–1,5% da folha de engenharia. Pré-aprove o gasto até esse teto para o VP de Engenharia ou Head de Plataforma.
Dia 31–60: Crie saídas
- Coloque de pé jobs de CI com caminho duplo para os três principais. Eles podem rodar semanalmente; eles só precisam funcionar.
- Normalize exports e artefatos. Adicione passos de “export portátil” aos seus pipelines de release.
- Pilote um farm remoto de ferramentas para um item com bloqueio de SO. Meça tempo de onboarding e latência percebida pelo desenvolvedor.
Dia 61–90: Operacionalize
- Rode um simulado de ativação offline e um exercício cronometrado de reatribuição de assento. Publique o RTO.
- Configure diffs de termos/watch e o rodízio de DRI. O primeiro resumo vai para #eng-leadership.
- Negocie com seus dois principais fornecedores períodos de aviso, chaves offline e compromissos de suporte a SO. Amarre isso no seu MSA ou renovação.
Após 90 dias, você terá transformado “esperança no free tier” em “continuidade que você controla”.
O que não fazer
- Não trave guerras filosóficas sobre se um fornecedor “deveria” suportar seu SO em um free tier. Eles não são seu time de plataforma. Você é.
- Não conte com migrações heroicas durante um incidente. Se o caminho alternativo não roda semanalmente, ele não existe.
- Não centralize tudo “por via das dúvidas”. Centralize seletivamente onde SO ou licenciamento bloqueiam você, não por dogma.
- Não esconda a conta. Mostre para finanças a matemática do custo de não fazer nada. Continuidade é barata comparada a paradas.
Se você não levar mais nada daqui
O free tier vai desaparecer na pior hora — ou, pior, vai continuar, mas aquela funcionalidade de que você depende (suporte a Linux, modo headless, ativação offline) vai, silenciosamente, subir de nível na tabela de preços. Trate “grátis” como avaliação, não como fundação. Seus desenvolvedores merecem mais do que um toolchain mantido por um código de cupom.
Principais pontos
- Pontue suas ferramentas por portabilidade, reprodutibilidade e neutralidade de SO; qualquer coisa ≤7 precisa de plano de continuidade.
- Orce 0,5–1,5% da folha de engenharia para “transformar grátis em pago” sem drama.
- Mantenha CI com caminho duplo semanal para suas três ferramentas mais arriscadas; migrações que não são ensaiadas não existem.
- Normalize exports e artefatos para que seu repo seja portável, não cativo de um formato de fornecedor.
- Planeje para bloqueio de SO: compre o tier, centralize em um farm de ferramentas ou substitua a ferramenta — de forma deliberada.
- Rode simulados de licença/autenticação e vigie EULAs como você vigia a produção; negocie aviso e chaves offline.
- Equipes nearshore no Brazil são heavy em Linux; remover atrito de SO retorna ROI de 16–24x com gasto modesto de licenças.