Plesk Obsidian Update: New Features for Hosting Providers

Clearly Separate Version Status and Components

The documented status as of October 2, 2026, is as follows for the Core Product Plesk Obsidian 18.0.81 Update 2. This update was released on September 29, 2026, and addresses a critical security issue. The new panel features described in this article are part of the Plesk Obsidian 18.0.81 release from September 15, 2026; Update 1 and Update 2, on the other hand, contain documented bug fixes and security fixes.

Later updates may still be available without changing the core version 18.0.81 Update 2: For example, the changelog lists updates for extensions such as SSL It! and Let’s Encrypt from September 29, as well as PHP package updates from September 30, 2026. Anyone who simply refers to a „current Plesk“ is therefore omitting information that is important for planning and support.

Plesk distinguishes between several levels of updates. Plesk packages consist of the control panel itself and its directly associated features. In addition, there are service packages and extensions provided by Plesk that offer additional capabilities or can integrate with external services. Therefore, a new version number for an extension does not necessarily mean that the Plesk core has also been updated—and vice versa.

In addition, each Hosting Panel Within an operating system, there are additional layers: operating system packages and third-party components, such as databases, PHP runtimes, web servers, and email services. Their package sources, support cycles, and dependencies do not necessarily follow Plesk’s release schedule. For a provider, this distinction is practically relevant because error patterns, maintenance windows, and responsibilities can vary depending on the component affected.

The inventory documentation should therefore always include the specific combination: Plesk version with update number, installed extension version, operating system, and relevant runtime packages. For certificate or application features, this also includes the integration used. This makes it possible to determine, for example, whether a change originated from SSL It!, a Let’s Encrypt integration, or the core panel. This prevents misunderstandings in customer announcements and simplifies troubleshooting for support.

How Plesk Updates Affect Providers

Within the Obsidian 18.0 branch, updates are released on an ongoing basis and sequential installed. Individual interim updates cannot be skipped. This creates a defined update path, but does not relieve a provider of the responsibility to test its own environment: The more customer websites, individual PHP dependencies, and extensions a server hosts, the more important it is to determine which changes affect which service class.

Plesk describes automatic updates for its own updates and separate options for bundled third-party components and system packages. However, the documentation page provides conflicting information regarding the default settings for the third-party components option. Administrators should therefore not assume a globally applicable default, but rather check the actual settings for each server under Tools & Settings > Update Settings Check. Special caution is advised because newer components may be incompatible with hosted websites.

For the operation of many customer instances, this distinction is an advantage when translated into processes. Panel updates and security changes can be planned based on their scope; component changes, on the other hand, undergo their own compatibility assessment. A managed hosting provider does not have to adopt every available package version immediately. The key factor is which versions are compatible with the agreed-upon stack, the tested customer base, and the intended support model.

The benefits of the latest Obsidian releases span several operational areas: diagnostic features can help structure first-level support, new application hosting tools expand pricing options, and certificate and assistance features address security and rights management. The article also covers earlier foundations and developments in the product line Plesk Obsidian 2025: Revolutionary innovations for web hosting However, for the current launch, the specific component is what matters—not just the product name.

Automation is therefore not a blanket approval decision. It makes sense to distinguish between the regular installation of documented Plesk updates and deliberately controlled changes to the customer stack. Especially on shared servers, this distinction prevents an unnoticed component change from simultaneously affecting many independent websites. It does not replace testing, but it makes risks visible and traceable.

New Features by Hosting Scenario

In shared hosting, one of the primary use cases is the faster identification of domain issues. The Plesk Obsidian 18.0.81 "Generally Available DNS Diagnostics" bundles checks for resolution, MX-related issues, DNSSEC, name servers, and domain expiration. The easy-to-read report in the dashboard can help support staff systematically investigate DNS, email, and delegation issues before they escalate.

However, the report is a Diagnosis and no automatic correction. In particular, domain aliases are not currently supported. Even if a finding indicates an incorrect delegation or zone, the resolution may be the responsibility of the registrar or an external DNS provider. As a support tool, this feature is therefore particularly useful when responsibilities and the next escalation step are clearly documented in the ticket.

A second area is Application Hosting For agencies and developers. Node.js Toolkit 2.5.0 adds a centralized overview of activated Node.js applications and one-click configuration of existing projects. Automatic detection can identify several popular server frameworks as well as static front ends. Additionally, the pnpm extension is supported exclusively on Plesk for Linux. This reduces the number of repetitive individual steps, but does not guarantee that every individual deployment can be adopted without modification.

The new Python extension 1.0.0 also supports Linux systems and provides Python support per domain, virtual environments, dependencies, environment variables, and encrypted secrets. Applications run as WSGI applications via Phusion Passenger; the „Python support management“ permission can be controlled via service plans and subscriptions. This can serve as a controlled pricing feature, but is not automatically a replacement for every Python architecture.

A third area covers certificates and assistance functions. In version 18.0.81, SSL It! supports DNS validation as an alternative to HTTP validation for the aforementioned ext-acme and ext-letsencrypt integrations. This is relevant, for example, for domains without an open port 80. A prerequisite remains the ability to set DNS records in the actual zone; simply viewing a record does not grant write access.

MCP is disabled by default in 18.0.81 and can be connected via a WebPros account. Administrators configure this in panel.ini the user types that are allowed to connect to MCP clients. Its suitability therefore depends not only on its functionality, but also on roles, permissions, and logging. Platform-specific extension features, external DNS management, and the architecture of the client application collectively determine which new features belong in which pricing plan.

Feature Comparison for Product Planning

For product planning purposes, the name “Plesk Obsidian” is not sufficient: The features relevant here come partly from the core product and partly from separately versioned extensions. Therefore, a provider should not evaluate features based solely on their usefulness, but should also include the operating system, licensing model, and technical dependencies in its pricing catalog.

The overview draws a particularly clear distinction between a platform feature and a marketable service offering. DNS diagnostics can be made widely available as a support tool. Python, on the other hand, belongs only in Linux offerings whose licensing and support limits are designed to accommodate it. For Node.js, the provider must distinguish between the respective sub-features: pnpm is documented as Linux-exclusive, while the changelog does not impose corresponding restrictions on the central overview and auto-configuration.

The certificate and MCP functions also require a product-specific decision rather than global activation. With DNS-01, responsibility for the zone determines its practical usability. With MCP, the technical connection is only one part of the process; the key factors are the authorized user group, traceable workflows, and the handling of actions with side effects.

DNS Diagnostics and Certificates in Support

The version of Plesk Obsidian 18.0.81 that is generally available DNA Diagnosis It serves as an initial technical assessment of a domain ticket. In the panel, „Troubleshoot DNS“ opens a clear report on DNS resolution, MX-related checks, DNSSEC, nameserver issues, and the domain’s expiration date. This streamlines the preliminary check but does not replace either the analysis of the authoritative zone or coordination with the registrar or an external DNS provider.

To ensure a repeatable first-level process, support should first record the affected main domain and the report, then assign responsibility and determine the severity. If, for example, the report indicates an incorrect delegation, the correction is often beyond the panel’s scope. It is also important to note the documented limitation: domain aliases are not currently covered by this check.

For command-line diagnostics, the changelog documents the following command with a neutral example domain. Before use, an administrator should review the help or command documentation for the actual version of Plesk that is installed. The syntax provided in the changelog alone does not offer any further guarantee regarding all the effects of the command.

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

Expanded for certificates DNS-01 Validation Possible use case: In Plesk Obsidian 18.0.81, you can use SSL It! as an alternative to HTTP validation for issuing and renewing certificates. This is relevant, for example, for API or email domains where port 80 is intentionally not open. Plesk displays the required DNS records and saves the selected method for each domain for future renewals.

However, the process does not automatically succeed simply because a record is displayed. The administrator needs write access to the actual relevant DNS zone or a properly configured automation workflow. According to the changelog, the DNS validation introduced in version 18.0.81 applies only to the ext-acme and ext-letsencrypt integrations of SSL It!, not universally to every certificate provider.

Separate from that is the later expansion update SSL It! 1.24.0 as of September 29, 2026. With this version, a domain without hosting can be secured with a wildcard certificate via the control panel or the command line; automatic renewal also occurs as a wildcard certificate. This addition is not part of the original feature set of Plesk Obsidian 18.0.81 but follows the extension’s own versioning and release schedule.

Application Hosting as a Managed Pricing Option

With the latest extensions, application hosting can now be more clearly distinguished as a pricing option. The Node.js Toolkit 2.5.0 adds a central overview of activated Node.js applications and one-click configuration of existing projects. In addition, the extension supports the pnpm package manager in Plesk for Linux. This allows a provider to standardize recurring setup tasks without having to treat each customer application as an individual server instance.

According to the changelog, project detection includes Express, Next.js, NestJS, and Nuxt.js, as well as static frontends based on React, Vue.js, Angular, or Vite. Plesk can create a Passenger-compatible startup file, account for hard-coded ports, and set the document root, with the changes displayed before confirmation. Static frontends are built and served without a permanently running Node.js process.

This automation is helpful, but it is no substitute for an architecture review. Multiple processes, worker queues, specialized reverse proxies, external secrets, or custom build pipelines may require additional operational rules. According to the changelog, the Linux restriction applies explicitly to pnpm; no corresponding platform restriction is listed there for the central domain overview and the one-click auto-configuration. Plan descriptions should therefore list these sub-features separately.

The Python extension 1.0.0 introduces a separately manageable offering per domain on Linux. Customers can create virtual environments, install dependencies via the interface, view metadata from pyproject.toml, and manage environment variables and encrypted secrets. Access is granted via the „Python support management“ permission in service plans and subscriptions.

Technically, these applications run as WSGI Applications via Phusion Passenger; Plesk automatically generates the web server configuration. A „Python Web App“ plan may, for example, include virtual environments, a defined resource allocation, and support for classic WSGI projects. However, this does not mean that the same plan covers complex ASGI stacks, persistently running workers, or specialized containerized architectures.

To understand the context of older features and interface changes, see the article Plesk Obsidian: An Overview of New Features and Improvements may be used as a supplement. For new rates, it remains essential to jointly document the extended version, documented platform limits, permissions, and the specific types of applications supported.

Roll out updates to production in stages

In a hosting provider environment, an update to the hosting panel should not begin the first time you click on the production main server. First, create a Inventory Plesk versions, operating system versions, enabled extensions, and the customer applications running on them. External dependencies—such as DNS providers, mail relays, backups, custom PHP packages, and deployment workflows—are also important. This makes it clear which systems share the same status and which special cases require separate handling.

Next, check the dependencies for each server class. An update to a core product may have different implications than an update to an extension or a third-party component. Packages provided by the operating system also remain a separate area of maintenance. Plesk explicitly separates these categories; updates to third-party components, in particular, can affect websites if they are not prepared for changed versions or runtime environments.

Next, we recommend a representative Pilot instance instead of just any test server. It should reflect typical service plan configurations: for example, classic CMS websites, email domains, database usage, and activated Node.js or Python applications, if these are offered. The purpose is not to simulate complete parity with the production environment, but rather to highlight relevant combinations of operating systems, extensions, and customer applications in advance.

For the production rollout, define a maintenance window with a clear sequence of steps. First, update a limited group of servers, evaluate the results, and only then expand the rollout. Afterward, check control panel accessibility, scheduled backups, web and email services, certificate renewals, and error messages from the affected applications. These checks reduce uncertainty but do not guarantee freedom from outages or complete application compatibility.

For capacity planning, Plesk specifies minimum requirements of 1 GB of RAM plus 1 GB of swap space on Linux and 2 GB of RAM on Windows. For shared hosting, a rough guideline is 1 GB of RAM for every 40 to 50 websites, provided that no more than 10 percent of all hosted websites have a consistent or regular number of visitors per week or month. Such Resource Guidelines These figures do not guarantee capacity and are not a substitute for measuring your own load: database activity, email volume, security software, and the type of application can significantly affect your needs.

Identifying Sources of Error and Safety Priorities

Recurring errors are usually caused by vague product boundaries. Therefore, document the specific core product or extension version for each announcement. A Node.js or Python feature must not be advertised broadly for Windows plans if it is documented only for Plesk for Linux. Similarly, Python hosting with WSGI via Passenger does not imply support for arbitrary ASGI, worker, or container architectures.

• Do not include DNS-01 as a plan feature until write access to the authoritative DNS zone or a suitable automation path is available.
• Do not assume that the options for automatic Plesk, third-party component, and system package updates are the same; check the actual settings for each server under „Tools & Settings > Update Settings.“.
• Check extensions, permissions, and operating systems before enabling new features for each product line.
• For MCP, define the user groups, approval workflows, and action logging that are permitted prior to role approval.

The Safety Priority is not determined solely by the convenience of the maintenance window. As of the date of this article, Plesk Obsidian 18.0.81 Update 2, released on September 29, 2026, is the current documented patch status for this core release line; Plesk has highlighted a critical security issue and recommends prompt installation. Update 1, released on September 21, also contained a critical security fix that is explicitly listed in the changelog for Linux. Therefore, Linux systems should not remain at Update 1.

The changelog also lists critical security fixes for Node.js Toolkit 2.5.0 (released September 14, 2026) and Site Import 1.12.2 (released September 23, 2026). Therefore, always check whether the affected component is installed, and treat the Panel core, extensions, PHP packages, and other add-ons as separate patching paths. A later extension or PHP version does not replace a pending core product update.

MCP earns a limited Pilot Operation instead of immediate, widespread activation. The feature is disabled by default; administrators can, in panel.ini Specify which user types are allowed to connect to MCP clients. Determine in advance which tasks should be supported, who is authorized to review changes, and how suspicious or unwanted actions will be tracked. An AI integration does not replace role models, change management, or technical reviews.

Warning: Third-party components should not be deployed unchecked across all customer environments simply because a newer version is available. Plesk warns of potential incompatibilities with hosted websites; at the same time, the current documentation page contains conflicting information regarding whether the corresponding automatic update feature is enabled by default. Therefore, check the following for each server under Tools & Settings > Update Settings the selected options and plan a phased rollout for common runtimes and plugins with a representative pilot group.

Decide Between an Upgrade or a Server Transfer

The choice between In-Place Upgrade and the server migration begins with the current state, not with the desired Obsidian version. Upgrading on the same server requires that the operating system and the initial version of Plesk installed be supported for the intended migration path. Also check the extensions in use, any customizations you’ve made, and the available space for backups. Just because an update path is technically possible doesn’t mean it’s suitable for every customer environment.

For Plesk Onyx, the upgrade documentation provides direct paths to Obsidian for versions 17.0, 17.5, and 17.8. Older or unsupported source environments may require a transfer to a new Obsidian server, provided that the source version is migratable. This transfer allows you to prepare the operating system, resource layout, and extensions separately from the old system.

A new target server is particularly worth considering if the existing operating system is reaching the end of its support life, the platform has been customized over a long period of time, or there are several major version jumps involved. Plesk’s system requirements provide only the minimum threshold for planning. Factors to consider when determining the target size include the number of websites, mailboxes, databases, security services, backup retention, and the expected load after migration.

At Upgrade via Transfer The existing environment will be migrated to a server with Plesk Obsidian installed. According to the upgrade documentation, the target server’s operating system must be supported, and the installed source version must allow migration to Obsidian. Therefore, before planning, you should check whether this approach is available based on the specific source version.

To ensure an up-to-date, supported, and manageable installation, prompt patching based on an inventory and pilot testing is usually the most logical approach. For new extensions or Linux-specific features, a targeted pilot phase is advisable. If operating system support, the initial version, or legacy technical issues limit the approach, a Preparing for Migration . Which option is appropriate depends on support status, compatibility, and operating model—not on a blanket production release.