Plesk Obsidian 18.0.80 is an operations release worth treating as a planned change, not a quick panel refresh. The release introduces WebPros Dashboard management for Model Context Protocol (MCP) servers, updates DNSSEC defaults and supported algorithms, and adds a newer TLS policy profile. It also puts a sharper deadline on older Debian 11 servers: Plesk says 18.0.81 will be the last release supporting that operating system.
This checklist keeps the work at the decision and validation level. It is designed for a hosting administrator who needs to preserve working sites, WordPress services, DNS, mail, and customer access while moving the platform forward.
What to confirm before the maintenance window
Start with a short inventory that identifies the server operating system, the Plesk release family, the hosted subscriptions that need a direct smoke test, the DNS role, and the services that depend on the panel. Include WordPress sites, email, scheduled work, SSL renewals, external DNS, and any integrations that use the panel as a control plane.
Choose a maintenance owner, define the expected user-visible impact, and document the normal acceptance path before making the change. Routine publishing or panel maintenance does not require creating a new full-account archive; use the organization’s existing, documented recovery coverage and confirm that the intended recovery owner can reach it.
For a broader WordPress service baseline, keep the WordPress support hub nearby. If the server uses WP Toolkit, the Plesk WP Toolkit installation guide is a useful reminder of the application-level checks that belong after panel work.
Review MCP access as a governance change
Plesk 18.0.80 introduces management of MCP servers through WebPros Dashboard. The release notes describe scoped access, per-tool controls, read-only and read-write choices, and activity logging. Treat this as an access-governance decision rather than something to enable merely because it is available.
- Keep ownership with the administrator responsible for the affected subscriptions and panel services.
- Start with the narrowest approved scope and read-only use where that meets the operational need.
- Review which tools are actually necessary, who can authorize a change, and how activity will be reviewed.
- Do not expose customer administration or tenant-wide authority to an integration that only needs a limited task.
The practical goal is simple: any newly connected service should have an accountable owner, a constrained role, and a review trail before it is trusted with production administration.
Check DNSSEC without assuming existing zones changed
The 18.0.80 release notes say that Plesk removed deprecated or insecure DNSSEC algorithms and changed default signing algorithms for new configuration paths. That is a cue to inspect DNSSEC deliberately, not proof that an existing signed zone has been rewritten.
- List the zones that are signed and record where their DS information is managed.
- Confirm the resolver-visible state for representative signed zones after the panel update.
- Review the algorithm and key policy for future zones or a planned key rollover with the DNS owner.
- Record any exception where an external DNS provider, registrar, or customer process owns part of the chain.
Use the Plesk DNSSEC signing checklist for the separate operational review. Keep DNS validation separate from web-page availability; a site can appear reachable through a cache while an authoritative DNS change is still not settled.
Validate the TLS policy against real client needs
Plesk 18.0.80 adds a Mozilla 5.8-based TLS and cipher policy option, with a screen-based profile selected by default. Review that policy as part of the change plan, especially when a server has legacy application clients, mail clients, or embedded integrations.
Before adopting a stricter policy, identify the public hostnames and application paths that must remain compatible. After the update, test a representative secure website, the certificate presentation, the expected mail or service path, and the customer-facing login route. Keep an exception register only where there is a documented business requirement and a retirement plan.
Make Debian 11 a migration project, not a last-minute update
Plesk’s release notes state that Debian 11 reaches end of life on August 31, 2026, and that Plesk Obsidian 18.0.81 will be the final Plesk release to support it. A panel update does not extend the operating system support window.
- Identify every Debian 11 Plesk server and the subscriptions it carries.
- Choose the owner and target state: an operating system upgrade where supported, or a migration to a prepared server.
- Schedule a test of the customer-critical services before the production move.
- Give customers a clear maintenance notice that names the expected impact and validation window.
For WordPress installations, include the sites, PHP compatibility, scheduled tasks, email delivery, and admin access in the acceptance plan. If a customer needs a content-level recovery runbook, link them to the Plesk Backup Manager guide rather than treating migration as an untested emergency procedure.
Run an acceptance pass after the upgrade
Finish with a small, repeatable acceptance pass. Check the Plesk administrator view, a normal subscription login, the public web path, expected HTTPS behavior, representative DNS, WordPress administration, mail where applicable, and the scheduled work that supports the hosted application. Confirm that new MCP capabilities remain limited to the approved scope, or stay disabled until their operational owner is ready.
For earlier Plesk hardening context, see the Plesk Obsidian security maintenance guide. It covers a different release line, so keep its security checks separate from the 18.0.80 access, DNS, TLS, and Debian 11 decisions described here.
Where these changes come from
This checklist is based on the official Plesk Obsidian change log for 18.0.80 and the current Debian 11 support notice. Verify the release notes for your operating system and installed Plesk extensions before scheduling production work.