Atualização do Plesk Obsidian: novas funcionalidades para fornecedores de alojamento web

Separar claramente a versão e os componentes

A situação registada a 2 de outubro de 2026 é a seguinte para o Produto principal Plesk Obsidian 18.0.81 Atualização 2. Esta atualização foi lançada a 29 de setembro de 2026 e corrige um problema de segurança crítico. As novas funcionalidades do painel descritas neste artigo fazem parte da versão Plesk Obsidian 18.0.81, de 15 de setembro de 2026; por outro lado, a Atualização 1 e a Atualização 2 incluem correções documentadas de erros e de segurança.

No entanto, podem existir atualizações posteriores que não alterem a versão principal 18.0.81 Update 2: O registo de alterações, por exemplo, inclui atualizações para extensões como o SSL It! e o Let’s Encrypt, de 29 de setembro, bem como atualizações dos pacotes PHP, de 30 de setembro de 2026. Quem se limita a referir-se a um „Plesk atual“ omite, portanto, uma informação importante para o planeamento e o suporte.

O Plesk distingue vários níveis de atualização. Os pacotes do Plesk constituem o próprio painel e as suas funcionalidades diretamente associadas. Além disso, existem pacotes de serviços e extensões disponibilizados pelo Plesk, que oferecem funcionalidades adicionais ou permitem a integração com serviços externos. Por conseguinte, um novo número de versão de uma extensão não significa necessariamente que o núcleo do Plesk também esteja atualizado – e vice-versa.

Além disso, cada um Painel de alojamento Dentro de um sistema operativo, existem outros níveis: pacotes do sistema operativo, bem como componentes de terceiros, tais como bases de dados, motores de execução PHP, servidores Web e serviços de e-mail. As suas fontes de pacotes, ciclos de suporte e dependências não seguem necessariamente o ritmo de lançamento do Plesk. Para um fornecedor, esta separação é relevante na prática, uma vez que os padrões de erros, as janelas de manutenção e as responsabilidades podem variar consoante o componente em causa.

Por isso, a documentação do estado atual do sistema deve indicar sempre a combinação específica: versão do Plesk com número de atualização, versão das extensões instaladas, sistema operativo e pacotes de tempo de execução relevantes. No caso de funções relacionadas com certificados ou aplicações, deve incluir-se também a integração utilizada. Desta forma, torna-se possível determinar, por exemplo, se uma alteração provém do SSL It!, de uma integração do Let’s Encrypt ou do núcleo do painel. Isto evita expectativas pouco claras nos comunicados aos clientes e simplifica a identificação do problema no apoio técnico.

Como as atualizações do Plesk afetam os fornecedores

Na linha Obsidian 18.0, as atualizações são lançadas de forma contínua e sequencialmente instalado. Não é possível saltar atualizações intermédias individuais. Isto cria um percurso de atualização definido, mas não isenta um fornecedor de verificar o seu próprio ambiente: quanto mais sites de clientes, dependências PHP individuais e extensões um servidor albergar, mais importante se torna a questão de saber que alteração afeta que classe de serviço.

O Plesk descreve atualizações automáticas para as suas próprias atualizações e opções separadas para componentes de terceiros incluídos, bem como para pacotes do sistema. No entanto, a página de documentação apresenta informações contraditórias sobre a configuração padrão da opção relativa aos componentes de terceiros. Por conseguinte, os administradores não devem partir do princípio de que existe uma configuração predefinida válida globalmente, mas sim verificar as opções efetivamente definidas para cada servidor em Tools & Settings > Update Settings verificar. É necessário ter especial cuidado, pois os componentes mais recentes podem ser incompatíveis com os sites alojados.

Para a operação de muitas instâncias de clientes, esta distinção constitui uma vantagem quando traduzida em processos. As correções no painel e as alterações de segurança podem ser planeadas com base no seu âmbito; por outro lado, as substituições de componentes são sujeitas a uma avaliação de compatibilidade específica. Uma oferta de alojamento gerido não tem de adotar imediatamente todas as versões de pacotes disponíveis. O que é decisivo é saber quais as versões que se adequam à pilha prometida, à base de clientes testada e ao modelo de suporte previsto.

Os benefícios das versões mais recentes do Obsidian distribuem-se por várias áreas operacionais: as funções de diagnóstico podem estruturar o suporte de primeiro nível, as novas ferramentas de alojamento de aplicações ampliam as opções tarifárias e as funções de certificação e assistência abrangem a segurança e a gestão de direitos. O artigo também aborda os fundamentos e desenvolvimentos anteriores da linha de produtos Plesk Obsidian 2025: Inovações revolucionárias para o alojamento web . No entanto, para o lançamento atual, o que é determinante é o componente específico, e não apenas o nome do produto.

A automatização não é, portanto, uma decisão de aprovação genérica. É aconselhável estabelecer uma separação entre a instalação regular de atualizações documentadas do Plesk e as alterações controladas de forma deliberada na pilha do cliente. Especialmente no caso de servidores partilhados, esta delimitação evita que uma alteração despercebida de um componente afete simultaneamente muitos sites independentes uns dos outros. Não substitui os testes, mas torna os riscos visíveis e identificáveis.

Novas funcionalidades por cenário de alojamento

Na hospedagem partilhada, uma das primeiras aplicações consiste na identificação mais rápida de falhas nos domínios. As informações contidas em Plesk Obsidian 18.0.81 O diagnóstico DNS de acesso geral reúne verificações relativas à resolução, a aspetos relacionados com MX, ao DNSSEC, aos servidores de nomes e ao prazo de validade do domínio. O relatório de fácil compreensão apresentado no painel pode ajudar os colaboradores do suporte a analisar de forma estruturada questões relacionadas com o DNS, o correio eletrónico e a delegação, antes de estas serem escaladas.

No entanto, o relatório é um Diagnóstico e não há correção automática. Em particular, os aliases de domínio não são, de momento, abrangidos. Mesmo que um resultado indique uma delegação ou zona incorreta, a correção poderá, se for o caso, caber ao registador ou a um operador de DNS externo. Como ferramenta de suporte, esta função é, por isso, particularmente útil quando as responsabilidades e o próximo passo de escalamento são claramente definidos no ticket.

Um segundo domínio é Alojamento de Aplicações para agências e programadores. O Node.js Toolkit 2.5.0 inclui uma visão geral centralizada das aplicações Node.js ativadas e a configuração com um clique de projetos existentes. A deteção automática consegue identificar várias estruturas de servidor comuns, bem como front-ends estáticos. Além disso, a extensão pnpm é suportada exclusivamente no Plesk para Linux. Isto reduz as etapas individuais recorrentes, mas não garante que cada implementação individual possa ser adotada sem alterações.

A nova extensão Python 1.0.0 também se destina a sistemas Linux e oferece suporte a Python por domínio, ambientes virtuais, dependências, variáveis de ambiente e segredos armazenados de forma encriptada. As aplicações são executadas como aplicações WSGI através do Phusion Passenger; a autorização „gestão do suporte a Python“ pode ser controlada através de planos de serviço e subscrições. Isto pode tornar-se uma funcionalidade de tarifação controlada, não necessariamente um substituto automático para qualquer arquitetura Python.

Uma terceira área abrange certificados e funções de assistência. Na versão 18.0.81, o SSL It! suporta a validação DNS como alternativa à validação HTTP para as integrações «ext-acme» e «ext-letsencrypt» mencionadas. Isto é relevante, por exemplo, para domínios sem a porta 80 aberta. Continua a ser necessário dispor de uma forma adequada de definir registos DNS na zona efetivamente responsável; a mera visualização de um registo não confere acesso de escrita.

O MCP está desativado por predefinição na versão 18.0.81 e pode ser ligado através de uma conta WebPros. Os administradores definem em panel.ini os tipos de utilizadores autorizados a ligar-se aos clientes MCP. A sua adequação depende, portanto, não só da função, mas também das funções, das autorizações e do registo. As funcionalidades de extensão dependentes da plataforma, a responsabilidade pelo DNS externo e a arquitetura da aplicação do cliente determinam, em conjunto, qual a novidade que se enquadra em cada plano tarifário.

Comparação de funcionalidades para o planeamento de produtos

Para o planeamento do produto, a designação «Plesk Obsidian» não é suficiente: as funcionalidades relevantes neste contexto provêm, em parte, do produto principal e, em parte, de extensões com versões próprias. Por isso, um fornecedor não deve avaliar as funcionalidades apenas com base na sua utilidade, mas sim incluir no catálogo de tarifas o sistema operativo, o modelo de licenciamento e as dependências técnicas de cada caso.

A visão geral distingue de forma particularmente clara entre uma funcionalidade da plataforma e um serviço tarifário comercializável. O diagnóstico DNS pode estar amplamente disponível como ferramenta de suporte. O Python, por outro lado, só deve ser incluído em ofertas Linux cuja gestão de direitos e limites de suporte estejam previstos para esse efeito. No caso do Node.js, o fornecedor deve distinguir a respetiva subfunção: o pnpm está documentado como exclusivo do Linux, enquanto o changelog não impõe restrições correspondentes à visão geral central e à configuração automática.

Também as funcionalidades de certificados e do MCP exigem uma decisão relativa ao produto, em vez de uma ativação global. No caso do DNS-01, a responsabilidade pela zona determina a sua utilidade prática. No caso do MCP, a ligação técnica é apenas uma parte do projeto; o que é determinante é o círculo de pessoas autorizadas, os processos rastreáveis e o tratamento de ações com efeitos colaterais.

Diagnóstico de DNS e certificados no Suporte

A versão do Plesk Obsidian 18.0.81, já disponível para o público em geral Diagnóstico de ADN É adequado como primeira avaliação técnica de um ticket de domínio. No painel, a opção „Troubleshoot DNS“ abre um relatório de fácil compreensão sobre a resolução DNS, verificações relacionadas com MX, DNSSEC, problemas com servidores de nomes e a data de validade do domínio. Isto agiliza a verificação preliminar, mas não substitui nem a análise da zona autoritativa nem a coordenação com o registador ou com um operador de DNS externo.

Para garantir um processo de primeiro nível repetível, o apoio técnico deve, em primeiro lugar, registar o domínio principal em causa e o relatório e, em seguida, atribuir a responsabilidade e a gravidade do problema. Se o relatório indicar, por exemplo, uma delegação incorreta, a correção fica frequentemente fora do âmbito do painel. É igualmente importante ter em conta o limite documentado: os aliases de domínio não são, de momento, abrangidos por esta verificação.

Para o diagnóstico na linha de comandos, o registo de alterações documenta a seguinte chamada com um domínio de exemplo neutro. Antes da utilização, um administrador deve consultar a ajuda ou a documentação de comandos da versão do Plesk efetivamente instalada. A partir apenas da sintaxe mencionada no registo de alterações, não é possível deduzir qualquer garantia adicional sobre todos os efeitos do comando.

plesk repair dns -n -j -check-resolution example.com

No caso dos certificados, alargado Validação do DNS-01 O âmbito de aplicação possível: o SSL It! pode ser utilizado no Plesk Obsidian 18.0.81 como alternativa à validação HTTP para a emissão e renovação. Isto é relevante, por exemplo, para domínios de API ou de e-mail, nos quais a porta 80 não está deliberadamente aberta. O Plesk apresenta os registos DNS necessários e guarda o método selecionado por domínio para renovações futuras.

No entanto, o processo não é automaticamente bem-sucedido só porque é apresentado um registo. O operador necessita de acesso de escrita à zona DNS efetivamente responsável ou de um processo de automatização devidamente configurado. De acordo com o changelog, a validação DNS introduzida na versão 18.0.81 aplica-se apenas às integrações «ext-acme» e «ext-letsencrypt» do SSL It!, e não de forma geral a todos os fornecedores de certificados.

Isso é distinto da atualização de expansão que será lançada posteriormente SSL It! 1.24.0 de 29 de setembro de 2026. Com esta versão, é possível proteger um domínio sem alojamento através do painel ou da linha de comandos com um certificado curinga; a renovação automática é igualmente efetuada com um certificado curinga. Esta adição não faz parte do conjunto de funcionalidades original do Plesk Obsidian 18.0.81, mas segue o próprio estado de versão e lançamento da extensão.

Alojamento de aplicações como opção tarifária controlada

Com as extensões atuais, o alojamento de aplicações torna-se mais facilmente diferenciável como opção de plano. O Node.js Toolkit 2.5.0 inclui uma visão geral centralizada das aplicações Node.js ativadas e uma configuração com um clique dos projetos existentes. Além disso, a extensão suporta o gestor de pacotes pnpm no Plesk para Linux. Desta forma, um fornecedor pode padronizar tarefas de configuração recorrentes, sem ter de tratar cada aplicação do cliente como um servidor individual.

De acordo com o changelog, a deteção de projetos inclui, entre outros, o Express, o Next.js, o NestJS e o Nuxt.js, bem como front-ends estáticos baseados em React, Vue.js, Angular ou Vite. O Plesk pode criar um ficheiro de arranque compatível com o Passenger, ter em conta portas codificadas e definir a raiz do documento, sendo que as alterações são apresentadas antes da confirmação. As interfaces estáticas são criadas e fornecidas sem a necessidade de um processo Node.js em execução permanente.

Esta automatização é útil, mas não substitui uma revisão da arquitetura. Vários processos, filas de trabalhadores, proxies reversos específicos, segredos externos ou pipelines de compilação próprios podem exigir regras operacionais adicionais. De acordo com o changelog, a restrição relativa ao Linux aplica-se expressamente ao pnpm; no que diz respeito à visão geral centralizada dos domínios e à configuração automática com um clique, não é indicada qualquer restrição de plataforma correspondente. Por conseguinte, as descrições dos planos devem referir estas subfuncionalidades separadamente.

A extensão Python 1.0.0 disponibiliza, no Linux, uma oferta controlável individualmente por domínio. Os clientes podem criar ambientes virtuais, instalar dependências através da interface, visualizar metadados do ficheiro pyproject.toml e gerir variáveis de ambiente, bem como segredos armazenados de forma encriptada. A ativação é feita através da autorização „Gestão de suporte Python“ nos planos de serviço e nas subscrições.

Do ponto de vista técnico, estas aplicações funcionam como Aplicações WSGI através do Phusion Passenger; a configuração do servidor Web é criada automaticamente pelo Plesk. Um plano „Python Web App“ pode, por exemplo, incluir ambientes virtuais, um limite definido de recursos e suporte para projetos WSGI clássicos. Isso não significa, contudo, que o mesmo plano abranja pilhas ASGI complexas, workers em execução contínua ou arquiteturas especiais em contentores.

Para compreender as funcionalidades mais antigas e as alterações na interface, pode consultar o artigo Plesk Obsidian: resumo das novidades e melhorias podem ser utilizados como complemento. No que diz respeito às novas tarifas, é fundamental documentar em conjunto a versão alargada, os limites documentados da plataforma, as autorizações e o tipo de aplicação concretamente suportado.

Implementar as atualizações de forma escalonada na produção

Numa ambiente de um fornecedor de serviços, uma atualização do painel de alojamento não deve começar logo ao clicar pela primeira vez no servidor principal em produção. Primeiro, crie um Inventário das versões do Plesk, das versões do sistema operativo, das extensões ativadas e das aplicações dos clientes que nele são executadas. São igualmente importantes as dependências externas, tais como fornecedores de DNS, servidores de retransmissão de e-mail, cópias de segurança, pacotes PHP próprios e processos de implementação. Desta forma, torna-se evidente quais os sistemas que se encontram na mesma versão e quais os casos especiais que devem ser tratados separadamente.

Em seguida, verifica as dependências por classe de servidor. Uma atualização de um produto principal pode ter consequências diferentes das de uma atualização de uma extensão ou de um componente de terceiros. Os pacotes fornecidos pelo sistema operativo também constituem uma área de manutenção distinta. O Plesk distingue explicitamente estas categorias; em particular, as atualizações de componentes de terceiros podem afetar os sites se estes não estiverem preparados para versões ou ambientes de execução alterados.

Em seguida, recomenda-se uma amostra representativa Instância piloto em vez de qualquer servidor de teste. Deve refletir configurações típicas de planos: por exemplo, sites clássicos com CMS, domínios de e-mail, utilização de bases de dados, bem como aplicações Node.js ou Python ativadas, caso estas sejam disponibilizadas. O objetivo não é simular uma igualdade total com o ambiente de produção, mas sim tornar visíveis antecipadamente combinações relevantes de sistema operativo, extensões e aplicações dos clientes.

Para a implementação em produção, define uma janela de manutenção com uma sequência clara. Começa por atualizar um grupo limitado de servidores, analisa os resultados e só depois alarga a implementação. Em seguida, verifique a acessibilidade do painel de controlo, as cópias de segurança programadas, os serviços Web e de e-mail, as renovações de certificados, bem como as mensagens de erro das aplicações afetadas. Estas verificações reduzem a incerteza, mas não constituem uma garantia de ausência de falhas ou de compatibilidade total das aplicações.

No que diz respeito ao planeamento de capacidade, a Plesk indica valores mínimos de 1 GB de RAM mais 1 GB de swap no Linux e 2 GB de RAM no Windows. Para o alojamento partilhado, a recomendação geral é de 1 GB de RAM por cada 40 a 50 sites, desde que, no máximo, 10% de todos os sites alojados registem um número constante ou regular de visitantes por semana ou por mês. Tais Valores de referência para recursos não constituem uma garantia de capacidade nem substituem a medição da própria carga: a atividade da base de dados, o volume de e-mails, o software de segurança e o tipo de aplicação podem alterar significativamente as necessidades.

Identificar fontes de erro e prioridades de segurança

Os erros recorrentes surgem, na maioria das vezes, devido a limites imprecisos dos produtos. Por isso, em cada anúncio, documenta a versão específica do produto principal ou da extensão. Uma função Node.js ou Python não deve ser promovida de forma genérica para planos Windows se estiver documentada apenas para o Plesk para Linux. Da mesma forma, a hospedagem Python com WSGI via Passenger não é sinónimo de compatibilidade com quaisquer arquiteturas ASGI, Worker ou de contentores.

• Só deve incluir o DNS-01 como característica da tarifa se houver acesso de escrita à zona DNS autoritativa ou se existir um caminho de automatização adequado.
• Não se deve equiparar as opções de atualizações automáticas do Plesk, de componentes de terceiros e de pacotes do sistema; verifique a configuração efetivamente definida para cada servidor em „Ferramentas e Definições > Definições de Atualização“.
• Verificar as extensões, as autorizações e os sistemas operativos antes de ativar novas funcionalidades em cada linha de produtos.
• Definir os grupos de utilizadores autorizados, os processos de aprovação e o registo de ações para o MCP antes da atribuição de funções.

O Prioridade de segurança não depende apenas da conveniência da janela de manutenção. À data de publicação deste artigo, o Plesk Obsidian 18.0.81 Update 2, de 29 de setembro de 2026, é a versão atualizada mais recente documentada desta linha de lançamento principal; A Plesk alerta para um problema de segurança crítico e recomenda a instalação imediata. A Atualização 1, de 21 de setembro, também incluía uma correção de segurança crítica, explicitamente referida no registo de alterações para o sistema Linux. Por conseguinte, nos sistemas Linux, não se deve ficar parado na Atualização 1.

O registo de alterações inclui ainda, em setembro, correções de segurança críticas para o Node.js Toolkit 2.5.0, de 14 de setembro de 2026, e para o Site Import 1.12.2, de 23 de setembro de 2026. Por isso, verifique sempre se o componente em questão está instalado e trate o núcleo do Painel, as extensões, os pacotes PHP e outros complementos como percursos de atualização separados. Uma atualização posterior de uma extensão ou do PHP não substitui uma atualização pendente do produto principal.

A MCP merece um Operação piloto em vez de uma ativação imediata e generalizada. A função está desativada por predefinição; os administradores podem, em panel.ini Definir quais os tipos de utilizadores que podem estabelecer ligação aos clientes MCP. Determine antecipadamente quais as tarefas que devem ser suportadas, quem pode verificar as alterações e como serão rastreadas as ações suspeitas ou indesejadas. Uma integração com IA não substitui nem os modelos de funções, nem a gestão da mudança, nem as revisões técnicas.

Aviso: os componentes de terceiros não devem ser instalados de forma descontrolada em todos os ambientes dos clientes apenas pelo facto de existir uma versão mais recente disponível. O Plesk alerta para possíveis incompatibilidades com os sites alojados; ao mesmo tempo, a página de documentação atual contém informações contraditórias sobre se a funcionalidade automática em questão está ativada por predefinição. Por isso, verifica, para cada servidor, em Tools & Settings > Update Settings as opções definidas e planeio uma implementação gradual para períodos de execução e plug-ins comuns, com um grupo-piloto representativo.

Decidir entre a atualização ou a transferência do servidor

A escolha entre Atualização no local e a transferência do servidor começa com o estado atual, não com a versão pretendida do Obsidian. Uma atualização no mesmo servidor pressupõe que o sistema operativo e a versão inicial do Plesk instalada sejam compatíveis com o procedimento previsto. Verifique também as extensões utilizadas, as personalizações próprias e o espaço disponível para cópias de segurança. O facto de um percurso de atualização ser tecnicamente viável não significa necessariamente que seja adequado para todos os ambientes dos clientes.

No que diz respeito ao Plesk Onyx, a documentação de atualização indica percursos diretos para o Obsidian para as versões 17.0, 17.5 e 17.8. Ambientes de origem mais antigos ou sem suporte adequado podem exigir uma transferência para um novo servidor Obsidian, desde que a versão de origem seja migrável. A transferência permite preparar o sistema operativo, a configuração dos recursos e o conjunto de extensões separadamente do sistema antigo.

É particularmente importante avaliar um novo servidor de destino quando o sistema operativo existente chega ao fim do suporte, quando a plataforma foi personalizada ao longo de um longo período de tempo ou quando se verificam várias atualizações de versão significativas. Os requisitos de sistema do Plesk fornecem apenas o limite mínimo para o planeamento. Para determinar a dimensão do servidor de destino, devem ser tidos em conta igualmente o número de sites, as caixas de correio, as bases de dados, os serviços de segurança, o espaço de armazenamento de cópias de segurança e a carga prevista após a migração.

Em Atualização por transferência O ambiente existente será transferido para um servidor com o Plesk Obsidian instalado. De acordo com a documentação de atualização, é necessário que o sistema operativo do servidor de destino seja compatível e que a versão inicial instalada permita a migração para o Obsidian. Por isso, antes do planeamento, deve verificar-se se esta opção está disponível, com base na versão de origem específica.

Para garantir uma instalação atualizada, compatível e fácil de gerir, a aplicação atempada de patches, após a realização de um inventário e de uma fase piloto, é, na maioria das vezes, a opção mais óbvia. No caso de novas extensões ou funcionalidades específicas do Linux, faz sentido realizar uma fase piloto específica. Se o suporte do sistema operativo, a versão inicial ou os problemas técnicos herdados do passado limitarem o caminho a seguir, deve-se, em primeiro lugar, realizar uma Preparação para a migração será. A variante adequada depende do estado do suporte, da compatibilidade e do modelo de funcionamento – e não de uma autorização genérica para entrada em produção.