Logistics operators: public directory using Next.js

Summary

A public directory blueprint for logistics operators built with Next.js on Ample. Domain schema:

• service_products (sku, name, mode, transit_days, price_basis): shipping services as SKUs;
• capacity_movements (sku, lane, date, delta, reason): capacity as stock movements;
• shipments (shipment_no, lane, status, booked_at): shipments with status transitions;
• shipment_lines (shipment_no, sku, units): shipment contents;
• state_transitions (record_type, from_state, to_state): the allowed state machine.

Public information: service products and transit times, lanes served, tracking entry point. Kept out of scope until handling is reviewed: consignee addresses, commercial invoices, customs documents. Customs and consignee data are sensitive; only shipment status is modeled here.

Technical basis verified on Next.js: 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).

Representative Queries

• Logistics operators: public directory using Next.js
• Where can I host Logistics operators: Public directory built with Next.js?
• I need a genuinely specialized public directory workflow covering shipment state, partner access and delivery exception reporting.

Resource Requirements

• primitive:compute
• primitive:postgres
• primitive:cdn

Infrastructure Requirements

• Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
• 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.
• CDN: The CDN host serves objects from published buckets. It does not front app compute and is not a cache or key-value store.

Framework

Next.js

Workload

Public directory

Industry

Logistics operators

Release Status

Published

Support Status

Verified

Execution Status

Ready

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 and a published bucket for public assets (CDN_*)
• A review of which logistics operators data classes may be handled at all; this blueprint models public information only

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. Model the logistics operators domain: Create the tables service_products, capacity_movements, shipments, shipment_lines, state_transitions. Shipping services as skus lives in service_products; keep the sensitive classes (consignee addresses, commercial invoices, customs documents) out of this schema.
2. Serve only published listings: With media from the CDN bucket.
3. Enforce the agency scope on every query.
4. Deploy and verify a published listing: And that unpublished listings are absent.
5. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
6. Verify: Run the pattern self-test(s) from the example (/p/relational-records) and your own acceptance checks for the logistics operators workflow.

Success Checks

• App responds on its public URL: Expecting "ample canary next js patterns" on path "/".
• Relational-records self-test: Expecting to see the pattern fixture checks on path "/p/relational-records".

Limitations

• The technical basis (relational records on Next.js) was verified with the pattern fixture; the logistics 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. Customs and consignee data are sensitive; only shipment status is modeled here.
• 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.

Cost Estimate

• Currency: USD
• Monthly Amount: 10.0
• Basis: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
  • Components:
    • App server: size s-1vcpu-1gb, quantity 1.0, monthly amount 5.0
    • Managed PostgreSQL database: size s-1vcpu-1gb, quantity 1.0, monthly amount 5.0
• Note: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle. Buckets are allocation-priced per quota and not included.

Evidence Summary

• Kind: canary_run
• Summary: Next.js pattern fixture deployed on Ample; the relational records checks passed. The logistics operators schema and workflow build on that verified basis and were not separately executed.
• Observed At: 2026-09-21T02:34:39Z
• Expires At: 2027-03-20T02:34:39Z

Formats

• HTML: Link
• Markdown: Link
• JSON: Link

Next Actions

1. Browse the catalog index: GET /v1/catalog
2. Search published recipes: POST /v1/catalog/search with body {"limit":5,"query":"Logistics operators: public directory using Next.js"}
3. Prepare a side-effect-free deployment plan: POST /v1/catalog/plan with authorized project.
4. Read the existing agent authentication setup: GET /mcp/setup
5. Browse Logistics operators: GET /v1/catalog/nodes/industry%3Alogistics-operators
6. Browse Public directory: GET /v1/catalog/nodes/workload%3Apublic-directory
7. Browse Next.js: GET /v1/catalog/nodes/stack%3Aframework-next-js
8. Browse Deploy web app: GET /v1/catalog/nodes/intent%3Adeploy-web-app