Environments, deployment and operations

Environments and previews

Production serves end users, staging validates changes before release, and preview is for short-lived changes. Keep branches, auto-deploy and variables independent for each environment. Do not use production credentials or data in previews. GitHub can create a preview service for a pull request and remove it after the PR closes.

Builds, releases and durable operations

A build records the source artifact; a release activates a build and a configuration snapshot in an environment. States such as queued, building, ready and failed describe builds. Deployment, lifecycle, exposure and deletion are trackable operations that may pass through several stages before reaching a terminal state.

Rollback and promote

Rollback turns a previously prepared build into a new release without rebuilding. It does not roll back the database schema; migrations must be backward-compatible or have a separate plan. Promote moves the same tested artifact to the destination environment, avoiding differences introduced by rebuilding.

Git and deploy hooks

With auto-deploy enabled, a push to the connected branch creates a new build and reports commit status in GitHub. A deploy hook embeds a credential in its URL for use in CI; rotate it if exposed. Watch paths prevent unrelated deployments in a monorepo.

Web, workers, cron and replicas

• Web processes receive HTTP or TCP traffic;
• Workers perform background tasks without a public endpoint;
• Cron runs according to a cron expression, and each run has a status, time and exit code;
• Additional replicas scale the process horizontally; the application must be stateless or keep shared state in an add-on.

Monitoring and control

Runtime logs come from stdout/stderr. Metrics show CPU/RAM usage and traffic. Restart restarts the current process, Stop keeps the service stopped and Start runs it again. Changing an image, command, variable or release may trigger reprovisioning.