Solved. product

deploy

Next.js → Cloudflare Workers at init time. Bootstrap configs, ship with a Vercel-like CLI, run on an owned Workers runtime.

Get started View on GitHub

Why deploy

Cloudflare-native from the first commit

Post-build adapters fight the framework. deploy patches your project when you start — so wrangler, bindings, and scripts match how Workers actually run.

Init-time, not post-build glue

Wire Cloudflare when you create or adopt an app — configs, deps, wrangler, and scripts — instead of bolting on an adapter after the fact.

Owned Workers runtime

Original build + runtime under @solvedgg/deploy-* packages. Not OpenNext. Not a rebrand. Gaps stay explicit in the compat matrix.

Vercel-like verbs

deploy, env, link, whoami, logs, dev, check — familiar CLI surface mapped onto Workers, Assets, KV, R2, D1, and friends.

Quick start

One binary. Familiar flow.

# greenfield
deploy create my-app --yes --name my-app
cd my-app && bun install

# existing Next app
deploy init . --name my-app
deploy check
deploy deploy

Full install & commands

Platform map

Vercel-shaped needs → Cloudflare primitives

  • App server Workers
  • Static assets Workers Assets
  • KV / edge cache KV + Cache API
  • Blobs R2
  • SQL D1 / Hyperdrive
  • Images CF Images / transform
  • Cron triggers.crons
  • AI Workers AI

Honesty

Progressive parity. Explicit gaps.

Runtime SSR climbs toward Node parity — it is not claimed at 0.0.x. Unsupported features prompt on TTY: we no do this yet, do anyway? Non-interactive fails closed unless --force.

  • 0.0.x CLI + init/create + wrangler + runtime skeleton
  • v0.1.0 ~75% Next / Vercel feature surface
  • v1.0.0 100% compat goal

See feature surface

Ship Next on Workers without the adapter tax

Build from source with Zig 0.16+, or follow the repo for published packages as they land.

Get started Features