Data and Storage

Databases (Amazon RDS PostgreSQL)

Each account has one shared RDS instance. The application environment uses a database and user named after the environment (staging-1, production-1); the credentials are in the backend .env parameter in SSM.

	Staging	Production
Instance	shared-staging-postgres, db.t3.micro	shared-production-postgres, db.t4g.large
Engine	PostgreSQL 18.3	PostgreSQL 18.3
Storage	20 GB	20 GB, grows automatically up to 100 GB
Automated RDS backups	none	7 days
Deletion protection	off	on
Monitoring	basic	Performance Insights, enhanced monitoring, slow-query log (> 1 s)

• The database is in private subnets: connect over Twingate.
• On top of RDS backups, the app takes a daily logical dump at 05:00 UTC to S3 from the ops-runner (db-backup.sh). You can restore it locally with /db-restore. See Database Backup & Restore.
• RDS applies minor version upgrades itself. When it does, the version pin in infra-volare/terragrunt/live/us-east-2/*-shared/postgresql/terragrunt.hcl must be bumped to match, or the next apply tries to downgrade and fails.
• Database schemas are changed only by Laravel migrations, which run when an ops-runner boots (see Servers and Containers).

Files (S3 and CloudFront)

Bucket	Purpose	Public?
<env>-volare-assets	Images and files uploaded in Arkana (served to the Web)	via CloudFront at assets[-staging-1].byvolare.com
production-1-volare-db-dumps	Daily database dumps	no
volare-<env>-hermes-backups	Hermes state backups	no

The CloudFront distribution adds security headers (HSTS, nosniff, X-Frame-Options: DENY) and caches files for a day by default. All app servers can write to the assets bucket; only the production ops-runner can write dumps.

Cache, sessions and queues

There is no Redis or ElastiCache in production. Laravel’s cache, sessions and queues all use the PostgreSQL database (database drivers). Redis exists only as a container in the local Sail stack.