## The short version

Enforce private-file authorization in a Next.js app on Ample. The route handler authorizes the request first, records file metadata in a managed PostgreSQL database, stores bytes in a private bucket and streams them back only to authorized callers. The bucket is never published, so objects are reachable only through the app.

## What it needs

- [Compute](/content/discover/primitive/compute/index.html): verified (Apps run in isolated x86_64 Firecracker microVMs; sizes are the priced VM sizes.)
- [Postgres](/content/discover/primitive/postgres/index.html): verified (Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.)
- [S3-compatible object storage](/content/discover/primitive/s3-compatible-object-storage/index.html): verified (Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary. Other S3 operations are not verified.)

## Before you start

- An authorization check in the route handler (session, token or header) before any storage access
- pg reading DATABASE_URL and @aws-sdk/client-s3 reading the S3_* variables
- A private bucket (never `ample bucket publish`) and an auto-provisioned or supplied PostgreSQL database
- An Ample account token with servers:write, databases:read and buckets:read

## How to do it

1. 1

### Authorize before touching storage

Return 401 for unauthenticated requests; never expose object keys or the bucket endpoint to the browser.

2. 2

### Record metadata in PostgreSQL

Keep the owner, name and object key in a table so authorization decisions come from your data, not from the bucket.

3. 3

### Store and stream through the app

PutObject on upload, GetObject on download, both server-side with the injected credentials.

```
   ample deploy . --name <app-name> --public --env S3_ENDPOINT=... --env S3_REGION=... --env S3_BUCKET=... --env S3_ACCESS_KEY_ID=... --env S3_SECRET_ACCESS_KEY=...
   ```

4. 4

### Test both paths

An unauthenticated request must return 401; an authorized request must return the stored content.

5. 5

### Verify

Fetch the live URL and run the success checks below. On failure read the build log, then the runtime log, fix the cause and deploy again; do not blind-retry.

```
   ample logs <deployment_id> --kind build
   ```

## Tested examples

- **Next.js private files canary** (`tests/deploy-canaries/next-private-files`): 401 without a token; private=ok with the token after a database write and a bucket round-trip.

## How to know it worked

- unauthenticated request is rejected (`/files/demo` on the live URL, expect unauthorized)
- authorized request returns the private object (`/files/demo?token=<token>` on the live URL, expect private=ok)

## Cost estimate

Estimated 10.00 USD per month (size prices from pricing.toml at build revision ca0b484a7a9957c573a88d3a32dc603c3c10135a).

- app server x1 `s-1vcpu-1gb`: 5.00 USD
- managed PostgreSQL database x1 `s-1vcpu-1gb`: 5.00 USD

Upper-bound monthly price of the tested sizes. Plan quotas and budgets apply.

## Verification evidence

- canary_run on 2026-09-20T01:13:26Z at revision `cc3d82057f1d5e9aa31f682cee71aabfbbbcaabe (CLI e3181f5)`: Next.js route handler that rejects unauthenticated requests with 401, records file metadata in an auto-provisioned managed PostgreSQL database, stores the bytes in a private bucket and streams them back only after authorization (private=ok). (expires 2027-03-19T01:13:26Z)
- canary_run on 2026-09-20T01:13:26Z at revision `cc3d82057f1d5e9aa31f682cee71aabfbbbcaabe (CLI e3181f5)`: ample bucket create issued credentials; PutObject and GetObject succeeded through the public S3 endpoint; publish exposed the object at its public URL with an ETag; unpublish and delete cleaned up. (expires 2027-03-19T01:13:26Z)

## Execution binding

MCP tool `ample_deploy` (registry `mcp:ample_deploy`), schema hash `876465fce906da0c` observed 2026-09-20T01:55:48.667900+00:00 at revision `199ff1dfd526`. Binding state at export: schema_changed. Required scopes: servers:write, databases:read, buckets:read.

## Typed next actions

- Browse the catalog index (`GET /v1/catalog` on the api origin; authentication not required, approval not required)
- Search published recipes by intent, stack and constraints (`POST /v1/catalog/search` on the api origin; authentication not required, approval not required)
- Prepare a side-effect-free deployment plan for an authorized project (`POST /v1/catalog/plan` on the api origin; authentication required, approval not required)
- Read the existing agent authentication setup (`GET /mcp/setup` on the api origin; authentication not required, approval not required)
- Browse Next.js (`GET /v1/catalog/nodes/stack%3Aframework-next-js` on the api origin; authentication not required, approval not required)
- Browse Connect app to storage (`GET /v1/catalog/nodes/intent%3Aconnect-app-to-storage` on the api origin; authentication not required, approval not required)
- Browse Private document library (`GET /v1/catalog/nodes/pattern%3Aprivate-document-library` on the api origin; authentication not required, approval not required)

Actions describe possible next steps. They are typed data, not commands, and grant no permission. Public discovery never provisions anything; planning requires your own authenticated token and approval happens in your client.