phpMyFAQ is a database-driven FAQ platform that runs anywhere PHP does

A knowledge base for organisations that answer the same questions

phpMyFAQ is described as a multilingual, AI-ready and scalable FAQ platform built for modern knowledge management, and the composition of the sentence tells you what the emphasis is.

It is powered by PHP 8.4 or later and a fully database-driven architecture, and it delivers fast search with Elasticsearch or OpenSearch, flexible multi-user permissions, and a content management system with revision history and WYSIWYG editing.

The supporting feature list is what separates it from a small FAQ script. There are 40+ languages, responsive Twig-based templates, a REST API, 2FA security, enterprise authentication through LDAP, Active Directory and Entra ID, and a built-in plugin system. The README also says it deploys on traditional hosting or runs in the cloud via Docker.

Two words in the description deserve a second look. The first is AI-ready, which the repository backs up with an MCP server in its topic list and MCP in the package keywords, though the README itself does not spell out what that means in practice, so the details are in the documentation rather than in the front page. The second is permissions, because a FAQ system for a support organisation is really a content system with a reading surface attached, and who may edit, review, publish and answer is where the work is.

That last point is the real reason to pick this over a wiki page. Revision history and a review workflow are what turn a list of answers into something a support team can rely on.

PHP 8.4 and six database engines

The requirements section is short, and one line in it will decide whether you can run this at all.

phpMyFAQ requires PHP 8.4 or higher and a supported database system. The supported databases are MySQL, MariaDB, Percona Server, PostgreSQL, Microsoft SQL Server and SQLite3. That is an unusually wide list for an application of this kind, and it means the migration story from an existing MySQL estate is usually the easy one, while SQLite3 is there for the smallest deployment.

Search is the optional extra. For enhanced search capabilities using Elasticsearch or OpenSearch, Elasticsearch 8.x or later, or OpenSearch 2.x or later, is required. The distinction matters: the platform runs without a search engine, but the fast search it advertises comes from one, and that turns a simple PHP application into a stack with a JVM in it.

The README points to phpmyfaq.de/requirements for a complete and up-to-date list of system requirements, which is the right instinct for a project with this many moving parts, because the version matrix of PHP extensions, search engine and database is not something you want to infer from a README.

One detail from the Dockerfile explains the requirement list. The image installs the PHP extensions gd, intl, ldap, mysqli, pdo_mysql, zip, opcache, bz2 and sodium, alongside the system libraries they need. intl for the 40+ languages, ldap for the directory integration, pdo_mysql and the MySQL drivers for the database, sodium for cryptography. That extension list is the practical shape of the requirements.

The end-user install is a browser wizard

For someone who just wants a FAQ on their website, the recommended path is the shortest one in the project.

The best way to install phpMyFAQ is to download the package from phpmyfaq.de/download, unzip it, and open http://www.example.org/phpmyfaq/setup/ in a browser. That is the whole procedure, and the setup route is a web installer rather than a command line.

The deployment documentation for that path points at docs/deployment.md in the repository, and the production images are published to the GitHub Container Registry as ghcr.io/thorsten/phpmyfaq:<version> for Apache and ghcr.io/thorsten/phpmyfaq:<version>-frankenphp for the FrankenPHP variant, with docker-compose.prod.yml and .env.production.example to run them alongside MariaDB or PostgreSQL and an optional search engine.

So there are two routes, and they serve different needs. The zip and wizard is for a traditional host where you have a web root and a database and nothing else. The container route is for a platform team that wants the application and its dependencies described in one file.

The Dockerfile in the repository is explicitly not the production image. It only builds an environment to run any release for development purpose, and it does not contain any code, because the phpmyfaq folder is meant to be mounted as the /var/www/html folder in the container. That is a deliberate and unusual design, and it is what lets the same image serve several versions of the application.

The development stack is profile-gated, and a helper hides the flags

The docker-compose.yml in the repository is for development, and every service sits behind a Compose profile, so you pick exactly the combination you need: one web server plus the databases and search engines you want to test against. A bare docker compose up now starts nothing, because no service is in the default profile.

The helper that makes this bearable is bin/dev. It maps friendly names to profiles and adds guardrails: it refuses to start two web servers on the same port, auto-adds Redis, generates self-signed dev TLS certificates, and installs dependencies on first run. The documented invocations are:

    $ bin/dev up nginx mariadb opensearch         # exactly these (Redis added automatically)
    $ bin/dev preset default                      # nginx + mariadb + opensearch + redis
    $ bin/dev preset full                         # one web server + every backing service
    $ bin/dev down                                # stop and remove the running stack

The same commands are available through pnpm as dev:up, dev:down, dev:default and dev:full, and bin/dev help, bin/dev presets and bin/dev profiles list the full set.

The services themselves are grouped by profile. The web servers are nginx served through a php-fpm container, apache, and frankenphp with HTTP/3 support, and each binds :443 with PHP 8.5 support. The databases are mariadb, postgres and sqlserver, the latter running the Azure SQL Edge image natively on Apple Silicon and x86. The search engines are elasticsearch and opensearch, both without XPack installed. Redis is the cache, and phpmyadmin and pgadmin are the admin tools, along with a build profile that runs composer for the PHP dependencies and pnpm for the TypeScript dependencies and the asset build.

Once the stack is up, phpMyFAQ is at https://localhost:443 with http://localhost:8080 as a fallback, phpMyAdmin at http://localhost:8000 and pgAdmin at http://localhost:8008.

Elasticsearch wants a kernel setting you have to apply twice

The section quoted from the Elasticsearch documentation is short and it is the kind of thing that blocks a first deployment.

The vm.max_map_count kernel setting needs to be set to at least 262144 for production use. On Linux, the setting should be set permanently in /etc/sysctl.conf, so the documented check is a grep for the current value followed by the value itself, and to apply it on a live system you type sysctl -w with the same value.

On macOS and Windows with Docker Desktop, the containers run inside a managed Linux VM, so the setting has to be applied inside that VM, which the README gives as a docker run of an alpine image with nsenter and the sysctl call. And the last line of that section is the one to remember: this change is not persistent and must be reapplied after restarting Docker Desktop.

For a developer running the search stack locally, that means every Docker Desktop restart produces a search engine that will not start until you run the command again. It is a small thing, but it is the kind that gets reported as a bug in the project rather than in the environment.

The same care shows up in the rest of the compose file, where every database and cache service has a healthcheck with an interval, a timeout, a retry count and a start period, and the data directories are mounted under ./volumes so a stack can be recreated without losing state.

Building from source and the test story in the Dockerfile

To run phpMyFAQ locally from the repository, you need at least a running web server with PHP support and a database. The documented sequence is:

    $ git clone git://github.com/thorsten/phpMyFAQ.git
    $ cd phpMyFAQ
    $ git checkout main
    $ curl -s https://getcomposer.org/installer | php
    $ php composer.phar install
    $ curl -fsSL https://get.pnpm.io/install.sh | sh -
    $ pnpm install
    $ pnpm build

The two package managers are not optional extras. Composer installs the PHP side, and pnpm installs the TypeScript dependencies and builds the assets, which the compose file describes as a separate build profile run once through bin/dev build.

The Dockerfile in the repository shows the testing path, and it is unusually opinionated about it. The image uses a php:8.4-cli base image and does not have any phpMyFAQ code with it, because it is for testing only. It has two stages, one that installs the Composer dependencies with the PHP extensions and one that repeats the extension installation in a clean runtime stage, then copies the vendor directory and the application code in. The final line runs PHPUnit by default: CMD points at ./phpmyfaq/src/libs/bin/phpunit, with a version check earlier in the build to confirm the binary works.

The README gives the command to use it, which builds the image and runs it:

    $ docker build -t phpmyfaq-test . && docker run --rm -it docker.io/library/phpmyfaq-test:latest 

Around that, the front end toolchain in package.json is a modern one: Vite for the asset build, Vitest for unit tests, Playwright for end to end tests with its own config file, oxlint and oxfmt for linting and formatting, stylelint for the SCSS, tsc for type checking, mkdocs for the documentation with a strict build, husky and commitlint for the commit hooks, plus semgrep, rector and mago configuration for static analysis.

Maintenance, licence and where phpMyFAQ fits

The licence is MPL-2.0, the file-level copyleft licence, which is a sensible choice for a self-hosted application that organisations modify and then host themselves.

The release picture shows a project that ships continuously. The recent releases are nightly builds, 4.1-nightly-2026-10-20, development-nightly-2026-10-20 and 4.1-nightly-2026-10-19, while the package version in package.json is 4.2.0-beta.3, and the last push was on 2026-10-20 with the repository not archived. Nightly tags on a stable version line, plus a beta on the next one, is a project with an active release pipeline rather than an occasional one.

The scope limits are the interesting part for an evaluation. phpMyFAQ answers questions. It is not a ticketing system, not a helpdesk, and not a documentation site generator, and the AI-ready framing is currently backed in the repository by an MCP server topic and keyword rather than by a described feature set. If your need is a knowledge base for a product with a hundred articles, you are looking at the wrong category of software; if your need is a support organisation answering the same forty questions, this is aimed at you.

The operational weight is the other limit. A minimal deployment is a PHP application, a database and a web server, and that is genuinely small. A deployment with the advertised search runs Elasticsearch or OpenSearch next to it, and that is a different piece of infrastructure with its own kernel tuning, its own JVM and its own operational habits.

The repository layout shows the seriousness of the engineering around the application: a .semgrep directory, a .husky directory, a .stylelintrc.json, a rector.php, a mago.toml with lint and analysis baselines, a STATIC_ANALYSIS_DEBT_REDUCTION.md file, a SECURITY.md, a kubernetes-deploy directory, and a docs directory with mkdocs configuration.

Editorial conclusion

phpMyFAQ suits a support organisation or a product team that has the same questions asked over and over, and that wants to answer them from its own server with its own permissions model rather than through a hosted service. It is the wrong choice for a site that needs three pages, and for a hosting environment stuck on an older PHP. Verify first that your platform can run PHP 8.4 or later, decide which database and whether you really want to run Elasticsearch or OpenSearch alongside it, and read the setup wizard path in the download package before you plan a deployment, because that is the shortest route to a working instance and the Docker stack is the one that takes real preparation.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. thorsten/phpMyFAQ on GitHub