Skip to content

Deployed Dev Lifecycle

The deployed dev environment is cost-first and disposable by default, but “shutdown”, “reset”, “replacement”, and “teardown” do not mean the same thing.

Use this page to reason about what happens to the runtime host, containerized Postgres data, and S3 media objects when an operator or workflow changes lifecycle state. Use Runbooks for reviewed procedures and Infrastructure Change Policy for Pulumi graph transitions.

  • Ordinary host shutdown is a cost-control action, not application-data cleanup.
  • The shutdown Lambda stops the EC2 runtime host; it does not delete S3 media, clear the database, run backups, or drain containers gracefully.
  • Automatic inactivity shutdown invokes the same host-stop path after the selected CloudFront request inactivity window.
  • Deployed-dev Postgres data is disposable and reseedable, but it is not automatically wiped by EC2 stop/start.
  • Deployed-dev S3 media is disposable at the infrastructure lifecycle level, but it persists across host stop/start and can outlive database rows after destructive reset or seed workflows.
  • DB/S3 divergence cleanup should be an explicit discrepancy report, cleanup command, or reset runbook. It should not be hidden inside host shutdown.
  • Backup and restore work remains a learning drill for deployed dev, not a production disaster-recovery guarantee.
Event / OperationRuntime Host BehaviorPostgres / DB DataS3 Media Bucket Data
Container restartContainers restart on the same EC2 host.Should persist if /opt/wavemap/data/postgres remains mounted and untouched.Unchanged.
Docker Compose down/upContainers are stopped and recreated on the same host.Should persist if the host path /opt/wavemap/data/postgres is preserved.Unchanged.
Runtime deploySelected backend/frontend images are pulled and Compose is restarted on the host.Preserved unless the deploy also runs an explicit reset or migration path.Unchanged.
Runtime rollbackThe last-good app image pair is redeployed through the runtime deploy document.Not rolled back.Not rolled back.
Operator shutdown Lambda / EC2 stopThe EC2 instance stops; root EBS remains provisioned.Should persist across stop/start because the root EBS volume remains attached to the same instance.Unchanged. The shutdown Lambda does not touch S3 buckets or objects.
Automatic inactivity host stopEventBridge invokes the inactivity monitor, which can invoke the shutdown Lambda.Same as EC2 stop. The inactivity policy does not run database cleanup, backup, reset, or seed commands.Unchanged. The inactivity policy does not touch S3 buckets or objects.
Future container-only standbyHost stays running; app containers may stop.Should persist if the Postgres data path remains mounted and no reset command runs.Unchanged.
Database reset / destructive reseedHost may stay running; database contents are deliberately reset.Existing rows may be deleted or replaced according to the selected reset/seed command.Unchanged. Media objects can become application-orphaned if database rows referencing them are removed.
Media discrepancy reportRuns inside the deployed API container through SSM.Read-only DB inspection.Read-only S3 inspection.
EC2 runtime replacement or destroyA new instance may occupy the logical runtime slot, or the old one may be destroyed.Data on the old root EBS volume is at risk unless a backup, copy, snapshot, or migration runbook is used.Unchanged unless the Pulumi change also modifies the media bucket or its policies.
Media bucket replacement / destroyNot a runtime-host action by itself.Unchanged by bucket operations, though app rows may reference objects that no longer exist.At risk. The deployed-dev media bucket currently uses forceDestroy, so bucket destroy can delete its objects.
Full deployed-dev stack destroyAll stack-owned resources may be removed according to Pulumi/provider settings.At risk, including root-volume-backed Postgres data, unless explicitly retained or backed up.At risk because the dev media bucket is intentionally disposable and configured for forced cleanup.

The current deployed-dev standby vocabulary should stay explicit:

Mode / EventMeaningNormal Gate
Container-only standbyFuture softer standby where selected app containers stop while the EC2 host and Postgres data path remain available.Not a current routine path.
Host stopThe current deliberate cost-control path. The EC2 instance stops while root EBS, S3 media, DNS names, and the wake path remain intact.Shutdown Lambda or approved lifecycle proof.
Runtime reset / destructive reseedInfrastructure identity is preserved, but database contents are intentionally replaced or reseeded.pnpm wavemap -- deploy dev database reset --execute.
EC2 runtime replacementA guarded infrastructure change replaces or destroys the runtime host.Runtime host replacement.
Media bucket replacement / destroyA guarded infrastructure or storage migration action changes the deployed-dev media bucket.Media bucket replacement.
Full deployed-dev stack teardownStack-owned runtime, ingress, control-plane, and storage resources may be removed according to Pulumi/provider settings and explicit operator plan.Explicit stack-destroy decision.

Do not describe stack teardown as standby. Do not let automatic inactivity handling become a data cleanup, reset, replacement, or stack-destroy path.

Lifecycle actions should end with evidence that matches their risk:

Mode / EventExpected EvidenceMust Not Do
Container-only standbyA resume command brings the same runtime back without rebuilding infrastructure, and smoke checks pass against existing DB/media state.Delete S3 objects, reset Postgres, replace EC2, or present itself as a full cost-control shutdown.
Host stopWake path starts the host again, dynamic origin DNS refreshes, original browser destination recovers, and smoke checks pass after wake.Run data cleanup, reseed the database, delete media, or require a Pulumi update to resume service.
Runtime reset / destructive reseedReset output states what changed, deployed smoke checks pass against the new seed state, and expected DB/S3 divergence is reported or cleaned explicitly.Hide behind a standby/shutdown command, or leave media-object orphaning unreported when media rows are reset.
EC2 runtime replacementPreview summary names the replacement, operator approves the data outcome, the deploy document succeeds on the new host, and deployed smoke checks pass.Occur unattended in normal app CD, silently discard DB state, or alter the media bucket unless separately approved.
Media bucket replacement / destroyPreview summary names bucket replacement/delete, operator approves object-data handling, runtime config is refreshed, and media upload/rendering checks pass afterward.Be triggered by host shutdown, container standby, or routine runtime reset.
Full deployed-dev stack teardownTeardown summary records expected deletes, including DB/root-volume and media-bucket data outcomes.Be described as standby, or be invoked by automatic inactivity handling.
  • Deployed Dev Environment records the selected environment shape, cost posture, value ownership, and control plane.
  • Data Durability And Recovery records disposable deployed-dev data posture, reset boundaries, backup learning drills, and future recovery gates.
  • Runbooks records reviewed operator procedures such as runtime config readiness, runtime deploy, rollback, database reset, and media discrepancy reporting.
  • Deployment Workflows records deployed-dev CD profiles, smoke lane promotion, and responsibility flow.
  • Infrastructure Change Policy records Pulumi review, replacement/delete gates, resource lifecycle classes, and topology evidence boundaries.
  • Working notes may keep proof history, live run identifiers, and unsettled lifecycle experiments until they are reviewed and promoted.