Among people actually running Plesk today, the most commonly used free (or free-core) extensions cluster around SSL, WordPress, security, monitoring, and basic tooling.
Very commonly used free / freemium extensions
- Let’s Encrypt – Free DV certificates, auto‑renewal for domains and mail, basically mandatory on any modern Plesk install.
- WordPress Toolkit (Free) – Core management (install, clone, themes/plugins, some security hardening) is free; “Deluxe/Smart Updates” parts are paid.
- Fail2Ban (built‑in, plus free rules) – Brute‑force protection using jails and filters; not an extension you install separately, but widely used and often mentioned alongside “best free security extensions.”
- ModSecurity WAF with free rule sets – Atomic Basic, OWASP, and Comodo free rules; gives you a usable web app firewall without paid subscriptions.
- Grafana Extension – Dashboards and metrics visualization integrated with Plesk, popular among admins wanting better monitoring.
- Log Browser / File Manager / SSH Terminal extensions – Quality‑of‑life tools that are free in the catalog and very frequently installed on admin‑heavy servers.
- Docker extension – If the OS supports it, free to use and heavily used by dev‑oriented Plesk admins.
- Sitejet Builder (where available) – Freemium website builder; basic site creation is typically available without extra license, advanced features can be paid.
These won’t all be preinstalled, but in terms of “popular free stuff admins actually grab from the catalog,” Let’s Encrypt, WordPress Toolkit (free tier), Grafana, Docker, WAF/Fail2Ban tooling, and the various log/terminal utilities are consistently at the top of lists and forum mentions.
Power Pack, Developer Pack, and Hosting Pack are paid feature packs (not free), each bundling licenses for several extensions/features.
Are they free?
- Power Pack: paid add‑on; historically sold as an extra feature pack on top of your base Plesk license.
- Developer Pack: clearly marked as a paid “set of licenses for 4 extensions”.
- Hosting Pack: explicitly noted as a paid extension that also requires a Web Pro or Web Host Plesk license.
What each pack includes
Power Pack (for Onyx / Obsidian)
According to Plesk’s feature‑pack KB for recent versions:
- 10 sites of Web Presence Builder.
- PostgreSQL support (Linux).
- MSSQL support (Windows).
- Docker Remote Node Management.
- DNSSEC.
- WP Toolkit (on older Onyx/early Obsidian where it wasn’t bundled).
- SmarterMail Remote Control (Windows only).
Developer Pack
From the official Developer Pack extension page:
- Google PageSpeed Insights Pro (paid features unlocked).
- Docker Remote Node Management.
- PostgreSQL management module.
- MSSQL management module.
You buy the pack, then go to Extensions → My Purchases and install whichever of these you want.
Hosting Pack
From the Hosting Pack extension page:
- Plesk Premium Email (Kolab) – Family (5 users).
- Joomla! Toolkit.
- Google PageSpeed Insights Pro.
- ImunifyAV (licensed variant, not just the basic free scanner).
- Backup to Cloud Pro.
- Sophos Anti‑Virus for 5 mailboxes.
- Docker Remote Node Management.
Again, you buy the pack, then install the included extensions from My Purchases.
Quick comparison
So none of these three are free extensions; they are “bundle licenses” that unlock paid features/extensions under one pack license.
There’s no extra benefit for you in a Power Pack PostgreSQL add‑on now; PostgreSQL support is already included in modern Web Pro/Web Host editions, and Plesk ships native PostgreSQL integration out of the box.
What “PostgreSQL support” in Power/Developer Pack originally meant
- Historically (Plesk 12 / early Onyx / early Obsidian), the PostgreSQL Management Module was only available if you bought a feature pack (Power Pack or Developer Pack). It unlocked: creating PostgreSQL databases/users via GUI, phpPgAdmin integration, and managing remote/local PostgreSQL servers.
- That made sense when basic Plesk licenses only covered MySQL/MariaDB and treated PostgreSQL as an add‑on engine.
How it works now
- Current Obsidian builds on Linux support PostgreSQL directly; Plesk’s own KB lists supported versions and treats it as a standard database server type alongside MySQL/MariaDB.
- The edition controls whether PostgreSQL is available (Web Pro/Web Host: yes; Web Admin: no), not the old Power Pack license.
- In practice, if you already see PostgreSQL under Tools & Settings → Database Servers / Server Components and you can create PostgreSQL databases in subscriptions, you’re getting the functionality those packs were originally selling.
When a pack would still matter
- Only if:
- You are on an edition that doesn’t include PostgreSQL (e.g., a very restricted Web Admin variant) but the reseller somehow bundled a legacy pack, or
- You specifically want other stuff in the pack (Docker remote node, DNSSEC, PageSpeed Pro, Premium Email, etc.), not PostgreSQL itself.
So in your current setup (AlmaLinux 10.1, Obsidian 18.0.77, PostgreSQL already present), buying a pack for PostgreSQL alone would be redundant.
On the free tier of Speed Kit (Baqend) you mainly get performance analysis and basic acceleration for a limited amount of traffic/domains; the paid tiers lift those limits and add higher quotas.
What the free option gives you
- You can install the extension and connect at least one domain in “Free” mode directly from Plesk.
- You get the built‑in Page Speed Analyzer, which can run tests and show detailed metrics like Speed Index, First Meaningful Paint, TTFB, resources, response size, DOMContentLoaded, FullyLoaded, and Last Visual Change for your site.
- You can compare your site’s performance with vs. without Speed Kit via side‑by‑side video to see potential gains before paying.
- It will add the Service Worker / JS needed to accelerate traffic for that domain, but free plans include only a limited traffic quota; once you hit the included traffic limit, the extension UI explicitly shows a notice that the limit was reached and prompts you to upgrade.
What’s reserved for paid plans
- Higher‑tier plans in the selector (1 domain, 10 domains, 30 domains, all domains) are paid and mainly increase the number of domains and traffic allowance that can be accelerated.
- The catalog warns: “This paid extension is not licensed. Some or all functions and features of the extension may not be available. Purchase a license to unlock all functions and features,” which means certain automation or large‑scale acceleration features only unlock after you subscribe.
So, free is useful to: run real performance tests, experiment with Speed Kit on a low‑traffic site, and see measurable impact; for sustained acceleration on busy or multiple domains you’d need one of the paid Speed Kit plans.
Speed Kit sits in front of your existing stack and accelerates responses via a Service Worker + external cache, mainly helping with global latency and front‑end load time, not raw server horsepower.
What it actually does
- Injects a Service Worker on the site, which intercepts browser requests and serves them from a synchronized, globally distributed cache instead of hitting your origin every time.
- Keeps that cache in sync with your site, so many HTML and asset requests are answered from their edge/cache layer, reducing network round‑trips and TTFB seen by the browser.
- Provides a Page Speed Analyzer that runs full tests and gives detailed metrics (Speed Index, FMP, TTFB, DOMContentLoaded, FullyLoaded, etc.) and side‑by‑side “with vs without Speed Kit” video.
When it helps vs when it won’t
- Helps most if:
- Users are geographically far from your server,
- You have lots of static or semi‑static content, or
- Your app stack is slow to generate pages, so caching them at the edge hides backend latency.
- On a local or low‑latency audience with a very fast box (128 GB RAM, big cache, tuned PHP/DB), the bottleneck is often minimal; you may see marginal gains at best, especially if you already use good HTTP caching, CDN, and compression.
- It doesn’t magically make heavy front‑end JS cheaper or reduce payload size by itself; it mostly shortens the distance/time to deliver what you already generate.
Given your hardware and the kind of control you have, I’d treat Speed Kit as an optional experiment: run its free analyzer on one domain, compare the “with vs without” timings, and only pay if you see a meaningful improvement for real users in other regions.
ohh external cache, like cdn or clodflare that goes down a lot
Roughly, yes: it’s an external edge cache layer, conceptually similar to a CDN, but implemented via a Service Worker and Baqend’s own infrastructure instead of something like Cloudflare’s reverse proxy.
- Like a CDN, it caches responses closer to the user and serves them without always hitting your origin, which can reduce TTFB and perceived load time.
- Unlike a simple static CDN, it hooks into the browser with a Service Worker to intercept requests and decide when to serve from cache vs origin, but the core idea (outsourcing delivery to a third‑party network) is the same.
- That also means you inherit another external dependency: if their edge or control plane has issues, your site’s performance (or in worst cases, availability) can be impacted, just like with any CDN.
Tuxcare extension is basically a management layer for paid TuxCare ELS PHP; it helps you keep end‑of‑life PHP versions patched without upgrading the apps themselves.
What it does
- Detects all EoL PHP versions on your server (5.6, 7.0–7.4, 8.0, 8.1) and shows how many sites use each one.
- Installs TuxCare “Extended Lifecycle Support” PHP builds for those versions and registers them in Plesk as
X.Y.Z (Secured)handlers. - Lets you switch sites from old Plesk PHP to the secured TuxCare PHP with one click or via CLI, preserving PHP configuration and handlers, and allows rollback if needed.
- Supports bulk operations and scripted management via
plesk ext tuxcare-phpCLI commands.
The “Free” radio button only covers installing and using the extension itself; to actually run sites on secured ELS PHP you still need a TuxCare ELS PHP license key. If all your sites are already on supported PHP versions (e.g., 8.2+), this extension doesn’t buy you much.
Roughly: it replaces your old PHP builds with TuxCare’s own secured builds for those versions, not just stock GPL PHP with a tweak.
Under the hood, you’re still running PHP built from the open‑source codebase, but the important part is: TuxCare, not the original PHP project or your distro, keeps shipping updated RPMs/DEBs for that EoL branch; that ongoing maintenance is what you’re paying for.
TuxCare maintains independently patched PHP packages for EoL branches (5.6, 7.x, 8.0, 8.1), backporting security fixes that the upstream/GPL branch no longer receives.
The extension wires those TuxCare‑maintained packages into Plesk as additional PHP handlers (e.g., “7.4 (Secured)”), and lets you move sites onto them without changing code.
The extension itself (UI, detection, CLI) is free to install and use, but actually running sites on secured TuxCare PHP requires a paid TuxCare ELS PHP license key.
Free vs paid
- Free (no TuxCare license key):
- Paid (with TuxCare ELS PHP license):
- The extension can install TuxCare ELS PHP packages for those versions.
- You can use the “Install & Switch” actions to move sites from old Plesk PHP to the
X.Y.Z (Secured)TuxCare handlers, preserving settings. - You can bulk‑switch, roll back, and generally use the extension as a full migration/maintenance tool for EoL PHP.
So: free = analysis/visibility and the management shell; paid = actually serving traffic with TuxCare’s secured PHP builds.
$10/month is the price for activating TuxCare ELS PHP on this Plesk server, and it covers unlimited use of the secured PHP handlers (all supported EoL versions, any number of sites) on that box.
What you get for $10/month (per server)
- Ability to install TuxCare ELS PHP packages for all supported EoL PHP versions (5.6, 7.0–7.4, 8.0, 8.1) on this server.
- Plesk registers them as
X.Y.Z (Secured)handlers and you can switch any number of sites to those versions via the extension UI or CLI. - Ongoing security patches for those EoL branches from TuxCare, so all sites using those handlers keep getting fixes even though upstream PHP and the distro have stopped updating them.
- Management features: dashboard listing all EoL PHP versions and affected sites, one‑click Install & Switch, bulk operations, and rollback back to the original Plesk PHP if needed.
So the $10 is not “per site” but effectively per‑server for all ELS PHP use on that server; whether it’s worth it depends on how many legacy PHP sites you must keep online and how hard it is for you to upgrade them.
for the plesk premium antivirus extension, any user chatter on how good it is, and any cons, etc
Overall sentiment from admins is that Premium Antivirus for Servers (Dr.Web) is effective but pricey, with some operational quirks and a few stability bugs in past versions.
Positive feedback
- Considered a solid, well‑integrated mail antivirus for Plesk; several admins say it’s “highly recommended” if you specifically want strong mail AV and are okay with the cost.
- Based on Dr.Web, which has a decent reputation and is designed to be relatively lightweight on server resources compared to some alternatives.
- Tight integration with Plesk mail: scans incoming/outgoing mail, can clean/rename/quarantine, and is managed directly from the Plesk UI and Services Management.
Common complaints / cons
- Price: frequently called “expensive” vs ImunifyAV/Imunify360 or ClamAV‑based setups, especially when hosts offer both and Dr.Web is several times the monthly cost.
- Mail‑only focus: it’s primarily a mail antivirus; if you want broader malware scanning of web roots (WordPress shells, etc.), admins often pair it with ImunifyAV/360 or other tools, which increases total cost.
- Operational issues:
- Lock‑in / complexity: you must manage Dr.Web service, license key, and sometimes troubleshoot systemd service failures (
drwebd.service), which adds another moving part.
How it compares conceptually
- Versus ImunifyAV (free): Premium AV generally gives better mail‑focused protection but costs significantly more and doesn’t replace broader website malware scanning.
- Versus doing nothing: it’s a clear upgrade if you host lots of mailboxes and care about AV at the SMTP layer more than the license cost.
Given your use case and comfort level, it’s worth it only if you’re handling enough mail that high‑quality server‑side AV is critical; for mostly web‑only workloads, many admins prefer to spend on Imunify360/Web AV and keep mail simpler.