MainWP is a management dashboard that lives on its own WordPress install

The two-plugin architecture and why it is split

The MainWP WordPress management system consists of two core plugins, and the README states that clearly. The MainWP Dashboard plugin is contained in this repository, and the second is the MainWP Child plugin, which lives in a separate repository. The split is the whole design and it is worth understanding before anything else. The Dashboard is a stand-alone plugin that is installed on its own WordPress site, and the README is explicit on two constraints: no other plugins should be installed with it, and it should not be installed on an active WordPress site with visitors. The Child plugin is the opposite end. It is the plugin you install on the WordPress sites you want to control from the MainWP Dashboard. So the control plane lives alone on its own installation, and the managed sites carry a lightweight agent. If you have ever wanted a dashboard plugin that quietly lives inside a production site with real traffic, this is not that, and the reasoning is about keeping the management surface away from the sites it manages.

What the dashboard is for

The project describes the MainWP Dashboard as an open source self-hosted WordPress management plugin that allows you to maintain virtually all aspects of multiple WordPress sites. The phrasing on self-hosted matters as much as the multi-site part. A hosted management service would have to hold credentials for every site you run and would be a single point of failure and a single point of compromise for your entire estate. Self-hosted means the dashboard is a WordPress site you control, on infrastructure you control, holding the credentials itself. The topics confirm the scope: mainwp, mainwp-dashboard-plugin, management-system, wordpress and wordpress-plugin. The repository is PHP, the licence is GPL-3.0 with LICENSE.md and LICENSE.txt at the root, the homepage is mainwp.com, and the last push was on 2026-10-13 with the current release at 6.3.

The repository layout, and what it tells you

The top-level entries describe a large, long-lived WordPress plugin. There is mainwp.php as the plugin entry point, a class directory, includes, modules, pages, templates, widgets, cron, languages, libs and assets, alongside a composer.json for the PHP dependencies and a phpcs.xml for coding standards. The test setup is visible too, with phpunit.xml.dist and a tests directory, and there is a bin directory for command line entry points. The separation of class, includes, modules, pages and templates is the WordPress plugin convention rather than anything MainWP-specific, but it tells you that this is a plugin with a conventional WordPress layout and a conventional test harness rather than a small utility. The presence of a cron directory is worth noting for anyone assessing it, since scheduled background work is where a management dashboard does much of its work, and the presence of a .coderabbit.yaml suggests automated code review runs on contributions.

Where to get help, and where not to file issues

The support section is unusually firm and the split between channels is clear. The repository is not suitable for support, and the README asks that the issue tracker not be used for support requests but only for core MainWP issues. Support requests in issues on this repository will be closed on sight. The channels offered instead are the Help Docs at docs.mainwp.com, the MainWP Community at community.mainwp.com, which is described as available to all MainWP users, and a support ticket through mainwp.com/support. For customisations, the README points to a list of MainWP Experts and to Codeable. There is a separate MainWP Community site linked in the Not a Developer section for those who are not developers at all. Documentation is split across three places, with the Help Documentation, the MainWP Codex at mainwp.dev, and the MainWP Dev Community for developers.

Reporting security issues and contributing

Security disclosure goes through HackerOne, with a submission link on mainwp's programme, and the README asks you to disclose security issues to the team that way rather than in a public issue. That is the arrangement you would expect from a plugin with credentials for many sites, and it is the reason a self-hosted dashboard is worth reviewing carefully when you first connect a site. Contributing is straightforward in principle: if you have a patch or have stumbled upon an issue with the MainWP plugin, you can contribute it back, and the README asks that you read the contributor guidelines first. The file it links sits in the .github directory of the repository, so the expectations are versioned alongside the code.

Where MainWP is the wrong choice

Three limits. The first is scale, and it runs in both directions. If you manage one or two WordPress sites, running a separate WordPress installation purely to manage them, plus a child plugin on each site, is more moving parts than the problem has, and updating plugins by hand on two sites is a reasonable afternoon's work. The second is the credential surface. A dashboard that maintains many sites necessarily holds the keys to all of them, and while the self-hosted model means you control where that credential store lives, it also means the compromise of that one WordPress install would expose every managed site. That is a single point of failure by design, and it is the trade the self-hosted model makes against a hosted service with its own security programme and multi-tenant isolation. Third, the README says almost nothing about what the dashboard actually does day to day. It tells you it maintains virtually all aspects of multiple WordPress sites, and it links to the documentation for the detail, so if you need to judge whether a specific operation, such as bulk plugin updates across a hundred sites or a staging workflow, is covered and how it behaves, that answer lives outside this repository. The repository tells you how the project is built and how to reach it, not what the product contains.

Editorial conclusion

Adopt MainWP if you run a fleet of WordPress sites and want updates, maintenance and oversight from one place on infrastructure you control. Skip it if you manage a single site, since a dedicated control plane is more machinery than that situation needs. Before you install, read the deployment note that the dashboard plugin belongs on its own WordPress site with no other plugins and no visitors, because that separation is the design, not a recommendation.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mainwp/mainwp on GitHub
3. Project website
4. README
5. Releases