Why WP Engine's disallowed plugins block some WordPress sites
Self-hosting WordPress on infrastructure you control removes the plugin restriction, and the trade-off is that caching, backups and patching become your team's work. A site that runs into a disallowed plugin, a platform cache layer that conflicts with its behavior, or a backup tool the host does not permit has a clear fix: run the same WordPress code on servers, a cloud account or a partner-managed environment where you choose the plugins. WordPress is released under GPLv2 or later, so the core, plugins and themes can run on any host that meets the WordPress license terms. The license settles whether you may move the code. The constraint you face settles whether moving is worth the operating load.
Start by identifying which limit blocks you. List every active plugin, mark those the site depends on for functionality, and check each against the host's current restriction list, which WP Engine publishes in its own documentation. Caching and backup plugins are the categories most often affected, so confirm which of your performance or recovery features depend on them. Then confirm the stack you would need: WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, as set out in its requirements page. Test each replacement plugin on a staging copy before cutover, and record which features behave differently. If the blocker is a single plugin, a targeted self-hosted setup may be enough. If it reflects a wider platform need, compare the scope with a partner's written quote.
The freedom to install any plugin comes with patching duties that the host previously carried. WordPress officially supports only its latest version, and its Security Team backports critical fixes to older versions as a courtesy, but plugin and theme updates are applied automatically only in special cases that the WordPress.org API determines. Sites created since WordPress 5.6 have automatic major release updates enabled by default, yet your team must still apply plugin updates, monitor advisories and keep backups current. Ask who owns each task, how quickly a critical vulnerability must be patched, and where backups are stored and restored. Those answers, not the plugin list alone, determine whether self-hosting fits your site.
What a site needs from its hosting platform
Whichever host runs a WordPress site, the same six needs apply: plugins, caching, backups, staging, patching, and the PHP and database versions underneath. A managed platform bundles these decisions for you. Self-hosting hands each one to your team, so you need to know what each requirement is before you choose a plan or a partner.
Plugin choice and caching plugins
Plugins are where many platform limits show up. Some managed hosts remove caching or backup plugins they judge to conflict with their own stack, so a site that depends on one of those plugins may not run there as configured. On your own server, you choose every plugin, but you own its compatibility with the rest of the stack. Check each plugin's update history and support status before you move, and test the caching plugin against your theme and checkout flows.
Server-level caching and CDN
A managed host usually provides page caching, object caching and a content delivery network at the platform level. When you self-host, you must configure these yourself: a web server or reverse proxy cache, an object cache such as Redis or Valkey, and a CDN in front of static assets. Ask who sets the cache rules, how purges are triggered after a content edit, and how cache behavior is tested for logged-in users and carts.
Backups and restore testing
A backup is only useful if a restore works. Your backup plan should cover both files and the database, run on a schedule, and keep copies outside the server that runs the site. Restore testing on a separate machine is the step most teams skip, so schedule it and record the time it takes. Confirm where backups are stored, how long they are kept, and who can restore them.
Staging environment
A staging copy lets you test core updates, plugin changes and theme edits before they reach visitors. Managed platforms often provide one, but on your own infrastructure it is a separate environment you must build and keep in sync with production, including its database and uploads. Decide how staging data is refreshed and how it is kept off search engines and out of live email delivery.
Security patching and automatic updates
WordPress only officially supports its latest version, but its Security Team backports critical fixes to older versions as a courtesy. Automatic background updates apply to WordPress core, and new sites have automatic major release updates enabled by default. Plugins and themes receive automatic updates only in special cases decided by the WordPress.org API. Plan who watches plugin advisories, who approves updates, and how a site is rolled back if an update breaks it.
PHP and database versions
WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater. A managed host sets these versions for you, while a self-hosted server stays on whatever you install. Confirm the PHP and database versions on your current host before migrating, match or exceed them on the new server, and check that every plugin you depend on supports them.
Where WP Engine limits apply and where self-hosting removes them
WP Engine restricts certain plugins it judges harmful to its platform, and the list can change over time. When a site depends on a plugin on that list, the limit blocks installation on the managed platform, so the team has to choose between a replacement and a different hosting arrangement. WordPress is released under the GPLv2 or later, which means the plugin code itself is not locked to any host. On a server you control, you decide which plugins run, when they update and which versions you pin. Your team also takes on the review of each plugin's code, its update history and its compatibility with the WordPress version you run, because no host filters that list for you.
- Installation scope: On your own server, any GPL-compatible plugin can be installed, subject only to your own change control.
- Version control: You choose when to update, which lets you test a plugin against staging before it reaches production.
- Review responsibility: Your team or partner assesses each plugin for security, abandonment and performance before deployment.
- Replacement planning: If a removed plugin is abandoned, you must find or build a substitute, which is a recurring engineering cost.
- Vendor confirmation: Ask WP Engine for its current plugin restrictions in writing, since the list is outside this page's sources.
Before migrating, export the site's active plugin list and confirm each entry's license, maintainer status and the WordPress versions it supports.
Managed hosts often run their own page caching, object caching and backup systems, and they may ask customers to avoid plugins that duplicate or conflict with those layers. When a team relies on a caching or backup plugin that is restricted on the platform, the limit blocks its use there and the team loses a familiar control. On self-hosted WordPress, the team decides which cache layers exist, where they sit and how they are invalidated. Backups also become the team's responsibility: you choose the schedule, the destination, the retention period and the restore procedure, and you can test restores on your own timetable rather than relying on a host's backup window.
- Page caching: You can configure a page cache on the web server, in PHP or at a reverse proxy, and tune its purge rules for your content model.
- Object caching: A Redis or Valkey instance can be added for object caching, with memory limits you set.
- Backup destinations: Backups can go to object storage or a second site, which keeps copies outside the primary server.
- Restore testing: You define how often a restore is tested and who signs off on the result.
- Operating work: Cache purges, backup monitoring and storage growth become tasks your team or partner must own.
Before you cut over, confirm which caching and backup features the current platform provides, then map each one to a self-hosted component and document the recovery point you need.
A custom integration may need access the managed platform does not offer, such as a background worker, a long-running cron job, a custom PHP extension, a message queue or outbound connections to a specific internal API. On a managed host, these needs can be blocked by the platform's runtime rules or require a support request. On your own infrastructure, you define the PHP version, extensions, system packages, network paths and process model. That flexibility applies to the integration code as well: your team must maintain the connection credentials, certificates, error handling and dependency updates that the platform previously managed.
- Runtime control: You select the PHP version within the range WordPress supports and install the extensions the integration requires.
- Network access: Firewall rules and egress paths can be set for each integration, including private network links to internal systems.
- Background processing: Queue workers and scheduled jobs can run as separate services rather than inside page requests.
- Secrets handling: Credentials must move to a secrets store or protected configuration, with rotation procedures written down.
- Dependency upkeep: Each library added to the integration becomes a patching obligation for the team that owns it.
Before migrating, list every integration, its network calls and its credentials, and check each one against the target environment with a staging test.
What plugin freedom costs in performance and security
The GPL lets you install any plugin you choose, but every plugin you install becomes your responsibility. WordPress is released under the GPLv2 or later, and the WordPress project treats plugins and themes as derivative works that must also be GPL. Nothing in that license asks a platform to vet what runs on your site. On a self-hosted install, the decision to add a caching, backup or security plugin sits with you, and so does the work of checking its code health, its update history and whether its author still maintains it before it reaches production.
Patching is the part teams most often underestimate. WordPress applies automatic background updates to the core software, and newly created sites have automatic major release updates enabled by default. Plugin and theme updates work differently: by default, WordPress only applies them automatically in special cases determined by the WordPress.org API, which the WordPress Security Team controls to patch critical vulnerabilities. Everything else waits for an administrator. Assign a named owner for plugin updates, define how quickly critical advisories are applied, and test updates in staging first. Confirm the update settings on your install in the WordPress advanced administration documentation before you rely on them.
The WordPress Security Team fixes responsibly disclosed vulnerabilities in bugfix releases and backports critical fixes to older versions as a courtesy, but only the latest version of WordPress is officially supported. Plan your core upgrade cadence around the current release line rather than around courtesy backports, and confirm the PHP and database versions your host runs against the WordPress requirements before each upgrade. Running a plugin that is abandoned or drifting from core is the kind of risk the upgrade path cannot fix on its own, so review plugin maintenance status as part of every release cycle.
Which open-source platforms keep WordPress or replace it
This table compares self-hosted WordPress, the container model used by WordPress VIP, Drupal and two rebuild-oriented CMSs. Read each row by asking whether your blocker is the plugin list itself or the platform that enforces it, since that determines whether you keep WordPress or change CMS.
| Option | How it removes the plugin limit | What it asks of your team | Main trade-off |
|---|---|---|---|
| Self-hosted WordPress (GPLv2 or later) | You install, update and remove any plugin, since WordPress code is GPL and runs on servers you control | Server, PHP and database operations, caching, backups, staging, WAF and patch testing | Full plugin freedom, but every plugin you add becomes your responsibility to keep patched |
| WordPress VIP container model | Runs the same WordPress code on Automattic-managed containers with a Git repository per application, so plugin choices are reviewed under VIP rules | Developer workflow built around the VIP repository, deployment pipeline and VIP-CLI tooling | Closer to managed hosting than self-hosting; confirm which plugins and tools VIP permits before you plan around them |
| Drupal (GPL version 2 or later) | Modules are GPL contributions from Drupal.org, and the GPL does not require sharing code used only to run a website | Drupal developers, a module review process and a planned upgrade path, with Drupal 11.4 and Drupal 12.0.0 scheduled per the core release schedule | Different content model and theming, so plugin-to-module mapping is a rebuild, not a copy |
| Payload (MIT) or Wagtail (BSD-3-Clause) | No plugin layer; features are code in your own application or Django project | Development team to rebuild templates, content models and editorial workflows | Suits teams rebuilding the site; not a drop-in for WordPress plugins |
| Plugin audit (any option) | Lists which disallowed plugins your site actually depends on before you choose a platform | Inventory of plugins, custom code and integrations, with owners for each | Skipping this step tends to move the same limits to a new platform |
How to run self-hosted WordPress without platform guardrails
This sequence turns a site that depended on WP Engine's platform controls into a self-hosted WordPress environment with a confirmed plugin list, supported runtime, caching, tested backups, staging, a patch policy and monitoring. Each step ends with a check the team can verify before cutover.
Confirm the plugin inventory and required plugins
Export the list of active plugins, themes and mu-plugins from the WP Engine environment, then mark each one as required, replaceable or unnecessary. Include any caching, backup or security plugin that WP Engine managed at the platform level, because those functions will need an owner after the move. Ask the site owner and developers to sign off on the list. The step is done when every item has a documented decision and a named owner, and no required function is left without a plan.
Select the PHP and database versions
Choose a runtime that meets the WordPress.org requirements: PHP 8.3 or greater, and MariaDB 10.11 or greater or MySQL 8.0 or greater. Check the plugin inventory against these versions, since some plugins may lag behind. Confirm the current support status of each version against the WordPress releases page and the requirements page before you build, because release status changes. The step is done when the stack is written down, every required plugin is confirmed to run on it, and the team has recorded the date it checked.
Set up the caching layer and CDN
Rebuild the caching that WP Engine provided at the platform level. Choose a page cache, an object cache for the database, and a CDN for static assets, and define which URLs and logged-in sessions must bypass the cache. Test cache purging on content updates and on checkout or form pages if the site has them. The step is done when a test edit appears on the public site within the expected cache window, logged-in users see uncached pages, and cache hit rates are visible in your monitoring.
Configure backups and prove restores
Set up scheduled full backups of files and the database, stored outside the web server and in a location with its own access controls. Keep the retention period your recovery and compliance policies require, and ask the site owner to confirm it. A backup has no value until it is restored, so restore the most recent copy into a separate environment and check that pages, media and user logins work. The step is done when a restore has succeeded end to end and the time it took is recorded.
Build a staging environment
Create a staging copy that matches production in PHP version, database version, plugins and cache configuration, with search engine indexing blocked and outbound email disabled. Use it to test core, plugin and theme updates before they reach production, and to rehearse the DNS cutover. Decide who can push from staging to production and how content created on production is handled during testing. The step is done when a change made in staging has been promoted to production through the documented process once without manual server edits.
Set the update policy for core and plugins
Write a policy that says which updates apply automatically and which need review. WordPress has automatic background updates, and newly created sites have automatic major release updates enabled by default, but the WordPress.org API controls which plugin and theme updates apply automatically, mostly for critical vulnerabilities. Decide how you will track the latest supported WordPress version, how quickly you will apply security releases, and who approves plugin updates. The step is done when the policy is written, configured on the server, and tested on staging.
Add monitoring and a patch cadence
Set up uptime checks, error logging, resource monitoring for CPU, memory and database connections, and alerts routed to a person who will act on them. Add file integrity checks and a log of admin logins and plugin changes. Schedule a recurring review of the patch cadence, the plugin inventory and the backup restore test, and assign each review an owner. The step is done when alerts have fired in a test, the on-call contact has acknowledged one, and the first scheduled review is on the calendar.
Evidence an auditor will ask for after leaving WP Engine
Once a WordPress site runs on infrastructure you control, every control your auditor tests becomes a record you must produce. The cards below cover the records that show what runs on the site, how it was patched, whether it can be restored, who can change it and how changes were made. DeployOpen prepares this evidence for your team, but independent auditors and certification bodies issue any audit report or attestation.
Plugin inventory with versions and sources
A dated list of every plugin and theme, its installed version, its source (wordpress.org, a commercial vendor or custom code) and its license. WP Engine previously restricted some plugins on its platform, so this inventory shows which ones you re-enabled or replaced after leaving. Check that each plugin has a named owner, that custom code sits in version control, and that any plugin without a maintained release is flagged for review. Use every component version must be recorded as the baseline for all other evidence.
Update and patch records
A log of WordPress core, plugin and theme updates with dates, versions applied and who approved them. WordPress applies automatic updates to plugins and themes only in special cases chosen by the WordPress.org API, so most plugin patches on a self-hosted site depend on your own process. Record the time between a vendor release and your deployment, and keep the staging test result for each change. Check the WordPress security page for the currently supported release line.
Backup logs and restore test results
Backup job logs showing schedule, completion status, size and storage location, paired with dated restore tests that rebuild the site on a separate server. A backup that has never been restored proves little to an auditor. Keep the database export and file archive versions, and record the time taken and any manual steps needed. Confirm that backups are stored away from the production server and that retention periods match your policy.
Access control and admin account records
An export of every WordPress administrator, editor and developer account, with the role, the date it was granted, the approver and the last login. Include SSH, SFTP, database and hosting control panel accounts, since those sit outside WordPress and were managed by WP Engine before. Show that shared credentials were removed, that multi-factor authentication is enforced for admin roles and that departed staff were removed on a dated ticket.
Change records for caching and DNS
Tickets and configuration history for the layers WP Engine used to run: the CDN, page and object caching, server rules, redirects and DNS records. Each change needs a before and after state, an approver and a rollback step. Auditors use these records to confirm that a site outage or a cache purge traces back to an authorized change. Keep DNS zone exports and certificate renewal logs with the same ticket references.
Questions buyers ask before self-hosting WordPress
Can our team run a self-hosted WordPress site on its own?
Often yes, if someone on the team already runs production web servers, databases and backups, and can own patching and monitoring every week. The work is not the initial install. It is the recurring duties: applying core and plugin updates, watching error logs, restoring from backup, handling traffic spikes and responding to incidents at night. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, so the stack must be kept on supported versions. Ask your team to list who covers each duty, including holidays. If that list has gaps, a partner can fill them under a written scope.
What drives the effort and ongoing cost of self-hosting WordPress?
Cost falls into one-time work and recurring work. One-time items include server or cloud setup, the CDN and caching layer that WP Engine's platform used to provide, backup design, staging and the migration itself. Recurring items include compute and storage that scale with traffic, backup retention, CDN usage, monitoring, update testing and the staff hours that run them. Costs rise with traffic volume, the number of plugins that need testing, and compliance logging requirements. Ask any quote to separate infrastructure, labor, and support retainers so you can compare them with your current plan fees line by line.
How long does a move off WP Engine take?
The timeline depends on site complexity, the number of plugins and integrations, how much custom code the theme contains, and how many environments must be rebuilt. The first step is taking a complete backup while the source site is still live, because WP Engine's backup retention and download windows are limited. Next come provisioning, restoring the database and files, rebuilding caching and the CDN, testing forms, redirects and integrations, and only then changing DNS. Staging and restore testing add time but reduce cutover risk. Request a fixed-scope timeline in writing that lists each milestone and the testing it includes.
Which WordPress plugins are safe to keep after leaving WP Engine?
Plugins that WP Engine disallowed for platform reasons are not automatically unsafe, and self-hosting lets you decide. Judge each plugin on three points: whether it is actively maintained, whether its code has a record of timely fixes, and whether it fits your caching, backup and security design. WordPress is GPLv2 or later and plugins are treated as derivative works that must also be GPL, so the license does not block use on your own servers. Build an inventory of active plugins, check each one against the WordPress.org security page process, and test them on staging before going live. Remove anything with no owner.
What does the work require from our internal staff?
Your staff needs to own decisions, not necessarily every task. Someone must approve plugin changes, hold the DNS and cutover decision, sign off on test results and set the business rules for downtime and backup retention. Engineers need Linux administration, web server and database skills, and familiarity with WordPress deployment practices. Editors need a short acceptance test plan for forms, content workflows and redirects. Identify these owners before the project starts, and ask the proposal to name the internal roles it expects you to fill and how many hours each role is likely to need.
Do we need a partner to handle WordPress security patching?
You do not need a partner for patching, but you need a named owner for it. WordPress applies automatic major release updates to sites created since WordPress 5.6, yet plugin and theme updates happen automatically only in special cases that the WordPress.org API controls to patch critical vulnerabilities. Everything else requires your team to review and apply updates. Only the latest WordPress version is officially supported, though the Security Team backports fixes to older versions as a courtesy. Self-hosting therefore means you are responsible for timely updates, vulnerability scanning and incident response. A partner can take on these duties under a retainer, with the scope and response expectations written down.
Which compliance evidence will we need to keep ourselves?
Self-hosting moves audit evidence to your side. You will need records of change control, patch history, access reviews, backup and restore test results, and logs for administrative actions. Those records support any assessment your regulator or customers require, but DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations. Before you start, ask your auditor which controls apply to a self-hosted CMS and confirm which evidence format they accept.
What should a written quote for self-hosting WordPress include?
A useful quote lists the scope in writing before work begins: environments to build, number of sites, plugins to review, caching and CDN design, backup and restore testing, staging, DNS cutover support and post-launch handover. It should separate one-time work from recurring support, name the deliverables and acceptance tests, and state what is excluded, such as custom theme development or content migration. Ask for the assumptions behind any timeline and the change process if scope grows. Most DeployOpen engagements are fixed-scope, so the written scope is the basis of the quote, and DeployOpen does not publish a price list.
Where to read next before you decide
Before you commit to moving, pick the sibling guide that answers the question you are stuck on. If you are still asking whether plugin limits justify leaving at all, start with the WP Engine vs self-hosted WordPress comparison. It sets out caching, backups, staging, security patching and support on each side, and it shows which of those duties move to your team or a partner once you host the site yourself. Read it with your list of blocked plugins in hand, and check each one against what your site actually depends on.
If the decision is made and you need the sequence, read the move from WP Engine to self-hosted WordPress guide. It covers the full backup ZIP and its download window, replacing platform caching and CDN, re-enabling or replacing plugins, setting up backups and staging, and switching DNS. If you want to know what the backup contains before you touch anything, go to the how to export your site from WP Engine guide, which explains the retention and download windows, the items that sit outside the ZIP (DNS, redirects and environment settings), and why restore testing matters. Confirm current retention and download windows with WP Engine directly, since those terms can change.
For the money question, the WP Engine cost vs self-hosted WordPress comparison breaks the bill into components: plan fees and traffic tiers on one side, and servers, CDN, backups, security monitoring, updates and staff time on the other. It also shows how visit-based pricing differs from infrastructure that scales with load. Use it to build a quote request for your own environment rather than comparing headline plan prices. Ask any hosting partner to price patching, monitoring and incident response as recurring line items, not as one-time setup.
How DeployOpen deploys self-hosted WordPress under platform constraints
DeployOpen plans, implements, hardens, backs up and documents self-hosted WordPress inside your own cloud accounts, data centers or air-gapped networks. We start by identifying which plugins and platform features your site depends on, then build the replacements and operating controls those needs require.
How we scope
- Inventory every plugin, theme, cache rule and backup dependency the current WP Engine site uses today
- Map each platform feature WP Engine provides to a self-hosted equivalent or a documented gap
- Agree scope, deliverables and timelines in writing before any work starts, as engagements are fixed-scope
How we build
- Set up hosting, page caching, CDN and database backups in your environment, with the PHP and MariaDB or MySQL versions your scope requires
- Configure staging and a tested deployment path so plugin changes are reviewed before reaching production
- Harden the WordPress installation, review each plugin for security and maintenance status, and test before cutover
How we hand over
- Document architecture, plugin inventory, update policy, backup schedule and restore steps for your team
- Run and record restore tests so your team sees that backups are recoverable before relying on them
- Provide a runbook covering patch responsibilities, including which updates are automatic and which your team approves
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover WordPress core and plugin updates, monitoring follow-up and security test cycles
- Ask any provider to confirm in writing who owns patching, incident response and backup verification
