Introducing Govard — a Go-native local development orchestrator

The local-dev pain point

Every PHP or web project eventually grows a pile of environment glue. You clone a repository, then spend the next hour reconstructing the world it expects: a matching PHP version, the right database, the correct web server, Redis or a search engine, a cron daemon, maybe a message queue. If you are lucky, someone wrote a Dockerfile and a docker-compose.yml that mostly works on their machine. If you are less lucky, the setup lives only in a teammate's head, or in a wiki page that drifts from reality the moment a dependency bumps a major version.

The usual escape hatch is a shared compose file. But compose files are static: they encode one opinion about versions and topology, and they do not know anything about your framework. When you switch from a Magento 2 store to a Laravel API, you start from scratch. Worse, the environment definition lives outside your project's source control in ways that are easy to forget, so new contributors still lose an afternoon to "works on my machine."

This is the problem Govard is built to remove. Instead of you describing the environment imperatively, Govard inspects the project and assembles a working local stack from a small, declarative configuration. You stay focused on code; the orchestrator handles the runtime.

What Govard is

Govard is a Go-native local development orchestrator for PHP and web projects. "Go-native" matters here: the binary is a single compiled executable with no runtime to install, no interpreter to match, and no container daemon it depends on beyond the one you already use. That makes it fast to start, easy to distribute, and trivial to pin across a team.

At its core, Govard detects the framework your project uses — Magento 2, Laravel, Symfony, WordPress, and others — and maps it onto the services that framework actually needs. You express intent in a thin config file; Govard resolves the effective configuration, provisions the containers, wires networking and volumes, and hands you a running environment. The architecture is built around a framework-agnostic engine plus per-framework definitions, so adding a new stack means adding a definition, not forking the core.

Operationally the mental model is small. govard env up brings the stack online, govard env ps shows what is running, govard env logs tails output, and govard env down tears it down. Those four commands cover the daily loop. Underneath, Govard is using Docker for isolation — but the Dockerfile writing, the service linking, and the framework-specific bootstrapping are all handled for you. You get containers without authoring compose spaghetti.

Key advantages at a glance

A few properties make Govard worth adopting on a team:

• One command to a running stack. govard env up goes from a clean checkout to a live environment. No copy-paste of environment variables, no README scavenger hunt.
• Framework-aware, not framework-locked. Detection drives behavior. The same tool brings up a Magento store and a Laravel API with the right services for each, and the engine stays neutral so new frameworks slot in cleanly.
• Declarative and version-controllable. Your environment is a config file in the repo, so it is reviewed, diffed, and pinned like any other source. Drift between machines becomes a diff you can read.
• Fast feedback loops. Built-in commands run your test suite (govard test), inspect database activity (govard db top), and import or dump data (govard db import, govard db dump) without leaving the orchestrator's vocabulary.
• Remotes and sync. Govard can talk to remote environments — staging, a colleague's box, or a cloud dev instance — to plan and replay file, media, and database synchronization (remotes & sync). That turns "let me copy my DB over" from a manual risk into a repeatable command.
• Reproducible for everyone. Because the binary is a single Go executable and the config is in the repo, onboarding a new contributor is install + env up.

For the full command surface, the CLI reference documents every subcommand, flag, and exit behavior.

Tip: run govard doctor after your first env up. It checks that the host prerequisites — Docker, the binary, and project detection — are all healthy before you start debugging application code.

Install in one line

Govard ships as a single compiled binary, so installation is a download and a PATH entry rather than a package-manager adventure. The recommended path is the installer script:

curl -fsSL https://raw.githubusercontent.com/ddtcorex/govard/master/install.sh | bash

The script places the govard executable on your machine and verifies it is reachable. Once it finishes, confirm the install:

govard version

You should see the installed version printed back. From there, the typical first run in a project directory is:

govard env up
govard doctor

env up provisions and starts the stack; doctor confirms the runtime is sound. If you ever need to refresh the binary itself, govard self-update pulls the latest release in place. Full instructions — including manual install and shell completion — live in the installation guide.

Note: Govard drives Docker under the hood, so the Docker daemon must be running on your machine before env up can provision anything.

What's next in this series

This post introduced Govard's purpose and the one-line install. The next entry goes hands-on with the environment lifecycle — what actually happens when you run govard env up, how the pipeline assembles services, and how to read govard env ps / govard env logs to debug a stubborn container.

Next in this series: Govard env up pipeline — /blog/govard-env-up-pipeline