Infrastructure Overview

This section explains where Volāre runs in production and how that is managed. Everything here is defined as code in a separate repository, volare-tech/infra-volare. You only need it when you deploy, change servers, secrets or alerts, or debug production.

The short version

Cloud: AWS, region us-east-2 (Ohio), two AWS accounts: one for staging (which also holds all Terraform state) and one for production.
Servers: plain EC2 instances in Auto Scaling groups, each running Docker containers. No Kubernetes, no ECS.
Database: one Amazon RDS PostgreSQL 18 instance per account.
DNS: Cloudflare (DNS only — traffic goes straight to AWS, not through the Cloudflare proxy).
Images: application Docker images are built in the volare repo and stored in Amazon ECR; server images (AMIs) are built with Packer + Ansible in infra-volare.
Infrastructure as code: Terragrunt (Terraform 1.10, Terragrunt 0.99).
Deploys: a GitHub Actions workflow in infra-volare that you trigger by hand. See Deploy Workflows.
Monitoring: Grafana Cloud (metrics, logs, alerts) plus Laravel Nightwatch and Sentry. See Monitoring and Alerts.

How a request reaches the code

flowchart TB
  U[Customer / staff browser] --> CF[Cloudflare DNS]
  CF -->|byvolare.com, www| FALB[front ALB]
  CF -->|api., arkana., analytics.| AALB[api ALB]
  CF -->|assets.| CDN[CloudFront] --> S3[(S3 assets bucket)]
  FALB --> FRONT[front servers<br/>Astro SSR container]
  AALB -->|/api, Arkana| API[api servers<br/>nginx + php-fpm]
  AALB -->|analytics MCP, Telescope| OPS[ops-runner server<br/>queues, scheduler, analytics-mcp]
  FRONT -->|server-side API calls| API
  API --> RDS[(RDS PostgreSQL)]
  OPS --> RDS
  OPS --> EXT[AerTicket, Stripe, Pipedrive, NetSuite…]
  API --> EXT

Environments

Terragrunt code lives in terragrunt/live/us-east-2/, one folder per environment:

Folder	What it contains	AWS account
`staging-shared`	Network (VPC, load balancers), the staging RDS database, Twingate, private DNS	staging
`staging-1`	The staging application: servers, target groups, DNS records, assets bucket, Hermes	staging
`production-shared`	Same as staging-shared, for production (bigger database, backups on)	production
`production-1`	The production application, plus the database-dumps bucket and the Analytics MCP	production
`global`	Grafana Cloud alert rules (applied automatically when merged)	—

The -shared / -1 split means the network and database could serve more than one application environment, although today each account has exactly one (staging-1, production-1).

Public hostnames

Host	Staging	Production	Served by
The Web	`front-staging-1.byvolare.com`	`byvolare.com` (`www` redirects)	`front` servers
Public API	`api-staging-1.byvolare.com/api`	`api.byvolare.com/api`	`api` servers
Arkana	`arkana-staging-1.byvolare.com`	`arkana.byvolare.com`	`api` servers
Static assets	`assets-staging-1.byvolare.com`	`assets.byvolare.com`	CloudFront + S3
Analytics MCP	—	`analytics.byvolare.com`	`ops-runner`
Hermes dashboard	`agents-staging-1.byvolare.com`	`agents.byvolare.com`	`hermes` (behind Cloudflare Access)

The servers

Each application environment has four Auto Scaling groups. Instance names follow <role>-<env> (for example api-production-1).

Role	Runs	Production size
`api`	Arkana and the public API (nginx + php-fpm)	2 × t3.medium
`front`	The Web (Astro server-side rendering)	2 × t3.medium
`ops-runner`	Queue worker, scheduler, database migrations, Analytics MCP, Telescope	2 × t3.medium
`hermes`	The Hermes AI agent	1 × t4g.large (ARM)

Staging runs one smaller spot instance per role. Details, containers and configuration are in Servers and Containers.

Where to go next

I want to…	Read
Deploy a new version	Deployment, then Deploy Workflows
Change an environment variable or secret	Servers and Containers › Configuration
Get a shell on a server	Server Access
Reach the database, Swagger or Telescope	Networking and Access
Understand an alert	Monitoring and Alerts
Change infrastructure code	Working on infra-volare
Know what Hermes is	Hermes