Running Magento 2 locally with Govard

Magento 2 is one of the most capable — and most demanding — e-commerce platforms to run locally. A realistic store is not a single PHP process; it is a constellation of services, each with its own version, config, and failure modes. This post walks through how Govard collapses that entire setup into a handful of commands, and how the same tooling keeps upgrades and QA reproducible across every machine on your team.

If you haven't installed it yet, start from the installation guide and the getting-started walkthrough, then come back here for the Magento-specific workflow.

Why Magento 2 local dev is painful

A production-grade Magento 2 stack needs far more than PHP-FPM:

• Multiple services. Elasticsearch or OpenSearch for catalog search, Redis for session and cache, RabbitMQ for message queues, Varnish or a similar reverse proxy for full-page caching, and a database server. Each one must be installed, version-pinned to what your Magento version supports, and kept running.
• Heavy setup steps. composer install, bin/magento setup:install, setup:upgrade, setup:di:compile, and setup:static-content:deploy — and then you wait while each phase churns through the codebase.
• Sample data. Demonstrating features or reproducing bugs usually needs magento2-sample-data, which adds another long install pass on top of an already slow build.
• MFTF / Selenium. The Magento Functional Testing Framework spins up a Selenium grid plus a browser container, a second web server, and a dedicated test database. Wiring that by hand is a project in itself, and keeping the browser version aligned with your Magento version is fiddly.

The result is a developer laptop full of half-documented Docker Compose files and "works on my machine" drift. Govard treats all of this as a single declarative environment instead of a pile of manual steps. See the architecture overview for how it models environments, services, and framework detection so you never hard-code a stack by hand.

One command to a working store

With Govard, the entire stack comes up from one command:

govard env up

govard env up (aliased as govard up) reads your project's configuration and provisions the supporting services Govard knows Magento 2 needs: Elasticsearch/OpenSearch, RabbitMQ, Varnish, and Redis, plus the web and database containers. You don't pin image versions in five different places — Govard resolves versions that are compatible with your detected Magento release, which removes a whole class of "Elasticsearch 8 vs Magento 2.4" mismatch bugs.

Tip: run govard doctor after a fresh setup to confirm every service is reachable and version-compatible before you start clicking through the storefront.

Once it's up, the usual lifecycle commands apply:

govard env ps       # list running services
govard env logs     # tail container logs
govard env restart  # restart a single or all services
govard env down     # tear the environment down

For the full list of environment and service commands, see the CLI command reference. When you're iterating on a shared branch, the lock workflow pins the environment so teammates get an identical setup instead of a subtly different one.

Upgrade pipeline

Magento upgrades are where small mistakes turn into long afternoons. Govard wraps the standard sequence into a single reproducible command:

govard upgrade

Under the hood govard upgrade runs the steps you'd otherwise do by hand, in the correct order: composer require/update for the new Magento and extension versions, bin/magento setup:upgrade, setup:di:compile, setup:static-content:deploy, and — when your project uses it — the sample-data refresh. Because the pipeline is fixed, an upgrade that works on one developer's machine works on everyone's, and it's trivial to re-run after a failed step without guessing which phases already completed.

You can still inspect progress and recover mid-upgrade with the standard database helpers if a migration needs a manual nudge:

govard db top     # show long-running queries during an upgrade
govard db dump    # snapshot the DB before a risky step
govard db import  # restore that snapshot if the upgrade goes sideways

The configuration reference explains how profile layers let you keep a shared base config and overlay environment-specific values without forking the whole file.

Pull prod DB without the pain

The fastest way to reproduce a production bug is to run against production data — safely, on your laptop. Govard connects to a remote (staging or production) through a named remote and syncs only what you ask for:

govard remote add staging \
  --host staging.example.com \
  --user deploy \
  --path /var/www/html \
  --capabilities files,media,db

govard remote test staging
govard remote sync --plan          # preview what will be pulled
govard remote sync --capabilities db

--capabilities db pulls the database and remaps it into your local environment, so you get real orders, customers, and configuration without copying media you don't need. The remotes & sync workflow explains how capabilities scope a sync (files, media, db) and how govard remote sync --plan lets you dry-run before touching anything.

Warning: always run govard remote sync --plan first. It shows exactly which datasets will move, so you never accidentally overwrite local work with a remote snapshot.

Running MFTF / QA in-container

Functional testing is where Govard earns its keep. Instead of assembling a Selenium grid by hand, Govard runs the Magento Functional Testing Framework inside the same environment:

govard test

govard test launches the test web server, the Selenium/browser container, and a dedicated test database, then runs PHPUnit, PHPStan, and MFTF against them. Your CI and your laptop run the identical harness, so a test that passes locally doesn't surprise you in the pipeline.

For debugging a failing test, the environment ships an Xdebug-capable PHP service — enable it with the XDEBUG_SESSION cookie or the php-debug service toggle, and your IDE attaches to the in-container process as if it were local. No port-forwarding guesswork, no second PHP install.

When a test reveals a performance problem rather than a correctness one, the audit workflow captures profiling data from the running environment so you can see exactly where time goes before you change a line of code.

Next in this series: Laravel, Symfony & WordPress on Govard — /blog/govard-laravel