Sync & deploy safely with Govard remotes

Most local development work is only half the story. The other half is getting your code, media, and database to and from the servers that already run your project — staging where the client reviews, production where real traffic lives, or a teammate's machine where the tricky bug reproduces. Govard treats those servers as remotes: first-class connection targets you register once and then sync against with the same single-binary simplicity you get from govard env up.

This post walks through what a remote is, how to register and classify one, how to plan a sync before it touches anything, and the two workflow details that save teams from the most common sync mistakes.

What a remote is

A remote is a named connection to another environment that runs (or hosts) your project. Unlike a generic SSH alias, a Govard remote carries capabilities — the things it is allowed to do on your behalf. Govard models three:

• files — pull and push the codebase, config, and generated assets.
• media — sync the upload directory (product images, CMS attachments, user files) that lives outside version control.
• db — dump and import the database so local and remote share the same data shape.

Declaring capabilities matters because a remote is never all-powerful by default. A read-only backup host might get db only; a staging box you deploy to gets files and media; production typically gets the narrowest set you can live with. Govard also tracks connection profiles for each remote — the SSH host, user, path, and transport details — so the same remote name means the same target whether you run the command from your laptop or from CI.

Register & classify

Adding a remote is one command. You name it, point it at the host, and declare what it can do:

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

The moment the remote is registered, Govard runs an auto-ping to confirm the host is reachable and the path exists. If the connection fails, you find out now rather than mid-sync. On a healthy connection Govard also performs light capability inference: it inspects the target (is there a media directory? a running database the deploy user can reach?) and warns you when the capabilities you declared don't match what the remote can actually offer. That surfaces a typo'd db claim before you depend on it.

You can verify a remote at any time without moving data:

govard remote test staging

Once a remote is classified, every later sync respects its declared capabilities. You cannot accidentally push files to a remote that was only ever granted db, and you cannot wipe a database on a remote that was only granted media. Classification is the guardrail, not just metadata.

For the full capability model and the supported transport options, see the Remotes & sync guide.

Plan before you push

The fastest way to break a shared environment is to sync before you understand what the sync will do. Govard's answer is --plan:

govard remote sync --plan staging

--plan produces a dry run: a readable list of every file, media, and database operation the sync would perform, grouped by direction, with sizes and the target path for each. Nothing is transferred. You review the plan, confirm it matches your intent, then run the same command without --plan to execute.

Two safety mechanisms sit on top of the plan:

• GPG-signed confirmation. When a sync targets a remote flagged sensitive (production, or any remote you mark as protected), Govard requires a confirmation signed with your configured GPG key. The signature proves the operation was authorized by a key the remote trusts, not just typed at a prompt — useful on shared machines and in audited environments.
• Destructive op guard. Any step that would delete or overwrite data on the remote is highlighted in the plan and blocked behind an explicit confirmation. A media sync that would remove orphaned files, or a database import that would replace the live schema, will not run silently.

Tip: keep --plan in your muscle memory. Reading the plan takes seconds and prevents the multi-hour recovery of an overwritten staging database.

The CLI commands reference lists every flag the remote subcommands accept, including the confirmation and guard options.

Docker-from-Docker media sync

One detail catches teams the first time they run Govard in a containerized setup: the orchestrator itself runs in Docker, and media lives on a Docker volume. Syncing media means copying between two Docker-managed filesystems, not between a host folder and a remote — the "Docker-from-Docker" path.

On a development machine that should mirror staging's media without a full copy, Govard supports mounting the staging media volume directly:

govard env up --use-staging-media

--use-staging-media points the local environment at the staging media volume instead of pulling gigabytes of images across the network. Your code and database still come from your own work, but product photos, banners, and uploaded assets render exactly as they do on staging. It is the fastest way to get a visually faithful local clone when the media bucket is large and you only need to see it, not edit it.

When you do need the media locally — to test an upload flow, for example — drop the flag and run a normal govard remote sync --plan scoped to the media capability:

govard remote sync --plan staging --capabilities media

This keeps a media-only sync from ever touching your files or database.

Connection profiles & exclusion rules

Real projects are messier than a clean checkout. Build artifacts, local .env files, node_modules, and editor metadata should never leave your machine. Govard handles this with exclusion rules attached to the remote or to the connection profile, so they travel with the configuration rather than with your memory.

An exclusion rule is a simple pattern list:

govard remote exclude staging \
  --add 'node_modules' \
  --add '.env.local' \
  --add 'var/cache/*'

Excluded paths are skipped on every sync to that remote, in both directions, and they appear in the --plan output as "excluded" so you can confirm nothing sensitive is queued. Combined with per-remote connection profiles, you can maintain a staging profile that syncs everything except caches and secrets, and a production profile that disables files push entirely and only ever pulls the database for local debugging.

Profiles also let the same remote name mean different things per machine. A developer on macOS and one on Linux can both run govard remote sync staging and get correct, environment-appropriate behavior because the profile resolves paths and transports locally. See Configuration for the profile schema and how profiles merge with your base config.

Next in this series: Running Magento 2 locally with Govard — /blog/govard-magento2