Adapter submission: @solcreek/adapter-creek (Cloudflare Workers for Platforms)

[linyiru]

Hello — thank you for the open governance model of this working group. Sharing our adapter for consideration alongside the existing @opennextjs/cloudflare work.

Adapter

• Package: @solcreek/adapter-creek (Apache 2.0)
• Repository: https://github.com/solcreek/adapter-creek
• Target runtime: Cloudflare Workers (via workerd)
• Next.js API: implements the stable NextAdapter interface (Next.js ≥ 16.2)

Positioning

This adapter targets a different user journey than @opennextjs/cloudflare:

	@opennextjs/cloudflare	@solcreek/adapter-creek
Deployment model	User self-hosts in their own Cloudflare account	Creek managed platform (Cloudflare Workers for Platforms tenant)
User flow	wrangler deploy + manual binding/DO setup	creek deploy (zero-config)
Cloudflare account needed	Yes	No — Creek provides the infra layer
Positioning relative to Cloudflare	Self-service tool	Managed platform, analogous to Vercel-on-top-of-AWS

We see the two as complementary: one serves teams who want direct Cloudflare control, the other serves teams who want a managed abstraction on top.

Verification criteria

• Open source — Apache 2.0, fully public repo
• Passes the full Next.js e2e deploy test suite — test/deploy-tests-manifest.adapter-creek.json is empty (no per-subtest failures, no whole-file excludes)
• CI against canary — 16-way test matrix on every manual dispatch, running the official scripts/e2e-deploy.sh contract against miniflare in-process

Latest full-matrix run: https://github.com/solcreek/adapter-creek/actions/runs/24760614935

Notable capabilities

A few things that aren't purely about passing tests but shape the adapter's feel for users:

• Opt-in multi-runtime isolation (CREEK_MULTI_WORKER=1) — emits a dispatcher + node-runtime + edge-runtime layout with runtime-label-aware routing. Off by default.
• Transparent sqlite3 compatibility — a build-time patcher swaps the native binding for a sql.js-backed shim so user code that imports sqlite3 builds and runs on workerd.
• Automatic transpilePackages detection — modifyConfig scans direct dependencies for JSX-in-.js and auto-transpiles packages that would otherwise trip Turbopack at the canary.
• Progressive-streaming fidelity — explicit Content-Encoding: identity on FL-compressed response types + a same-origin fetch() coalescer to preserve chunk boundaries through intra-worker dispatch, so RSC streams and server-action ReadableStream responses observe the intended chunk count at the client.

Questions

1. Are you open to a second Cloudflare-target adapter in the verified list, given the distinct managed-vs-self-hosted positioning?
2. If yes, what does the submission review look like in practice — any artifacts you'd like us to provide beyond what's in the repo?
3. For verified-adapters documentation listing: anything we should prepare in advance (description blurb, logo, etc.)?

Happy to answer questions or adjust anything. Thank you for the time.