## Host public directory with Astro: Postgres-backed content

### Summary
Deploy a public directory built with Astro on Ample using the relational records pattern. Compute runs the app in an isolated microVM behind a public HTTPS URL, a managed PostgreSQL 16 database is auto-provisioned and injected as DATABASE_URL, and a published bucket serves public assets from the CDN host. Verified on Astro: a workspace-scoped table, an explicit state machine (draft to review to published) that rejects invalid transitions, and a cross-workspace read that returns nothing (transitions=true isolation=true). Not separately tested: your record schema, states and access rules; treat the public directory-specific behavior as your application code.

### Representative Queries
- Host public directory with Astro: Postgres-backed content
- Where can I host Public directory built with Astro?
- I need a content schema, publishing workflow and cache behavior after content updates.

### Resource Requirements
- **Compute**
- **Postgres**
- **CDN**

### Infrastructure Requirements
1. **Compute**: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
2. **Postgres**: Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.
3. **CDN**: The CDN host serves objects from published buckets. It does not front app compute and is not a cache or key-value store.

### Prerequisites
- An Astro project that builds and starts with the documented commands (astro build with the @astrojs/node standalone adapter then node ./dist/server/entry.mjs on the node-22 template).
- A PostgreSQL driver reading DATABASE_URL at runtime (auto-provisioned when omitted, or supplied with --env).
- A bucket from `ample bucket create` with its credentials passed as encrypted S3_* environment variables.
- An Ample account token with servers:write, databases:read, buckets:read.

### Tested Configuration
- **Template**: node-22
- **Runtime**: node
- **Size**: s-1vcpu-1gb
- **Install**: npm install
- **Build**: npm run build --if-present
- **Start**: npm run start

### Workflow Steps
1. **Build and start**: astro build with the @astrojs/node standalone adapter then node ./dist/server/entry.mjs on the node-22 template.
2. **Implement the pattern on PostgreSQL**: Copy the approach into your schema; keep migrations idempotent and run them with --release-command.
3. **Wire object storage**: Create the bucket(s), then pass endpoint, region, bucket and keys as --env values.
4. **Deploy**: Run the synchronous deploy once and read the result (exit 0 live, 1 failed, 2 blocked).
5. **Verify**: Fetch the live URL and the pattern self-test route(s) from the example; then run your own checks.

### Examples
- **Astro pattern fixture**: Multi-pattern Astro app whose relational records module was checked live; the module is under tests/deploy-canaries/_pattern-modules.

### Success Checks
- App responds on its public URL: Expected response - ample canary astro patterns
- Relational-records self-test: Expected response - records=ok transitions=true isolation=true

### Limitations
- Verified on the node-22 template at s-1vcpu-1gb; other sizes, templates and Astro major versions are not verified.
- The public directory itself was not separately tested.

### Cost Estimate
- **Currency**: USD
- **Monthly Amount**: 10.0
- **Components**:
  - app server: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: 5.0
  - managed PostgreSQL database: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: 5.0
- Note: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle.

### Evidence Summary
1. **Canary Run**: Astro pattern fixture deployed on Ample...  
2. **Canary Run**: The same Astro app deployed with a --release-command migration.

### Last Verified At
2026-09-20T03:31:44Z