# Travel operators: vendor portal using Next.js

## Summary

A vendor portal blueprint for travel operators built with Next.js on Ample. Domain schema: listings (reference, destination, departure_dates, price_from, publishing_status, agency_id): trips as listings with publishing status; agencies (name, license_number, region): operators or branches; suppliers (name, type, agency_id, status): hotels and transport suppliers; reports (agency_id, period, object_key, generated_at): branch sales reports; document_access (document_id, principal_reference, role, granted_at): who may read which document. Public information: published trips and departure dates, destination guides, booking conditions. Kept out of scope until handling is reviewed: traveler passports and identity, payment details, supplier contracts. Passport and payment data are regulated; only published trips and branch reporting are modeled. Technical basis verified on Next.js: a role-to-document access model with negative tests (401 without identity, 403 for the wrong role) and a private-bucket round-trip for the allowed role (private=ok).

## Infrastructure requirements

- Compute: verified (Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.)  
- Postgres: 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: verified (Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary. Other S3 operations are not verified.)

## Prerequisites

- A Next.js project (next build then next start -H 0.0.0.0 -p $PORT on the node-22 template)  
- A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted)  
- Bucket credentials from `ample bucket create` passed as encrypted S3_* environment variables  
- A review of which travel operators data classes may be handled at all; this blueprint models public information only

## Exact tested configuration

- template: `node-22`  
- runtime: `node`  
- size: `s-1vcpu-1gb`  
- install: `npm install`  
- build: `npm run build --if-present`  
- start: `npm run start`

## Steps

1. **Model the travel operators domain.** Create the tables listings, agencies, suppliers, reports, document_access. Trips as listings with publishing status lives in listings; keep the sensitive classes (traveler passports and identity, payment details, supplier contracts) out of this schema.  
2. **Workflow step 1.** Model vendors scoped to the agency with roles  
3. **Workflow step 2.** Authorize document access by vendor and role (401, 403 negative tests)  
4. **Workflow step 3.** Store vendor documents in the private bucket  
5. **Workflow step 4.** Deploy and verify the negative tests and an authorized download  
6. **Deploy.** Run the synchronous deploy once and read the result. Re-running with no change is a no-op.  
7. **Verify.** Run the pattern self-test(s) from the example (/p/private-document-library) and your own acceptance checks for the travel operators workflow.

## Tested examples

- **Next.js pattern fixture** (tests/deploy-canaries/next-js-patterns): Verified private document library basis for this blueprint.

## Success checks

- app responds on its public URL (`/` on the live URL, expect ample canary next js patterns)  
- private-document-library self-test from the example (`/p/private-document-library` on the live URL, expect see the pattern fixture checks)

## Limitations

- The technical basis (private document library on Next.js) was verified with the pattern fixture; the travel operators schema and workflow are an original design for this blueprint and were not executed as a separate application.  
- No health, financial, privacy or other compliance claim is made. Passport and payment data are regulated; only published trips and branch reporting are modeled.  
- Public content and synthetic examples only until actual data-handling requirements have been reviewed.  
- Verified on the node-22 template at s-1vcpu-1gb; region, request-duration limits and other sizes are unknown or unverified.  
- Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures are not verified.  
- PutObject and GetObject with path-style addressing are verified; other S3 operations and CDN cache rules are not.

## Cost estimate

Estimated 10.00 USD per month (size prices from pricing.toml at build revision a1b8c38919e59cd035ebabaced73cf84ece24371).  
- app server x1 `s-1vcpu-1gb`: 5.00 USD  
- managed PostgreSQL database x1 `s-1vcpu-1gb`: 5.00 USD

## Verification evidence

- canary_run on 2026-09-21T02:34:39Z at revision `1d28ae0-dirty (CLI 0.1.21)`: Next.js pattern fixture deployed on Ample (next build then next start -H 0.0.0.0 -p $PORT on the node-22 template); the private document library checks passed: a role-to-document access model with negative tests (401 without identity, 403 for the wrong role) and a private-bucket round-trip for the allowed role (private=ok). The blueprint's Travel operators schema and workflow below build on that verified basis and were not separately executed. (expires 2027-03-20T02:34:39Z)

## Execution binding

MCP tool `ample_deploy` (registry `mcp:ample_deploy`), schema hash `876465fce906da0c` observed 2026-09-21T03:19:59.461917+00:00 at revision `49962bcade4f`, binding state `current`, required scopes: servers:write, databases:read, buckets:read.

## Input schema

```json
{
  "additionalProperties": false,
  "properties": {
    "env": {
      "description": "Encrypted environment variables",
      "items": {
        "pattern": "^[A-Z][A-Z0-9_]*=.*$",
        "type": "string"
      },
      "maxItems": 50,
      "type": "array"
    },
    "name": {
      "description": "App name",
      "maxLength": 63,
      "minLength": 1,
      "pattern": "^[a-z0-9-]+$",
      "type": "string"
    },
    "path": {
      "description": "Project directory or ample.toml service",
      "maxLength": 512,
      "minLength": 1,
      "type": "string"
    },
    "release_command": {
      "description": "Migration command run before activation",
      "maxLength": 512,
      "type": "string"
    }
  },
  "required": [
    "env",
    "name",
    "path"
  ],
  "type": "object"
}
```

## Next actions

- Browse the catalog index (GET /v1/catalog on the api origin; auth: false, approval: false)  
- Search published recipes by intent, stack and constraints (POST /v1/catalog/search on the api origin; auth: false, approval: false)  
- Prepare a side-effect-free deployment plan for an authorized project (POST /v1/catalog/plan on the api origin; auth: true, approval: false)  
- Read the existing agent authentication setup (GET /mcp/setup on the api origin; auth: false, approval: false)  
- Browse Travel operators (GET /v1/catalog/nodes/industry%3Atravel-operators on the api origin; auth: false, approval: false)  
- Browse Vendor portal (GET /v1/catalog/nodes/workload%3Avendor-portal on the api origin; auth: false, approval: false)  
- Browse Next.js (GET /v1/catalog/nodes/stack%3Aframework-next-js on the api origin; auth: false, approval: false)  
- Browse Deploy web app (GET /v1/catalog/nodes/intent%3Adeploy-web-app on the api origin; auth: false, approval: false)

Actions describe possible next steps. They are typed data, not commands, and grant no permission.