Architecture & Security
Built secure, from the edge to the database
Command Established is a cloud platform on Amazon Web Services, designed for the sensitivity of fire department data—incident records, personnel files, and patient information. Here's how the production system is put together, and how your data is protected in transit and at rest at every step.
Last updated June 2026 · Primary data stored in U.S. AWS regions
Encryption in transit on every external connection
Encryption at rest across all data stores
Redundant compute across multiple availability zones
Append-only log of changes to your operational records
System at a Glance
The production environment: how users reach the application, where the application logic runs, where data is stored, and which connections are encrypted.
How a Request Flows
-
1
Your browser connects to the edge
Every visitor reaches Command Established over HTTPS through Amazon CloudFront, AWS's global content delivery network. Connections use TLS 1.2 or higher, and HSTS tells browsers to refuse any unencrypted connection.
-
2
Static assets are served from S3
The web application and our public pages are delivered from a private Amazon S3 bucket. The bucket is not publicly accessible—CloudFront is the only thing that can read it, using AWS Origin Access Control with signed requests.
-
3
API calls go through a load balancer
Requests to
/api/*are forwarded to an Application Load Balancer over HTTPS. It only honors requests carrying a secret header set by CloudFront, so requests that don't arrive through CloudFront are rejected. -
4
The application runs on Fargate
The API is a containerized Bun + Hono service on AWS ECS Fargate, reachable only through the load balancer. It runs as redundant tasks across separate availability zones and scales automatically. Each request to department data is authenticated, validated, permission-checked, and—when it changes data—written to an append-only audit log.
-
5
Data is stored in managed AWS services
The application reads and writes to DynamoDB, caches in ElastiCache (Valkey), stores files in S3, and pulls credentials from Secrets Manager—all reached over encrypted, private network paths.
Where Your Data Lives
All systems of record are hosted in AWS data centers in the United States. Files delivered through our content-delivery network may be cached temporarily at edge locations outside the U.S., but the authoritative copies remain in U.S. regions.
| Data | Stored in | Notes |
|---|---|---|
| Incidents, personnel, apparatus, training, inventory, inspections, permits | DynamoDB — Content table | Primary operational database; partitioned per department |
| User accounts, login sessions, credentials | DynamoDB — Users table | Passwords hashed; MFA secrets KMS-encrypted |
| Audit trail of every create / update | DynamoDB — Audit table | Append-only; retained for accountability |
| Uploaded files (photos, documents, attachments) | S3 — User Content | Served only through signed, expiring URLs |
| Inbound CAD email | S3 — CAD Email | Auto-expires after a retention window |
| Session cache, realtime messaging | ElastiCache (Valkey) | Transient; not the system of record |
Encryption Everywhere
Public and cross-service traffic uses TLS 1.2+, and data at rest is encrypted across every store. The only unencrypted hop—the load balancer to the application—stays inside the private VPC.
In Transit
Every connection that crosses a network boundary uses TLS 1.2 or higher.
- ✓Browser → CloudFront: HTTPS only; HTTP redirected; HSTS enforced.
- ✓CloudFront → Load Balancer: TLS 1.2 plus a shared-secret header so the origin only serves CloudFront.
- ○Load balancer → application: the one hop that isn't TLS—plain HTTP that never leaves the private VPC; the load balancer terminates TLS.
- ✓App → DynamoDB, Secrets, SQS: private VPC endpoints—traffic never leaves AWS's network—over TLS.
- ✓App → ElastiCache: in-transit encryption (TLS) enabled.
- ✓App → integrations & email: all outbound calls use HTTPS; mail sent via SES with DKIM & SPF.
At Rest
Every persistent store is encrypted at rest, with a customer-managed KMS key for the most sensitive secrets.
| DynamoDB (all tables) | SSE enabled · point-in-time recovery |
| S3 (web, uploads, CAD email) | AES-256 (SSE-S3) · private · versioned |
| ElastiCache (Valkey) | At-rest encryption enabled |
| Amazon SQS | Server-side encryption enabled |
| Secrets Manager | KMS-encrypted |
| MFA / TOTP secrets | Customer-managed KMS key · auto-rotation |
Network Isolation & Access Control
Isolated databases
Databases run in private subnets of a multi-AZ Virtual Private Cloud with no public internet access. The application tier accepts inbound traffic only from the load balancer—never directly from the internet.
Locked-down origin
The application is reachable only through CloudFront, which presents a shared secret to the load balancer. Direct requests to the origin are rejected.
Least-privilege IAM
The application runs with narrowly scoped AWS permissions—only the specific tables, buckets, queues, and keys it needs.
Secrets never in code
All credentials and API keys live in AWS Secrets Manager and are injected at runtime over encrypted channels.
Authentication & authorization
Secure, HTTP-only session cookies, optional multi-factor authentication, and fine-grained role-based checks on every request that accesses department data. Each department's data is isolated from every other department's.
Hardened browser security
A strict Content Security Policy, HSTS, clickjacking protection, and MIME-sniffing protection are applied to every page.
Reliability & Backups
- Redundancy. Multiple tasks across separate availability zones, scaling automatically; an unhealthy task is replaced without downtime.
- Point-in-time recovery. DynamoDB continuous backups allow restore to any moment within the retention window.
- Versioned storage & snapshots. S3 keeps prior versions of objects; the cache layer is snapshotted daily.
- Monitoring & alerting. Logs, metrics, and errors feed centralized monitoring (CloudWatch and Sentry) with automated alerts.
Auditability
Every change to your operational records is recorded in a dedicated, append-only audit log capturing who made the change, when, and what changed—giving your department a comprehensive history for accountability, compliance, and incident review.
We rely on a small, carefully vetted set of third-party subprocessors. The complete, current list—and what each handles—is on our Subprocessors page.
Questions about our architecture?
We're glad to walk your IT or security team through any part of this system, complete a security questionnaire, or provide additional documentation.