Skip to content
Volare Documentation

Deployment

Step-by-step guide for deploying the Volare backend and frontend to staging and production environments.

Overview

Section titled “Overview”

Deploying requires two sequential steps:

  1. Build (automatic) — Merging a PR to master builds Docker images and uploads them to AWS ECR. This does not deploy anything — it only prepares the images.
  2. Deploy (manual) — A developer triggers the deploy workflow from the infra-volare repository to put those images on a server.

The deploy process is the same for both staging and production — the only difference is the environment selected in the workflow.

Prerequisites

Section titled “Prerequisites”
  • Access to the infra-volare GitHub repository
  • A merged PR in the volare repository (or a known image tag to deploy)

Automated Pipeline (after merge)

Section titled “Automated Pipeline (after merge)”

When a PR is merged to master, two workflows run automatically in the volare Actions tab:

  1. Tag on Merge — Creates a semantic version tag (e.g., v1.3.0) based on conventional commit messages
  2. Build & Push to ECR — Builds Docker images for backend and frontend and pushes them to AWS ECR, tagged with the version

Before deploying, verify both workflows completed successfully in the Actions tab. The version tag created (e.g., v1.3.0) is the value you will use as the image tag when deploying. You can find it in the repository tags.

Deploying

Section titled “Deploying”

Once images are built and available in ECR, trigger the deploy:

  1. Go to infra-volare Actions
  2. Select the Deploy infrastructure workflow
  3. Click Run workflow
  4. Fill in the form:
FieldDescriptionExample
Environment to deployTarget environmentstaging-1 or production-1
Frontend image tagVersion tag for the frontend imagev1.3.0
Backend image tagVersion tag for the backend imagev1.3.0
  1. (Optional) Check “Only run plan, do not apply” to preview infrastructure changes without deploying
  2. Click Run workflow

Tips

Section titled “Tips”
  • Frontend and backend tags are independent — you can deploy only a frontend change by using the new tag for frontend and keeping the current tag for backend (or vice versa).
  • There is no required order between staging and production. You can deploy directly to production if needed.
  • Use the sha-<commit> tag format if you need to deploy a specific commit that is not a release.

Post-deploy Verification

Section titled “Post-deploy Verification”

After the workflow completes, verify the deployment is healthy:

Health Endpoint

Section titled “Health Endpoint”
Terminal window
# Replace with the actual environment URL
curl https://<environment-url>/health

A 200 response with all checks ok confirms the deployment is healthy. See Health Monitoring for details on available checks.

Monitoring Dashboards

Section titled “Monitoring Dashboards”
  • Pulse (/pulse) — Check the Deployments card for the new entry and review real-time metrics
  • Telescope (/telescope) — Look for new exceptions or errors after the deploy

See Deployment Tracking for how deployments are recorded in Pulse.

Rollback

Section titled “Rollback”

To roll back a deployment, run the deploy workflow again with the previous version tag. The containers will be replaced with the earlier image.

Section titled “Related Documentation”