# Host Asset Library with Phoenix: Relational Workflow State

Deploy an asset library built with Phoenix on Ample using the transactional workflows pattern. Compute runs the app in an isolated microVM behind a public HTTPS URL, and a managed PostgreSQL 16 database is auto-provisioned and injected as DATABASE_URL. Verified on Phoenix: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected). Not separately tested: your domain records, validation rules, and concurrency policy; treat the asset library-specific behavior as your application code.

## Summary
- **Family:** Workload recipe  
- **Framework:** Phoenix  
- **Workload:** Asset library  
- **Release Status:** Published  
- **Support Status:** Verified  
- **Execution Status:** Ready

### Representative Queries
- Host asset library with Phoenix: relational workflow state
- Where can I host Asset library built with Phoenix?
- I need a domain record schema, validation rules, and concurrency behavior.

### Resource Requirements
- `primitive:compute`
- `primitive:postgres`

### Infrastructure Requirements
#### Compute
- **Primitive ID:** primitive:compute  
- **Status:** Verified  
- **Summary:** Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.

#### Postgres
- **Primitive ID:** primitive:postgres  
- **Status:** Verified  
- **Summary:** Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.

### Workflow Steps
1. **Build and Start**  
   Commands: `mix deps.get, MIX_ENV=prod mix compile and mix release in the builder`, then `the release bin script with PHX_SERVER=true on the elixir-1.18 template; PORT, DATABASE_URL, and SECRET_KEY_BASE read in config/runtime.exs.` The server must bind 0.0.0.0 on PORT.

2. **Implement the Pattern on PostgreSQL**  
   The fixture's module implements transactional workflows: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected). Copy the approach into your schema; keep migrations idempotent and run them with --release-command.

3. **Deploy**  
   Command: `ample deploy . --name  --public`

4. **Verify**  
   Command: `ample logs --kind build`

### Examples
- **Phoenix Pattern Fixture**  
  *Description:* Multi-pattern Phoenix app whose transactional workflows module was checked live; the module is under tests/deploy-canaries/_pattern-modules.
  *Source Ref:* tests/deploy-canaries/phoenix-patterns

### Success Checks
- App responds on its public URL  
  *Kind:* http_get  
  *Path:* /  
  *Expect:* ample canary phoenix patterns

- Transactional-workflows self-test  
  *Kind:* http_get  
  *Path:* /p/transactional-workflows  
  *Expect:* tx=ok history=2 conflict=rejected

### Cost Estimate
- **Currency:** USD  
- **Monthly Amount:** 10.0  
- **Basis:** Size prices from pricing.toml

#### Components
- **App Server**  
  *Size:* s-1vcpu-1gb  
  *Monthly Amount:* 5.0
- **Managed PostgreSQL Database**  
  *Size:* s-1vcpu-1gb  
  *Monthly Amount:* 5.0

### Limitations
- Verified on the elixir-1.18 template at s-1vcpu-1gb.
- The asset library itself is application code and was not separately tested.

### Next Actions
- **Browse the catalog index**  
  *Action ID:* browse-catalog  
- **Prepare a side-effect-free deployment plan**  
  *Action ID:* plan:page:recipes:asset-library:phoenix:relational-workflow