Deploy & operate

A new app should declare its access policy, services, configuration, schema changes, work limits, and recovery expectations. The platform supplies the common mechanisms.

Configuration and secrets

Shared settings load at process startup. In production, SSM configuration overrides local database settings. App-specific settings are read through kit.config and cached per process.

value = await kit.config.aget("SERVICE_TOKEN")

Declare environment names with required_env and app-scoped SSM names with required_secrets. Values do not belong in manifests or committed files. Operators can use at cloud secret-put <app> <name> to enter a value through a hidden prompt and store it as a SecureString. Restart after rotation to refresh cached values.

The runtime EC2 role has application permissions. Provisioning and database schema changes use separate operator authority.

Schema changes

at cloud migration-new my_app "add results table"

Edit and review the generated migration. Test it in an isolated database before applying it to production with the operator workflow. Use app-prefixed table names and additive changes that remain compatible during deployment.

Runtime database roles cannot create tables. Deployment and readiness compare the applied migration heads with the code. The operator database guide contains exact production commands.

Deployment

at doctor my_app
at build my_app
at doctor --live
at deploy

The active workflow builds frontends, validates capability/configuration requirements, checks schema and dependency readiness, restarts services, and smoke-tests each app. For Python-only changes, at deploy --skip-build skips frontend builds.

The optional immutable-release implementation can verify artifacts and restore a previous release symlink after failed checks, but it is not the active service layout. GitHub production deployment wiring and automatic preview environments are not configured. Schema rollback is a separate concern; never assume reverting application code reverses data changes.

Health, logs, and analytics

A green readiness check verifies dependencies, not every business workflow. Test real sign-in, ownership, uploads, job results, and error states when changing those flows. Do not put credentials, signed URLs, or personal content into diagnostic logs.

Recovery

RDS provides seven-day point-in-time recovery. Nightly SQL dumps go to S3; the platform backup also covers local application files. Monthly drills download the real backups, verify hashes, restore into disposable local databases, compare table counts, and remove the test databases.

Media uses separate S3 replication. Deleting a source object does not delete the recovery copy. DynamoDB tables have point-in-time recovery; the pilot has been exercised through a restore to a separate table.

Restore into an isolated destination, verify it, then switch configuration. Pointing back to a stale pre-migration database after new writes can lose data. Detailed steps and acceptance evidence are in the operator runbooks.

Capacity and costs

The current platform reuses one managed RDS instance and the existing VM. Storage, download egress, retained file versions, logs, model calls, and request volume remain variable costs.

Owner quotas and DynamoDB throughput ceilings constrain resource use, but are not a monthly dollar cap. The additional infrastructure allocation is $200/month; budget email alerts are intentionally disabled. The VM and Single-AZ database remain availability limits.