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.

Talk to our team View subprocessors

Last updated August 2026 · Primary data stored in U.S. AWS regions

TLS 1.2+

Encryption in transit on every external connection

AES-256

Encryption at rest across all data stores

Multi-AZ

Redundant compute across multiple availability zones

Audit log

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. Traffic is also geographically restricted—requests from outside the markets we serve are stopped at the edge before they reach the application.
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	Amazon DynamoDB	Primary operational database; partitioned per department
User accounts, login sessions, credentials	Amazon DynamoDB	Passwords hashed; MFA secrets KMS-encrypted
Audit trail of every create / update	Amazon DynamoDB	Append-only; retained for accountability
Uploaded files (photos, documents, attachments)	Amazon S3	Served only through signed, expiring URLs
Inbound CAD email	Amazon S3	Auto-expires after a retention window
Session cache, realtime messaging	ElastiCache (Valkey)	Transient; not the system of record

AI Features: Where That Data Goes

Command Established offers optional AI-assisted features—generating an incident narrative from structured fields, parsing CAD dispatch emails, scanning inventory and certificates, transcribing EMS vitals, and similar drafting and extraction tasks.

Primary provider: Google Vertex AI. AI requests are processed by Google's Gemini models through Vertex AI. Google acts as our subprocessor and, under our agreement with Google, does not use your data to train its foundation models. Search embeddings are generated the same way and indexed in TurboPuffer.
Resilient fallback inside AWS. If Vertex AI is unavailable—or slow to respond—text, PDF, and image requests fail over to models hosted on AWS Bedrock, running in-region inside AWS. Audio transcription runs on Vertex AI only. For CAD email parsing the fallback is hedged: the Bedrock request starts only after Gemini has used up a head start, and the first valid result wins. AWS does not use inputs or outputs to train the underlying models.
No new credentials, no new exposure. The Bedrock fallback authenticates with the same narrowly scoped IAM task role as our other AWS services—no static API keys—and traffic to both providers travels over TLS.
Validated, attributed output. Structured extraction—parsed dispatch fields, scanned inventory and certificate data—is schema-validated before it is accepted; drafted free text, such as a generated narrative, is returned for review. Either way, output is stored in your department's tenant like any other record and remains fully reviewable and editable by your personnel.

More detail on AI data handling is in our Privacy Policy.

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 (all buckets)	AES-256 (SSE-S3) · private · data buckets 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. Delegated API access uses a standards-based OAuth 2.1 authorization server. 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.
Durable delivery. Notifications (in-app, email, and web push) and inbound CAD email flow through SQS queues with automatic retries and dead-letter queues, and delivery latency is measured and monitored.
Monitoring & alerting. Logs, metrics, and errors feed centralized monitoring (CloudWatch and Sentry) with automated alerts, and AWS GuardDuty continuously watches the environment—including S3 access patterns—for threats.

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. Departments handling patient information can find our compliance posture on our HIPAA 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.