How Govard provisions a Magento environment

Part 1 of the Govard deep-dive series — the container stack and how Govard reproduces it on every machine.

Why a reproducible stack beats a hand-built one

When three engineers each install Magento locally, they rarely end up with the same machine. One is on PHP 8.1, another on 8.3, and the person who set up the database two years ago has long forgotten which MariaDB version it runs. A bug that "only happens in staging" is usually the first symptom of that drift — the local stack simply is not the stack you deploy to.

Govard removes the guesswork by treating the environment as data. You describe the stack once, in configuration, and every machine renders the same containers, the same PHP build, and the same service versions. Onboarding stops being a two-hour ritual of "install this, then this, then hope." The environment becomes something you reproduce, not something you rebuild from memory.

What govard env up actually stands up

At the core is a small, opinionated stack. Govard provisions a PHP-FPM container (version chosen from your config), a MariaDB container for relational data, a Redis container for cache and sessions, and an Elasticsearch or OpenSearch container when the search backend needs one.

# .govard.yml (base layer)
framework: magento2
php:
  version: "8.3"
services:
  database: mariadb:11.4
  cache: redis:7
  search: opensearch:2

The PHP version is not auto-detected from the host — it is pinned in configuration (and enforced by govard lock), so a teammate on PHP 8.1 cannot silently run the project on 8.1. When the project requires a different build — say a Magento version that only supports 8.2 — you change one line and every environment follows. See the configuration reference for the full key set.

Config lives in layers. .govard.yml is the base; profile files such as .govard.review.yml merge on top for heavier setups, and GOVARD_ENV can override a value for a one-off run. You can always inspect the resolved result:

govard config profile      # print the effective, merged configuration
govard env ps              # show which containers actually came up

Govard also keeps your working tree clean through a git worktree model: each environment maps to an isolated checkout, so bringing up a second stack never touches the files of the first. That isolation is what makes the per-branch workflows in the next post possible.

Pitfalls

• PHP version drifts from production. If prod runs 8.2 and your config says 8.3, you will ship code that fails only after deploy. Pin the version and lock it.
• Stale volumes outlive the containers. govard env down stops containers but can leave database volumes behind; re-running up may mount old data. Use the volume-clean flag when you truly want a fresh start.
• Forgetting to tear down. Spinning up stacks and never stopping them burns disk and port ranges; make govard env down part of your end-of-day habit.

Next in this series: Parallel Govard environments for every branch — /blog/govard-parallel-environments