Add Alchemy v2 Cloudflare deployment support

[kattsushi]

Requested outcome

Add an optional Infrastructure as Effects deployment path using Alchemy v2, starting with Cloudflare.

The existing behavior should remain the default. Users who do not select infrastructure should receive exactly the same generated project they receive today.

The initial Cloudflare integration should support any compatible subset of:

• one Client React Application;
• one Client Foldkit Application;
• one base Server Application.

Motivation

Stack Effect currently scaffolds runnable applications but leaves deployment and infrastructure configuration entirely to the user.

Alchemy v2 is built around Effect and already provides first-class support for:

• Cloudflare Vite websites;
• Foldkit websites;
• Effect HTTP API Workers;
• Effect RPC Workers;
• typed resource bindings;
• native stages and deployment lifecycle commands.

This creates an opportunity to provide an Effect-native deployment path without introducing a separate configuration language or treating infrastructure as an unrelated concern.

Proposed product surface

Add an optional Infrastructure as Effects selector modeled after the existing Database selector.

Initial semantic values:

• none, the default;
• cloudflare.

Future providers such as aws should remain unselectable until implemented.

The selector should appear consistently in:

• the interactive CLI;
• non-interactive CLI commands;
• Recipe Builder;
• shareable Recipe Builder URLs;
• generated commands.

The exact configuration key and flag name can be decided during design. Possible names include infrastructure, iac, or iae.

The default none value should be omitted from commands and URLs so existing output remains unchanged.

Initial Cloudflare stack

Generate one Alchemy Stack containing the compatible targets selected by the user. All three target types are optional, but the first slice should support at most one instance of each.

The generated workspace should expose root lifecycle scripts for:

infra:plan
infra:dev
infra:deploy
infra:destroy

The first release should use Alchemy native stages and workers.dev. Custom domains, DNS, and CI preview environments can follow later.

Client React Application

Deploy through:

Cloudflare.Website.Vite

Requirements:

• use the application's monorepo rootDir;
• configure SPA fallback behavior;
• preserve monorepo-aware build hashing;
• inject the deployed server URL through a public VITE_ variable when a server exists in the same stack.

Client Foldkit Application

Deploy through:

Cloudflare.Website.Foldkit

Foldkit already has explicit support in Alchemy.

The current generated Foldkit network modules use hardcoded localhost URLs. These should become environment-driven so the deployed server URL can be injected by the stack.

Server Application

The current Server Application starts a Bun or Node HTTP listener, which cannot run unchanged as a Cloudflare Worker.

Cloudflare deployment should generate a separate Worker entry while preserving Bun/Node for local development.

The Worker adapter should reuse the existing API descriptions and handler Layers, then expose a real Effect-based fetch handler using Alchemy's documented patterns:

• Effect HTTP API through HttpRouter.toHttpEffect;
• base Event RPC through the existing router composition, only if a real mixed HTTP + RPC workerd or deployed test passes.

The initial server support should be intentionally narrow:

Capability	Initial status
Base Effect HTTP API	Supported
Base Event RPC with HTTP	Supported only after real E2E evidence
RPC-only server	Unsupported
Todo/Postgres modules	Unsupported
Chat and managed chat	Unsupported
Presence/WebSocket	Unsupported
DevTools	Unsupported
MCP Server target	Out of scope

Unsupported modules should be disabled with an explanation in interactive surfaces. Persisted URLs and non-interactive recipes must fail explicitly rather than silently removing selections.

Dependency policy

Generated projects should pin an exact, revalidated Alchemy v2 version rather than depend on the moving alchemy@next tag.

The implementation will also need to align the generated Effect dependencies with the minimum version required by the selected Alchemy version.

Security and operational behavior

• Use Alchemy and Cloudflare's documented credential and state conventions.
• Never write credentials or tokens into generated source, commands, shareable URLs, stack outputs, or public VITE_ variables.
• Treat deployed endpoint URLs as public configuration, not secrets.
• Document that infra:plan, infra:dev, provider initialization, and integration tests may authenticate and create or mutate real cloud resources.
• Ensure destroy reports partial cleanup honestly rather than claiming all resources were removed.

Acceptance criteria

• Infrastructure defaults to none and existing recipes remain unchanged.
• cloudflare round-trips through CLI, Recipe Builder, URL state, and generated commands.
• Client-only, server-only, and compatible mixed subsets generate one deterministic Alchemy Stack.
• Duplicate instances of the initially supported target types are rejected.
• React deploys through Cloudflare.Website.Vite.
• Foldkit deploys through Cloudflare.Website.Foldkit.
• Foldkit network endpoints no longer require hardcoded localhost URLs.
• A base Server HTTP API responds through a real Cloudflare Worker fetch path.
• The Worker entry does not start a Bun/Node listener or depend on PORT, HOST, or runMain.
• Base Event RPC is exposed only after a real shared HTTP + RPC Worker test passes.
• Unsupported server modules are disabled interactively and rejected non-interactively.
• Generated projects expose stage-aware infra:plan, infra:dev, infra:deploy, and infra:destroy scripts while preserving the existing application dev command.
• Alchemy is pinned to an exact compatible v2 version.
• No secrets appear in generated or publicly serialized configuration.

Suggested delivery slices

1. Infrastructure selector, serialization, validation, and unchanged-none regressions.
2. Alchemy workspace core plus React and Foldkit deployment resources.
3. Cloudflare Worker adapter for the base Server HTTP API.
4. Mixed HTTP + Event RPC validation and conditional support.
5. Documentation, lifecycle guidance, and explicit cloud cleanup validation.

Follow-up roadmap

PostgreSQL infrastructure

Stack Effect currently provides an Effect Postgres application provider and local Docker Compose, but it does not provision managed PostgreSQL.

A later slice could use:

• Alchemy Neon.Project and Neon.Branch;
• deploy-time migrations;
• Cloudflare Hyperdrive;
• request-scoped Effect SQL access.

Hyperdrive should be treated as a connection/pooling resource, not as the Postgres provisioner.

AWS

After the provider model is proven with Cloudflare, a separate proposal can add AWS deployment using Alchemy's Lambda, container, and RDS resources.

Out of scope

• AWS implementation
• Neon/Postgres or D1 provisioning
• Hyperdrive bindings
• Custom domains and DNS
• CI preview environments
• Multiple instances of the same application target
• Arbitrary cross-target deployment bindings
• RPC-only servers
• MCP Server deployment
• Chat, presence, WebSocket, Todo/Postgres, or DevTools on Workers

References

• https://alchemy.run/providers/cloudflare/website/vite/
• https://alchemy.run/cloudflare/apis/effect-http-api
• https://alchemy.run/cloudflare/apis/effect-rpc
• https://alchemy.run/cloudflare/compute/workers/
• https://alchemy.run/neon/
• https://github.com/alchemy-run/alchemy

[kattsushi]

Thanks, I agree that the current PR is too broad and should not add a new infrastructure category to the core.

Rather than reducing Alchemy to a smaller built-in module, I would like to explore it as an external community addon. Infrastructure can be composed in many different ways, including Cloudflare, AWS, and other providers, much like architectural approaches such as DDD. Keeping those combinations outside the main repository could let Stack Effect remain small and deterministic while addons package opinionated, tested Effect building blocks. Over time, this could also become an agent-friendly software factory with an external community registry or marketplace.

Stack Effect does not currently expose an addon API, and I am not proposing that we design one as part of this issue or PR. I would first prototype DDD and Alchemy as standalone companion tools using the public CLI boundaries. If multiple working addons eventually reveal a small, stable extension contract, I could return with concrete evidence for a separate discussion. Would that direction be compatible with how you see the ecosystem evolving, or would you prefer these tools to remain entirely independent from Stack Effect? Either way, I will retire the current broad PR and move the experiment outside the core.