Self-hosted service
pH7Software/pH7-Social-Dating-CMS avatar
pH7Software/pH7-Social-Dating-CMS

pH7Builder: a self-hosted PHP dating CMS you install from a ZIP

Self-hosted, open-source PHP 8.2+ software for building white-label dating sites, matchmaking communities, and social networks. Own your code, hosting, database, and member data.

1,056 stars608 forksPHPMIT

At a glance

What is it?
pH7Builder (formerly pH7CMS) is an MIT-licensed PHP 8.2+ application for running a white-label dating or social site on your own server. The judgement: it is a real deployment target for operators who want to own member data, but the hosting requirements and the MySQL 8.0-only support boundary are the first things to verify.
Who is it for?
Adopt pH7Builder if you already run PHP 8.2+ and MySQL 8.0 on infrastructure you control, and you want member profiles, messaging, paid plans, and moderation queues without renting a SaaS dating platform. Do not adopt it if your stack is MariaDB, if you cannot run URL rewriting and HTTPS, or if you expect a managed service to patch and scale the site for you.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 3 days ago.
What is it written in?
Mainly PHP, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem pH7Builder addresses: renting vs owning a dating platform

Most dating products start on a hosted platform where the operator pays a subscription and the vendor holds the member table. pH7Builder takes the opposite position. The README describes it as "a self-hosted alternative to rented SaaS platforms" where the deployer keeps "control of the application, database, files, and member data." That is the whole pitch, and it defines the audience: an operator with a niche (a regional matchmaking community, a members-only social network, a white-label dating brand) who can run a LAMP-style stack and would rather pay a host than a platform vendor. The MIT license means there is no required public "Powered by" link; the README notes only that the license notice stays with copies or substantial portions of the software. The trade is explicit: you get the code and the data, and in exchange you own the patching, the mail deliverability, the TLS certificate, and the database backups. Nothing in the repository suggests a hosted control plane that does any of that for you.

Modules, pH7Framework, and PH7Tpl: how the application is put together

The README describes "a modular MVC application built on the project-specific pH7Framework and PH7Tpl template engine." That single sentence explains most of the operational behaviour. Features are modules: the README states plainly that "features depend on the modules you enable and the external services you configure," so two installs of the same release can expose very different surfaces. A site with the forums, blogs, and video modules off is a smaller application with fewer routes to secure and fewer tables to back up. The template engine is project-specific rather than a general PHP template library, which matters if you plan to hand the theme layer to a designer who knows Twig or Blade; they will be learning PH7Tpl instead. The framework is likewise in-house, so extending the application means reading this project's conventions rather than reaching for a widely documented framework's ecosystem. The feature list groups into discovery and matching (search, behavioural matchmaking, nearby people, Hot or Not, profile ratings), publishing and conversation (private mail, instant messaging, chat, comments, forums, blogs, photo albums, videos, newsletters), business tools (membership groups, paid plans, advertisements, affiliates, payment integrations, CSV user import), and trust and moderation (approval queues, abuse reports, blocking, country restrictions, login-attempt protection, registration throttling, duplicate-content checks, optional image screening, two-factor authentication, optional SMS verification). A REST API module and PWA support are listed under platform and reach. Treat that list as a map of what can be switched on, not as a claim about what a default install turns on.

Installing from the release ZIP, and the Docker path for evaluation

The README gives two routes. For production it says to use "the ready-to-run ZIP attached to a tagged release, set only the required writable paths, configure the web server, and then open /_install/." The versioned ZIP includes locked production dependencies, so Composer 2 is only needed for a source checkout; the README also notes that a source install needs outbound Internet access. The browser installer is not a formality: it "checks the runtime, extensions, writable paths, MySQL version, and database connection before importing the schema." The README's own estimate is 20 to 30 minutes for deployment plus the guided installer, with DNS, TLS issuance, and mail-provider approval excluded. For local evaluation there is a Docker Compose path: clone the repository, run docker compose up --build -d, then docker compose exec php _install/create-install-token.php, copy the one-time token, and open http://localhost:8080. The installer expects database host db, database ph7builder, username ph7builder, password ph7builder, port 3306. One caveat is stated directly: the checkout is snapshotted into a Docker volume, so testing changed source requires docker compose down -v before rebuilding, and that "permanently deletes the local application and database volumes." Mail configuration is environment-based: the README says SMTP credentials are supplied as PH7_MAILER_DSN through the server environment and that "the application does not store SMTP credentials in its admin form." That is a sensible design decision and also a deployment step people miss.

The requirements list is the real admission gate

PHP 8.2 or newer, with a long extension list: curl, dom, exif, fileinfo, GD with FreeType and WebP, hash, iconv, json, mbstring, openssl, pdo_mysql, simplexml, xmlwriter, xml, zip, zlib. That is broader than a default PHP build on many shared hosts, and GD with FreeType and WebP in particular is the kind of thing that is compiled out on cheap plans. MySQL 8.0 or newer with utf8mb4 is required, and the README is blunt about the boundary: "Older MySQL releases and MariaDB are not verified or supported for this release." For a large share of self-hosted PHP operators, MariaDB is the default database on their VPS image or control panel, which means the install path runs through a MySQL 8.0 migration or a different host before you get to the installer at all. The web server needs Apache with URL rewriting or nginx with equivalent routing and protected path rules; the second half of that phrase is doing quiet work, because a rewrite rule that routes clean URLs but leaves configuration, storage, or upload directories reachable is a different problem from one that does not. HTTPS is required for production, and PWA support is described as available "when served over HTTPS." FFmpeg is needed only if locally uploaded video processing is enabled. Read the list before you pick a host, not after.

Where pH7Builder is the wrong tool

The most concrete failure mode is the database. If your infrastructure is MariaDB, the README does not support you for this release, and the installer's MySQL version check will decide the question before you have written any configuration. The second is operational scope. This is a CMS with paid plans, payment-gateway integrations, an affiliate programme, advertisements, and a REST API module, all of which expand the attack surface an operator has to keep patched. The README points to a Launch Checklist and says to "test the exact production configuration" before accepting real users or payments; that instruction implies the project does not consider a stock install production-ready without operator work. Mail is a third: the application does not store SMTP credentials in the admin form, so deliverability depends on PH7_MAILER_DSN being set correctly in the environment and on a mail provider that has approved you, which the README explicitly places outside its 20 to 30 minute estimate. Finally, if you want someone else to handle uptime, scaling, and security patches, this is the wrong category of product. The README's own framing is ownership, and ownership is a workload.

What you would use instead, and the difference in approach

The obvious alternative is a hosted dating SaaS, where you configure a branded site in a browser and the vendor runs the servers, the database, and the upgrades. The difference is not features; it is where the member table lives and who is on call when the site is down. A second alternative is assembling a general-purpose CMS plus plugins for profiles, messaging, and payments. That route gives you a larger ecosystem of themes and extensions and a wider hiring pool, but you would be wiring matchmaking, approval queues, moderation, and membership groups yourself, and the result is a bespoke codebase rather than a product with a documented upgrade path. pH7Builder's position between those two is specific: it ships the dating and community mechanics as modules, and it asks you to run the stack. The README also names its own lineage ("Formerly pH7CMS"), which matters for anyone evaluating older tutorials or forks, since documentation written for pH7CMS may not describe the 18.x or 19.x branches accurately.

Upgrades, licensing, and what the release history tells you

The default branch is 18.x while the newest releases are v19.0.1, v19.0.0 (dated 2026-08-28), and v18.6.2. That is a real maintenance consideration: if you track the default branch, you are not tracking the tagged releases, and the repository ships a separate Upgrade Guide under docs/UPGRADING.md for a reason. The release notes for v19.0.1 describe "Form and autocomplete fixes," which suggests a steady cadence of small corrections rather than long-stable drops, and the v19.0.0 and v18.6.2 titles carry a marketing word that tells you nothing about the code. Budget upgrade time as a recurring cost, and read UPGRADING.md before moving between major versions rather than after. On licensing: the project is MIT, which is permissive and permits commercial use and modification. This is not legal advice, and the only licence obligation the README highlights is that the notice remains with copies or substantial portions of the software. If you rebrand and redistribute, read LICENSE.md yourself. Note also that the README references translated interface packs and multiple themes; the licence status of third-party themes and language packs is a separate question the README does not answer, and you should confirm it before shipping a commercial site built on them.

Editorial conclusion

Adopt pH7Builder if you already run PHP 8.2+ and MySQL 8.0 on infrastructure you control, and you want member profiles, messaging, paid plans, and moderation queues without renting a SaaS dating platform. Do not adopt it if your stack is MariaDB, if you cannot run URL rewriting and HTTPS, or if you expect a managed service to patch and scale the site for you. Before importing the schema, confirm the MySQL version reports 8.0 or newer, that the PHP extension list in the README is complete on your host, and that PH7_MAILER_DSN is set in the server environment rather than typed into the admin form.

Official sources

  1. License: MIT
  2. pH7Software/pH7-Social-Dating-CMS on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes