Customizing Govard: adding services and overrides

Part 4 of the Govard deep-dive series — extending the environment without breaking the base.

Why extend instead of rebuilding

A throwaway local stack is only useful if it matches the project you are actually shipping. Govard gives you a working Magento, but real stores need extras: a queue, a second datastore, a specific PHP extension, or config that differs from the Govard default. The temptation is to hand-edit the running container — but those edits vanish on the next govard env down and never reach a teammate. The discipline is to express customizations as version-controlled overrides layered over Govard.

Where overrides live

Govard reads project-level overrides on top of its own defaults, so your additions survive rebuilds and travel with the repo:

# .govard/overrides/services.yaml (example shape)
services:
  queue:
    image: redis:7-alpine
    ports:
      - "6379:6379"
  php:
    extensions:
      - pcov
      - rdKafka

The key idea is layering: Govard's base defines the standard stack; your override file adds or amends only what the project needs. You are not maintaining a fork, just a small, reviewable delta.

Adding a service

Add the container definition to your override file, expose the port, and reference it from Magento's env the same way you would in production. Because the override is committed, every developer who runs govard env up gets the queue automatically — no "works on my machine" gap.

Overriding config

PHP settings, environment variables, and Magento config can be injected through the same override layer:

php:
  ini:
    opcache.memory_consumption: "256"
    memory_limit: "2G"
env:
  MAGENTO_CRON_DISABLED: "0"

Keep overrides minimal. If a value is the same as Govard's default, do not restate it — the smaller the delta, the easier it is to upgrade Govard later.

Pitfalls

• Editing the live container. Changes made with docker exec are gone on rebuild and invisible to teammates. Put it in the override file.
• Uncommitted local overrides. If the override stays only on your machine, CI and other devs diverge. Commit it.
• Service port clashes. Two projects both mapping 6379 collide; namespace ports per project.
• Overriding too much. A large delta is a fork in disguise and makes Govard upgrades painful.

What's next

The overrides are version-controlled, which means they can also drive automation. The final post shows Govard running inside CI to test real code before merge.

Next in this series: Pre-merge testing with Govard in CI — /blog/govard-ci-premerge