Moodle plugin development with moodle-docker vs Lando: which environment integrates cleanly with an existing codebase and CI pipeline?

Direct Answer

moodle-docker integrates more cleanly with a plugin-only repository and CI pipeline. It is the officially maintained stack, pins Moodle/PHP/PostgreSQL versions declaratively via git tags and image digests, and the Moodle project's own CI tooling (including moodle-plugin-ci) is built around it. Lando's community Moodle recipe assumes a full Moodle codebase as the app root, so a plugin-only repo requires extra bootstrap scripting that erodes Lando's convenience advantage.

Both tools can achieve identical local/CI runs if you pin image digests (not just tags) and destroy database volumes on teardown. moodle-docker makes this more straightforward because the entire environment — Moodle core checkout, PHP image, database image — is described in version-controlled compose files and env files.

Why moodle-docker Fits Plugin-Only Repos Better

Directory Layout

moodle-docker expects a full Moodle checkout mounted at /var/www/html. A plugin-only repo does not need restructuring: in CI you clone a pinned Moodle tag (e.g., MOODLE_405_STABLE), then symlink or copy your plugin into mod/, local/, etc. Locally, developers can keep the Moodle checkout outside the plugin repo and mount the plugin directory via a compose override. No rearrangement of your existing plugin repository is required.

Lando's .lando.yml recipes typically set the app root to the Moodle codebase. To use a plugin-only repo you must script a Moodle core fetch and plugin placement step before lando start, which adds maintenance burden and diverges from the recipe's defaults.

Declarative Version Pinning

For guaranteed identical runs, pin by image digest (e.g., moodlehq/moodle-php-apache@sha256:…) in a CI-specific compose override. Tags can drift; digests cannot.

CI Reproducibility: PHPUnit and Behat

The Moodle project's moodle-plugin-ci GitHub Actions workflows demonstrate the standard pattern:

1. Check out pinned Moodle tag.
2. Install plugin into the checkout.
3. Start moodle-docker containers (bin/moodle-docker-compose up -d).
4. Run php admin/tool/phpunit/cli/init.php and php admin/tool/behat/cli/init.php inside the web container.
5. Execute test suites.
6. Teardown with bin/moodle-docker-compose down -v (the -v flag removes named volumes, preventing state leakage).

This runs non-interactively on any clean runner. Lando can script the same steps, but you maintain the bootstrap logic yourself.

config.php Templating

moodle-docker ships a config.docker-template.php that reads from environment variables (DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASS, WWWROOT, etc.). In CI you provide a .env.ci file (committed or generated) with the compose service names and credentials. Locally, developers use a .env.local with host ports if needed. No hand-editing of config.php is required.

Lando injects its own environment variables (LANDO_INFO, service-specific vars) which you must map into a Moodle-compatible config.php — typically via a custom script or template.

Xdebug in CI

Do not map Xdebug ports in CI. Interactive step debugging requires a fixed host port and an IDE listener — neither exists in a headless runner. Instead:

• Enable Xdebug only for coverage via an environment variable (e.g., ENABLE_XDEBUG=1) that adds zend_extension=xdebug and xdebug.mode=coverage to the PHP ini.
• Keep the interactive debugging profile (xdebug.mode=debug, xdebug.client_host=host.docker.internal, xdebug.client_port=9003) in a local-only compose override.

moodle-docker's PHP images include Xdebug; toggling it via env is documented in the repo's README.md and bin/moodle-docker-compose helper.

Verification Steps Before Committing

1. Clone the current moodlehq/moodle-docker repo and confirm the supported env vars, PHP image tags, and config.docker-template.php match your target Moodle 4.x branch (e.g., MOODLE_405_STABLE).
2. Run one CI job that: checks out the pinned Moodle tag, installs your plugin, starts containers, initializes PHPUnit/Behat, runs a smoke test, and tears down with down -v. Confirm it passes on a clean runner.
3. Diff the generated config.php, PHP version (php -v), and PostgreSQL version (psql --version) between a local run and the CI run to confirm parity.
4. Check the maintenance status of the Lando Moodle recipe (GitHub stars, recent commits, Moodle version matrix) before shortlisting it.

One Diagnostic Detail

Does your CI runner provide host.docker.internal (or equivalent) for local Xdebug connections, or do you need a fixed host IP? This only matters for the local debugging override; it does not affect the CI recommendation.