Stateful resources
llms.txt lists every page for a coding agent.
A Loom deployment is mostly stateless infrastructure that redeploys from the same CloudFormation templates. A few things hold real state, and those are what backup and restore are about.
| Holds | What | A redeploy brings it back | Protected by |
|---|---|---|---|
| RDS Postgres | Loom’s application data: agents, memories, credentials, costs, settings, registered roles | No | 7-day automated backups and point-in-time recovery, DeletionPolicy: Snapshot, loom-backup snapshots and DR copies, the upgrade Op’s pre-migration snapshot |
| Cognito user pool | User records | Configuration only (groups, clients, resource server, scopes come back from code) | loom-cognito-export; deletion protection on the production tiers |
| Secrets Manager | The database credential, MCP and A2A OAuth2 client secrets (loom/*) | No | Recreated by the stack for the database; Loom’s own secrets live with the account |
| S3 artifact bucket | Agent code artifacts | Yes, rebuildable from source | Versioning, DeletionPolicy: Retain |
| ECR repositories | Built images | Yes, rebuilt from the pinned Loom source | Left behind by teardown |
| AgentCore | Runtimes, memories, credential providers created from Loom’s UI | No | Nothing loomster adds; they live outside CloudFormation |
| CloudFormation templates | The infrastructure | Yes | git |
Two consequences:
- Multi-AZ on
production-hais availability. It removes single-AZ failure as a way to lose data, but a bad delete replicates to the standby too, so production-ha still needs backups. - Every RDS restore creates a new instance. RDS has no in-place undo, so a
restore is always followed by a cutover, which is why
loom-restoreis gated (Gated Ops).
Back up and restore has the steps, and Tiers and targets the recovery targets per tier.