Environments

Current MVP default AWS region is eu-north-1 (Stockholm). That is a region, not an availability zone; the single-AZ dev posture means one AZ inside eu-north-1.

The three environments

Env	Purpose	HA	DR	Provider mode
Dev	Development, early validation, mock-driven iteration	Single AZ	None	Sandbox / mock
Test	Production-like validation, security + perf + reconciliation testing	Multi-AZ	DB DR to secondary region	Production-like (sandbox where vendor offers it)
Prod	Live regulated operations	Multi-AZ	DB DR to secondary region	Live

Principles

1. Test mirrors Prod. Anything that's hard to validate in a simplified env (network routing, CoSigner topology, async retry behaviour, reconciliation) is mirrored.
2. Dev stays cheap on purpose. Reduced footprint, single AZ, no DR. Don't try to validate prod-readiness here.
3. Strict isolation. Secrets, provider credentials, data, and network boundaries never cross environments.
4. Promotion is one-way. Dev → Test → Prod. No back-promotion of data.

Dev

Profile

• Single Availability Zone.
• No HA / DR requirement.
• Smaller compute + DB sizing.
• Lower logging volume.
• Reduced redundancy.

What's wired

• Route 53 + CloudFront + AWS WAF (lightweight rule set).
• API Gateway, internal ALB.
• App + worker containers on EC2 (smaller instance).
• Postgres single-instance (or simplified topology).
• S3, Secrets Manager, KMS, CloudWatch, CloudTrail.

Provider posture

Sandbox / mock / limited-validation everywhere it's available:

• Fireblocks: sandbox or simplified CoSigner profile (see 09-Open Questions#CoSigner topology).
• Elliptic (AML + sanctions): sandbox.
• Sumsub: sandbox.
• Mercuryo (acquirer + on/off ramp): sandbox.
• CEX.IO (rate oracle): public API with a 30 s batch cache.
• Email: local dev keeps EMAIL_PROVIDER=mock writing to mock_emails; AWS dev uses EMAIL_PROVIDER=resend for live delivery.

What Dev is not

• Final perf testing.
• Final security sign-off.
• Final reconciliation validation.
• Production readiness sign-off.

Those belong in Test.

Test

Profile

• Two Availability Zones.
• Production-like topology, including private subnets and NAT egress.
• Full HA model.
• DB DR to a secondary region.
• Same provider set as Prod (production endpoints where contractually permitted; otherwise vendor-sandboxes).

What's wired

• Same component list as Prod, just lower scale + fewer retained artifacts.
• Fireblocks CoSigner parent + Nitro Enclave in both AZs (mirrors Prod).
• GuardDuty enabled.
• Stronger observability than Dev.

What Test validates

Surface	What we check
User Account flows	Buy / Sell / Send / Receive / Convert / Wallet behaviours
Merchant Account flows	Invoicing / Payouts / API / Subaccounts
Admin Account flows	Users / Transactions / Wallets / Fees / Pages / Logs
API path	/api/v1/* response shapes, auth, rate-limit
Workers	Payout execution, webhook delivery, deposit indexer
Provider integrations	Callbacks, retry, signature handling
Network boundaries	SG enforcement, no public ingress to private services
Reconciliation	TRES mismatch handling, audit_log cross-reference
DR	DB backup + DR rehearsal

Test vs Prod differences

Aspect	Test	Prod
Traffic volume	Synthetic	Real
Retained logs	Shorter window	Full retention
Alert thresholds	Looser	Tight
Data	Test data only	Real customer data
Scale	Smaller	Production sizing

Architecturally identical. Operationally lighter.

Prod

Profile

• Two Availability Zones.
• Full HA + private application + data runtime.
• DB DR to secondary region.
• Strong observability and audit trail.
• Least-privilege access enforced.
• Separate admin entry path (AWS IAM Identity Center SSO + dedicated AWS WAF ruleset).

What's wired

• Everything in Test, plus:
  • Security Hub.
  • Tighter alert thresholds.
  • Production retention windows on logs/metrics.
  • Production provider contracts (live mode).
  • Production secrets (rotated regularly).

Production priorities

• Controlled availability.
• Understandable transaction processing.
• Provider stability + degraded-mode visibility.
• Traceable admin behaviour.
• Recoverable from any single-AZ failure without manual ops.
• Explicit DR rehearsal cadence.

Production controls

• Separate admin subdomain.
• AWS IAM Identity Center (SSO) on admin, with MFA enforced via permission set.
• Dedicated AWS WAF web ACL on the admin distribution (IP allowlist, geo restriction).
• Private runtime; no direct public ingress to data services.
• audit_log for every privileged action.
• Failure visibility / alerting / escalation paths.

Cross-environment rules

Strict separation

• Secrets per environment.
• Provider credentials per environment.
• IAM roles per environment.
• Network boundaries per environment.
• Data per environment — never copy Prod data into Dev or Test in raw form.

Cost logic

• Dev: minimise.
• Test: realistic but not aggressive.
• Prod: resilient and supportable.

Documentation rule

Every environment must be described consistently across:

• This page (logical profile).
• 13-Network-Model (network + security groups).
• 14-Operations (runbook coverage).
• 10-Roadmap (cutover targets).

DR strategy

Scope	Dev	Test	Prod
DB backup	Best-effort	Required	Required
DB DR to secondary region	None	Required	Required
Application failover	Single AZ	Multi-AZ	Multi-AZ
RPO target	n/a	< 1h	< 15min
RTO target	n/a	< 4h	< 1h

DR is intentionally DB-first — the rest of the application can be redeployed from artifacts. Critical data continuity is the non-negotiable layer.

Drawbacks

• Test+Prod architectural symmetry costs roughly 2× the AWS bill of a single env. Accepted to keep cutover risk low.
• Sandbox provider modes diverge from production; some integration bugs only surface in Prod.

Open Questions

• 09-Open Questions#CoSigner topology — Dev CoSigner profile.
• 09-Open Questions#Multi-region — when Prod gets a second active region (vs DR-only).
• 09-Open Questions#Sizing — final resource sizing per env.

Cross-references

• 11-Target-Architecture
• 13-Network-Model
• 14-Operations
• Glossary