Skip to main content

Static Environments

While pull request environments are ephemeral and tied to the PR lifecycle, static environments are long-lived environments that you create and manage explicitly. They are not bound to a pull request — you control when they are created, deployed to, and deleted.

When to Use Static Environments​

Static environments are useful when you need:

  • Shared staging or QA — a persistent environment that multiple team members can test against
  • Environments that outlive a single PR — long-running test beds, demo environments, or release candidates
  • Manual control over deployments — you decide when to deploy new code rather than having it happen automatically on every push

How They Work​

Static environments are created by pointing greyhound at a GitHub repository and a Git ref (branch or tag). Greyhound resolves the ref to a commit, reads the greyhound configuration at that commit, and provisions the environment asynchronously.

  1. Create — create an environment from a repository and ref using GitHub Actions, the CLI, or the API
  2. Deploy — trigger new deployments to update the environment with the latest code
  3. Manage — list environments, check status, and delete when done

Auto-Deploy​

When creating an environment, you can enable auto-deploy. With auto-deploy on, greyhound automatically redeploys the environment whenever a new commit is pushed to the tracked branch or tag — similar to how PR environments update on every push.

With auto-deploy off (the default for API-created environments), deployments must be triggered explicitly.