Low-operations AI product prototype — AI Stack

Components and roles

Every component earns its place.

01
Next.js application
Provides the public interface, static content, route handlers, and server-rendered paths when required.
02
Cloudflare Workers deployment path
Runs the application at the edge through the current compatible Next.js adapter.
03
Server-side model boundary
Keeps provider credentials private and applies validation, timeouts, budgets, and safe failure behavior.
04
Optional D1 and R2 bindings
Add structured records or generated artifacts only after the product flow proves the need.
05
Release and observation loop
Connects each deployment to a commit, route checks, error visibility, cost signals, and a rollback rule.

Data flow

Browser → validated application route → model provider when needed → optional D1/R2 record → user-visible result → release and error review

Default choices

Start here, then switch for a stated reason.

Next.js on Workers

vinext for a compatible new app; OpenNext for an existing app with a migration gap

Selection reason: Matches Cloudflare’s current guidance while avoiding an unverified production migration.
Switch when: Re-evaluate the adapter when compatibility, maintenance status, or application requirements materially change.

Structured persistence

No database until the flow needs durable records; D1 as the Cloudflare-native starting point

Selection reason: Avoids operating unused state while keeping a direct binding path when persistence becomes real.
Switch when: Use an existing Postgres system or another store when relational features, portability, regions, or team operations make it the better fit.

Artifact storage

No object store until files or immutable exports exist; R2 when they do

Selection reason: Keeps the first release small and separates large objects from structured records.
Switch when: Use an existing object store when data residency, tooling, or organizational standards outweigh consolidation.

Operating assumptions

Cost, privacy, alternatives, and limits.

Cost assumption: Begin with static and request-driven work. Model inference, Workers usage, storage, logs, and human review all scale separately and need explicit budgets.
Privacy boundary: Only validated task data should cross the server-side model boundary. Secrets stay in deployment configuration; durable data needs a retention and deletion owner.
Reference implementation: RichBay currently runs an existing Next.js 16 application on Cloudflare Workers through OpenNext; new applications should evaluate Cloudflare’s recommended vinext path first.
Alternatives: Use a static export when the product has no server requirements; use another host or application framework when its runtime and operating model fit the team better.
Known limitation: This stack supports a low-operations prototype. It does not by itself provide production security, model evaluation, compliance, data recovery, or product-market fit.

Human checkpoints

Keep accountable decisions visible.

Approve the one-flow scope and data boundary
Review production configuration and the exact release artifact
Verify the public version and own rollback

Evidence and sources

See what supports this record.

Used at RichBay

Last reviewed 2026-09-05. Recheck current provider documentation, limits, pricing, and terms before adoption.

Every component earns its place.

Next.js application

Provides the public interface, static content, route handlers, and server-rendered paths when required.

Cloudflare Workers deployment path

Runs the application at the edge through the current compatible Next.js adapter.

Server-side model boundary

Keeps provider credentials private and applies validation, timeouts, budgets, and safe failure behavior.

Optional D1 and R2 bindings

Add structured records or generated artifacts only after the product flow proves the need.

Release and observation loop

Connects each deployment to a commit, route checks, error visibility, cost signals, and a rollback rule.

Data flow

Browser → validated application route → model provider when needed → optional D1/R2 record → user-visible result → release and error review

Start here, then switch for a stated reason.

Next.js on Workers

vinext for a compatible new app; OpenNext for an existing app with a migration gap

Selection reason: Matches Cloudflare’s current guidance while avoiding an unverified production migration.
Switch when: Re-evaluate the adapter when compatibility, maintenance status, or application requirements materially change.

Structured persistence

No database until the flow needs durable records; D1 as the Cloudflare-native starting point

Selection reason: Avoids operating unused state while keeping a direct binding path when persistence becomes real.
Switch when: Use an existing Postgres system or another store when relational features, portability, regions, or team operations make it the better fit.

Artifact storage

No object store until files or immutable exports exist; R2 when they do

Selection reason: Keeps the first release small and separates large objects from structured records.
Switch when: Use an existing object store when data residency, tooling, or organizational standards outweigh consolidation.

Cost, privacy, alternatives, and limits.

Cost assumption

Begin with static and request-driven work. Model inference, Workers usage, storage, logs, and human review all scale separately and need explicit budgets.

Privacy boundary

Only validated task data should cross the server-side model boundary. Secrets stay in deployment configuration; durable data needs a retention and deletion owner.

Reference implementation

RichBay currently runs an existing Next.js 16 application on Cloudflare Workers through OpenNext; new applications should evaluate Cloudflare’s recommended vinext path first.

Alternatives

Use a static export when the product has no server requirements; use another host or application framework when its runtime and operating model fit the team better.

Known limitation

This stack supports a low-operations prototype. It does not by itself provide production security, model evaluation, compliance, data recovery, or product-market fit.