SSD Nodes Learn Hosting plans →
Guias Matt ConnorPor Matt Connor · Atualizado 2026-08-24

Ubuntu LTS ou versão intermédia no servidor?

Versões intermédias do Ubuntu têm 9 meses e exigem upgrade. LTS oferece 5 anos de segurança. Veja o custo real de cada opção no servidor.

Ubuntu LTS vs versões intermédias: a resposta curta

A escolha entre uma versão LTS e uma versão intermédia do Ubuntu num servidor resume-se a um número: durante quanto tempo essa versão continua a receber atualizações de segurança. Uma LTS recebe cinco anos de manutenção de segurança padrão. Uma versão intermédia recebe nove meses; depois, as atualizações param, pelo que é necessário atualizar ou recriar o sistema. Use uma LTS em qualquer sistema de que outras pessoas dependam. Use uma versão intermédia apenas quando recriar o sistema for algo que possa fazer sem pedir autorização a ninguém.

LTS significa suporte de longo prazo. A Canonical publica uma LTS a cada dois anos, em abril dos anos pares, e uma versão intermédia a cada seis meses entre essas versões. A 26.04 LTS foi lançada em 23 de abril de 2026, e a sua manutenção de segurança padrão prolonga-se até 2031. A 26.10 está prevista para 15 de outubro de 2026 e é uma versão intermédia, pelo que o seu ciclo termina em julho de 2027.

Quanto tempo cada versão do Ubuntu é suportada

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Estes são os valores da política publicados pela Canonical em agosto de 2026, não medições feitas num servidor de teste. Uma versão LTS tem 60 meses de manutenção de segurança padrão, o que corresponde a 1 atualização planeada da versão em cinco anos. Uma versão intermédia tem 9 meses. Permanecer no ciclo de versões intermédias durante esses mesmos cinco anos exige 10 atualizações da versão, porque não é possível saltar uma versão e cinco anos abrangem dez versões.

Uma subscrição Ubuntu Pro aumenta o período da versão LTS para 120 meses, ou dez anos, e amplia a cobertura do componente main para todo o arquivo. Em agosto de 2026, o Pro é gratuito para uso pessoal em até cinco máquinas, o que cobre a maioria das pequenas frotas de VPS. Não existe uma opção equivalente para uma versão intermédia. Nove meses são todo o período disponibilizado, e nenhuma subscrição o prolonga.

O custo de nove meses num servidor real

Use 26.10 como exemplo. A versão é lançada em 15 de outubro de 2026 e a manutenção de segurança termina em julho de 2027, seguindo o mesmo ciclo de nove meses que terminou com a 25.10 em julho de 2026. Visto no calendário, isto parece representar uma janela de manutenção a cada três trimestres. Essa leitura do calendário está errada, e conduz a mais trabalho e custos.

A sequência de prazos, passo a passo

Instale a 26.10 em outubro de 2026 e aguarde até ao último momento seguro. Atualize para a 27.04 em junho de 2027, pouco antes de a 26.10 deixar de ter suporte. Mas a 27.04 foi lançada em abril de 2027, e os seus próprios nove meses terminam em janeiro de 2028. O segundo prazo chega sete meses depois do primeiro, não nove.

Atualize novamente em dezembro de 2027 para a 27.10, lançada em outubro de 2027 e com suporte até julho de 2028. A partir daqui, o padrão é fixo. Está sempre uma versão atrás da versão atual, por isso surge um prazo aproximadamente a cada seis meses. Nove meses é a duração do suporte de uma única versão. Não é o intervalo entre as suas janelas de manutenção.

Uma atualização de versão substitui o sistema operativo no local. do-release-upgrade reescreve as fontes do apt, desativa repositórios de terceiros, altera a versão de quase todos os pacotes instalados, interrompe o processo para perguntar sobre ficheiros de configuração que editou e reinicia o sistema no final. Por isso, é uma janela planeada, não uma tarefa executada em segundo plano.

Execute-a através de ssh e a ferramenta protege-o caso a sua própria ligação seja interrompida. Inicia a sua própria sessão screen e abre um segundo sshd, informando-o primeiro:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Permita essa operação. Se a firewall ou a firewall de rede separada do seu fornecedor bloquear a porta 1022, essa alternativa não estará disponível. Nesse caso, uma ligação interrompida deixa o sistema com um conjunto de pacotes parcialmente atualizado. Executar o processo dentro de tmux ou screen proporciona a mesma proteção em qualquer servidor.

As perguntas sobre os ficheiros de configuração são o que transforma uma atualização de quinze minutos numa hora:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Manter o seu ficheiro significa perder as alterações feitas na nova configuração predefinida. Aceitar o ficheiro do responsável pela manutenção significa perder o seu hardening até o repor. Nenhuma das respostas é segura sem saber o que mudou nessa versão. Por isso, ler as notas de lançamento faz parte da janela de manutenção, e não é uma tarefa opcional.

Depois, multiplique pelo número de servidores. Um VPS no ciclo intermédio representa dez janelas de atualização em cinco anos. Cinco servidores VPS representam cinquenta, a menos que todos sejam descartáveis e reconstruídos a partir de uma imagem. Cinco servidores no ciclo LTS representam cinco atualizações no mesmo período, e pode escolher o mês em que cada uma ocorre.

Por que você não pode ignorar uma versão do Ubuntu

Os caminhos de atualização são fixos. Uma versão intermediária é atualizada para a versão seguinte, seja qual for. Uma versão LTS é atualizada diretamente para a próxima LTS ou para a próxima versão intermediária, se você solicitar. Nenhuma atualização salta duas versões de uma vez. Para passar de 26.10 para 28.04 LTS, é necessário passar por 27.04 e 27.10 ou reinstalar a máquina.

Vale a pena conhecer o mecanismo, porque ele mostra que essa regra não é flexível. do-release-upgrade obtém um arquivo de metaversão de changelogs.ubuntu.com e depois baixa uma ferramenta de atualização criada para uma transição específica. A Canonical cria e testa uma transição de cada vez. Por isso, um salto que ignore uma versão não tem ferramenta nem testes correspondentes. O atualizador não recusa a operação apenas por precaução. Não há uma atualização disponível para oferecer.

A versão que será oferecida vem de uma linha da configuração:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts oferece apenas a próxima LTS. Prompt=normal oferece a próxima versão, seja LTS ou não. Prompt=never não oferece nenhuma versão. Essa é a forma de impedir que um colega bem-intencionado inicie uma atualização que você não planejou. Em uma versão que não é LTS, lts se comporta exatamente como normal, porque a versão seguinte a 26.10 é 27.04 em ambas as configurações. A verificação imprime Checking for a new Ubuntu release e depois uma linha New release ... available. ou No new release found.

Outra regra de planejamento costuma causar problemas. Uma atualização de LTS para LTS não é oferecida no dia em que a nova LTS é lançada. Ela é disponibilizada com o primeiro point release, e o lançamento de 26.04.1 está previsto para 27 August 2026. Um point release não é uma nova versão do Ubuntu, mas a mesma versão com quatro meses de correções acumuladas incorporadas a uma nova mídia de instalação, e a espera existe para que o caminho de atualização receba esses quatro meses de testes antes de ser oferecido. Uma máquina com 24.04 e Prompt=lts que respondeu No new release found. durante o verão de 2026 não estava com defeito. Ela estava seguindo a política definida. Quando o caminho for disponibilizado, a atualização de 24.04 para 26.04 LTS será a operação que você deve planejar e ensaiar.

Quando escolher uma versão intermédia

Há quatro casos em que ela é realmente vantajosa:

  • Precisa agora, neste servidor, de uma versão do kernel ou do userspace que o arquivo LTS não disponibiliza.
  • A máquina é um host de compilação, um runner de CI ou um ambiente de testes que recria a instalação a partir de uma imagem. Nesse caso, uma atualização corresponde a uma nova instância, e não a uma janela de manutenção.
  • O hardware ou uma funcionalidade do hypervisor foi disponibilizado depois de o LTS ser congelado, e não existe nenhum backport.
  • Está a verificar o que o próximo LTS vai incluir. A versão 28.04 é montada a partir das versões 26.10, 27.04 e 27.10. Encontrar uma alteração incompatível numa VPS de reserva custa menos do que encontrá-la no servidor principal.

A maioria das pessoas que escolhe uma versão intermédia precisa de um pacote mais recente, e não de uma distribuição mais recente. Existem duas alternativas mais simples. A pilha de habilitação de hardware disponibiliza kernels de versões posteriores num LTS. No 24.04, essa pilha é sudo apt install linux-generic-hwe-24.04, e avança a cada point release, começando pela segunda. Para uma única aplicação, uma imagem de contentor ou o repositório do próprio fornecedor atualiza apenas um componente, em vez de todo o sistema operativo.

Quando uma versão intermédia é a escolha errada

  • Qualquer sistema com utilizadores pagantes ou uma escala de plantão. Estaria a aceitar uma atualização obrigatória duas vezes por ano em troca de versões de pacotes que pode nunca utilizar.
  • Qualquer máquina em que unattended-upgrades faça a aplicação das atualizações de segurança por si. Essa automatização só é tão eficaz quanto o repositório de segurança de onde obtém os pacotes.
  • Uma frota que atualiza manualmente, porque o custo real é uma janela de manutenção multiplicada pelo número de máquinas.
  • Qualquer sistema que instale e depois não volte a consultar durante um ano. Uma versão intermédia esquecida transforma-se, nove meses depois, num servidor exposto à Internet sem correções.

Esta última falha é silenciosa, o que a torna perigosa. Quando uma versão chega ao fim da vida útil, os respetivos pacotes passam para old-releases.ubuntu.com, por isso sudo apt update começa a falhar contra archive.ubuntu.com com erros 404. As listas de pacotes armazenadas no disco ficam desatualizadas. unattended-upgrades continua a ser executado segundo o temporizador e continua a escrever linhas como esta em /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Essa linha é igual num servidor totalmente atualizado e num servidor cuja versão terminou há quatro meses. A menos que alguém leia os erros do apt ou acompanhe a data de fim da vida útil, nada na máquina indica qual dos dois casos está a consultar.

O tipo de alteração que chega primeiro ao interim track

Em março de 2026, um engenheiro da Canonical propôs, no Ubuntu discourse, remover o bootloader GRUB assinado fornecido para secure boot no 26.10. A proposta remove os drivers de sistema de ficheiros para btrfs, hfsplus, xfs e zfs, os analisadores de imagens JPEG e PNG, as tabelas de partição Apple, /boot em LVM, software RAID que não seja RAID 1 e um /boot encriptado com LUKS. O motivo indicado é que os analisadores dentro de um bootloader são uma fonte recorrente de falhas de segurança e que a lógica de armazenamento e encriptação pertence ao initramfs, o pequeno sistema de ficheiros inicial em RAM que o kernel monta antes do root real. Em agosto de 2026, isto é uma proposta em discussão, não uma alteração disponibilizada.

Na maioria das instâncias VPS, isto não alteraria nada, porque arrancam sem secure boot a partir de um /boot ext4 simples numa tabela de partições GPT. Verifique a sua instância em vez de presumir. Se o seu root for ZFS, ou se /boot estiver em btrfs ou dentro de LUKS, esta é exatamente a classe de alteração que o pode atingir primeiro no interim track. A recomendação do próprio tópico para os utilizadores afetados é permanecer numa LTS. Essa recomendação resume todo o argumento numa frase. As versões interim são onde as alterações são testadas. Uma LTS é onde chegam depois de dois anos de versões interim terem identificado aquilo que quebram.

O mesmo padrão surge de formas menores em cada versão interim. As versões predefinidas da base de dados, do runtime da linguagem e da configuração do init avançam, pelo que ficheiros de configuração que funcionavam podem deixar de funcionar. Avançar as versões predefinidas é a função de uma versão interim. Por isso, ler as notas de lançamento antes de cada uma dessas dez atualizações faz parte do custo que aceitou pagar.

Escolher o track ao preparar o servidor

Escolha o track durante a instalação, porque alterá-lo depois exige uma reinstalação ou uma sequência de upgrades. Num servidor novo, quatro comandos mostram a situação:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a deve indicar a release que pretendia instalar, e, numa LTS, a linha de descrição termina com LTS. A linha Prompt deve corresponder ao track escolhido, não ao track incluído por acaso na imagem do fornecedor. do-release-upgrade -c numa LTS atual deve responder No new release found.. Se apresentar uma release interim, Prompt está definido como normal e alguém deve confirmar se isso foi intencional. pro security-status indica quantos pacotes instalados estão abrangidos por cada stream de atualizações e informa claramente quando a máquina não está associada a uma subscrição.

Registe depois a data de fim de vida num local onde a volte a ver, junto das restantes notas de instalação desse servidor. Isto faz parte do mesmo trabalho que os primeiros dez minutos num VPS novo, porque uma data de suporte guardada apenas na memória de alguém é precisamente a que expira sem ser notada. Se o ciclo de seis meses é aquilo que pretende evitar por completo, o modelo de releases do FreeBSD comparado com o Linux merece uma hora de leitura antes de comprometer uma frota com qualquer uma das opções.

FAQ

Devo executar uma versão interim do Ubuntu num servidor de produção?

Na maioria dos casos, não. Uma versão interim deixa de receber atualizações de segurança nove meses depois do seu lançamento. Assim, usar essa versão em produção implica uma janela de atualização obrigatória aproximadamente duas vezes por ano, para sempre. As exceções legítimas são máquinas que já são reconstruídas a partir de uma imagem, como runners de CI e hosts de build. Nesses casos, a atualização cria uma nova instância em vez de exigir uma janela de manutenção. Se houver utilizadores reais dependentes do servidor, instale a LTS e use as janelas poupadas noutra tarefa.

Durante quanto tempo uma versão interim do Ubuntu recebe suporte?

Nove meses. A 26.10 será lançada em 15 de outubro de 2026 e a sua manutenção de segurança termina em julho de 2027, seguindo o mesmo ciclo que terminou a 25.10 em julho de 2026. Todas as versões interim seguem este modelo: são lançadas em abril ou outubro e terminam nove meses depois. Uma LTS recebe cinco anos de manutenção de segurança padrão, prolongados para dez anos com o Ubuntu Pro, que, em agosto de 2026, é gratuito para uso pessoal em até cinco máquinas.

Posso saltar versões do Ubuntu durante uma atualização?

Não. do-release-upgrade avança uma versão de cada vez: uma versão interim passa para a versão seguinte, e uma LTS pode passar diretamente para a LTS seguinte. Para passar da 26.10 para a 28.04 LTS, é necessário executar primeiro a atualização para a 27.04 e depois para a 27.10, ou reinstalar a máquina. A Canonical cria e testa uma transição de cada vez. O atualizador descarrega uma ferramenta específica para esse salto, por isso não existe uma ferramenta para um salto de duas versões e essa opção nunca é apresentada.

O que acontece quando a minha versão do Ubuntu chega ao fim de vida?

Os pacotes passam para old-releases.ubuntu.com. Por isso, sudo apt update começa a falhar contra archive.ubuntu.com com erros 404, e não são publicadas mais atualizações de segurança para essa versão. Nada na máquina anuncia esta situação. O servidor continua a funcionar e a servir tráfego, enquanto cada vulnerabilidade publicada posteriormente permanece aberta. A recuperação consiste em executar uma atualização de versão sob pressão de tempo ou reconstruir a máquina. Por isso, monitorize a data em vez dos sintomas.

O kernel da LTS é demasiado antigo para hardware novo?

Normalmente, não, porque uma LTS não mantém o kernel original durante cinco anos. A pilha de ativação de hardware, HWE, disponibiliza kernels de versões posteriores nas point releases da LTS. Uma instalação de servidor pode ativá-la com um pacote como linux-generic-hwe-24.04. Verifique o que está a executar com uname -r antes de concluir que o kernel é o bloqueio. Se o componente em falta for uma versão de userspace e não do kernel, um container ou um repositório do fornecedor representa uma alteração muito menor do que mudar toda a máquina para o ciclo interim.