Proxmox sem subscription: o que muda no repositório e o risco do \"no-subscription\

Toda instalação nova do Proxmox VE mostra aquele aviso no primeiro login: "You do not have a valid subscription for this server". A reação mais comum é procurar como tirar o aviso. A pergunta mais útil é outra: o que exatamente eu perco sem subscription, e isso importa para o meu ambiente?

A resposta curta é que você não perde nenhuma funcionalidade. A resposta longa envolve qual repositório de pacotes o seu servidor usa para receber atualização — e é aí que mora uma decisão de risco que muita gente toma por omissão.

O Proxmox é gratuito mesmo?

Sim, e sem asterisco escondido. Todo o código do Proxmox VE é aberto, sob licença AGPLv3. Não existe edição paga com recursos a mais, não existe limite de nós, de VMs, de CPU ou de RAM. Cluster, alta disponibilidade, Ceph, ZFS, backup, replicação, firewall, SDN — tudo está lá na instalação gratuita.

O que a subscription compra é acesso ao repositório enterprise e suporte técnico da Proxmox Server Solutions, com nível de resposta conforme o plano. É um modelo honesto: o produto é livre, o suporte e a estabilidade curada são o serviço.

Os três repositórios

É aqui que a decisão realmente acontece.

Uma instalação nova vem apontando para o enterprise. Sem subscription ativa, o apt update falha com erro de autenticação — e é por isso que tanta gente troca para o no-subscription logo no começo, às vezes sem entender a diferença.

Repare no que a tabela não diz: não diz que o no-subscription é instável. Ele é o mesmo código, apenas com menos tempo de maturação. Milhares de ambientes rodam produção nele sem incidente. O que muda é o perfil de risco, e risco se administra.

O risco concreto do no-subscription

O risco não é abstrato. Ele tem uma forma específica: uma atualização com regressão chega ao seu cluster antes de ter sido exercitada pela base enterprise.

Na prática, isso se manifesta em situações como:

• Uma versão de kernel que quebra o driver de uma placa de rede específica, corrigida dias depois.
• Uma atualização de pacote do cluster que muda comportamento sutil e aparece só sob carga.
• Uma mudança em componente de storage que exige passo de migração não óbvio.

Nada disso é frequente. E nada disso é problema se o seu processo de atualização tiver três coisas: backup válido antes, atualização de um nó por vez e janela para reverter. Sem essas três, o risco existe em qualquer repositório — inclusive no enterprise.

O erro que dói não é escolher o no-subscription. É escolher o no-subscription e atualizar todos os nós de uma vez, sem backup e sem ler as notas da versão.

O aviso de login e as "soluções" da internet

Existe uma quantidade grande de scripts circulando que removem o aviso de subscription editando arquivos da interface web. Funcionam. E criam três problemas que raramente são mencionados junto:

1. Quebram na próxima atualização, porque o arquivo é substituído — e às vezes quebram a interface inteira até alguém rodar o script de novo.
2. Modificam código de pacote gerenciado, o que complica diagnóstico e invalida qualquer conversa com suporte no futuro.
3. Vêm de fonte não verificada. Você está rodando script de terceiro como root no seu hipervisor. Vale ler cada linha antes, sempre.

Nossa recomendação é direta: conviva com o aviso, ou compre a subscription. É um pop-up por sessão de navegador. Não vale modificar o hipervisor por causa dele.

Quando o gratuito é a escolha certa

Há cenários em que rodar sem subscription é simplesmente a decisão correta:

• Laboratório e homologação, sempre. Inclusive, é onde o no-subscription é útil de propósito: ele recebe as atualizações antes, então o seu ambiente de teste vira o lugar onde você descobre o problema antes da produção.
• Ambientes pequenos, com um ou dois nós, sem carga crítica, operados por alguém com domínio de Linux.
• Projetos com orçamento restrito que preferem investir em backup e monitoramento antes de investir em contrato de suporte — o que, sinceramente, é a ordem certa de prioridade.

Quando a subscription se paga

E há cenários em que a conta fecha sem dificuldade:

• Produção com impacto financeiro por hora parada. Se uma hora de indisponibilidade custa mais do que o ano de subscription do nó, a discussão acabou.
• Ambiente com compliance ou auditoria que exige suporte formal do fornecedor.
• Equipe enxuta, sem alguém dedicado a acompanhar notas de versão e diagnosticar problema de kernel.
• Cluster grande, onde o custo por socket dilui bem e o risco de uma regressão simultânea em muitos nós é alto.
• Necessidade de escalar um problema para quem escreve o código, que é o que a subscription efetivamente dá.

O modelo é por socket de CPU, por ano, com níveis diferentes de tempo de resposta. É previsível e comparado a licença de hipervisor proprietário costuma ser uma fração.

O desenho híbrido que funciona bem

Um arranjo que recomendamos com frequência, porque equilibra custo e risco:

• Produção no repositório enterprise, com subscription no nível compatível com o risco do negócio.
• Homologação no no-subscription, um ambiente que espelha a produção em versão e configuração.
• Ciclo de atualização: a correção chega primeiro na homologação, roda por alguns dias com carga sintética ou espelhada, e só depois entra na janela de produção.

Esse arranjo entrega o melhor dos dois lados — você vê o problema antes, no lugar onde ele não custa nada, e a produção só recebe o que já foi exercitado.

Se o orçamento não permite subscription em tudo, uma variação: subscription apenas nos nós de produção que sustentam as cargas críticas.

Como trocar de repositório sem quebrar nada

A troca em si é simples — é uma mudança de origem de pacote. O que importa é o entorno:

1. Backup íntegro e verificado de todas as VMs antes de qualquer atualização.
2. Ler as notas da versão, especialmente em mudança de versão maior. Elas avisam sobre passos manuais.
3. Atualizar um nó por vez, migrando as VMs para os outros nós antes.
4. Validar o nó antes de seguir: cluster saudável, storage acessível, rede correta, VM de teste subindo.
5. Não misturar repositórios em nós do mesmo cluster por longo período. Divergência de versão entre nós causa comportamento estranho em migração e em HA.

Esse roteiro vale para os dois repositórios. A diferença entre enterprise e no-subscription é probabilidade; o roteiro é o que transforma probabilidade em incidente controlado.

Erros comuns

• Achar que sem subscription faltam recursos — não faltam.
• Trocar para o repositório test e deixar assim em produção.
• Rodar script da internet como root para remover o aviso de login.
• Atualizar todos os nós do cluster ao mesmo tempo.
• Atualizar sem backup válido e sem plano de reversão.
• Ignorar as notas da versão em mudança de versão maior.
• Manter nós do mesmo cluster em repositórios e versões diferentes por meses.
• Comprar subscription e continuar sem processo de atualização — o contrato não substitui o método.
• Não ter homologação, e descobrir a regressão na produção.

A conclusão prática

Rodar Proxmox sem subscription é legítimo, comum e funciona. O que separa o ambiente tranquilo do ambiente instável não é o repositório — é ter backup testado, atualizar por nó e ter onde validar antes. Se você tem isso, o gratuito atende. Se não tem, a subscription ajuda mas não resolve; o processo resolve.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, ajudamos a tomar essa decisão com os números do seu ambiente — quanto custa uma hora parada, quantos sockets você tem, qual o risco real que você aceita. Fornecemos a subscription quando ela se paga, montamos o ambiente de homologação e implantamos o processo de atualização por nó com backup verificado e ponto de reversão. Também sustentamos a operação continuamente, se preferir terceirizar essa rotina.

Quer saber se o seu ambiente está exposto na hora de atualizar? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.