Alchemy | Blog

2.0.0-beta.85 - Effect 4.1, Domain Replay & DynamoDB State

Sun, 01 Nov 2026 09:00:00 GMT

beta.85 is 249 pull requests from 39 contributors: 84 features and 95 bug fixes.

It moves Alchemy to Effect 4.1. Alchemy Domain’s deploys now roll out every model change by replaying history, and one Domain model can be served over HTTP, MCP or the CLI, so people and agents reach it however they prefer. GCP gets redesigned Cloud Run services and containers and connects to AWS without keys. Custom domains work with any DNS provider, the Cloudflare state store takes its Worker name, account and domain, AWS state uses DynamoDB and plans 270× faster, Alchemist exposes the whole CLI as a programmatic API, and Alchemy’s test runner ships as @alchemy.run/test.

Breaking changes

Effect 4.1: bump effect and @effect/* to ^4.1.0 (below).
Cloudflare.state({ name }) is workerName, the store’s full Worker name, and --name takes the Worker name too: name: "team-a" becomes workerName: "alchemy-state-store-team-a", the same Worker and secrets (below).
AWS.state() uses DynamoDB: run alchemy state migrate, or keep S3 with AWS.state({ backend: "s3" }) (below).

Lambda event-source handlers take the Lambda event instead of a Stream, and can return a partial batch response (below):

yield* AWS.SQS.consumeQueueMessages(
  queue,
  (records) =>
    records.pipe(Stream.runForEach((record) => Effect.log(record.body))),
  queue,
  Effect.fn(function* (event) {
    for (const record of event.Records) yield* Effect.log(record.body);
  }),
);

Test.make moved to @alchemy.run/test: alchemy/Test/Alchemy is now @alchemy.run/test/Alchemy, and the same for Bun, Vitest, Core, Http and TestState (#2621).
GCP profiles: the env method is gone, and gcloud profiles name a configuration; run alchemy profile edit --reconfigure GCP (#2680).
GCP.Run.Container is now a resource; the container-spec type it named is GCP.Run.ContainerSpec (#2652).
Domain models are upgraded on the next deploy: their Durable Object classes are renamed after their model, and their data moves with them (below).
The Durable Object Domain platform and workflow engine are factories: layerDurableObjects() and layerDurableObjectEngine() (#2601).
Domain clients: bank.WithdrawMoney(target, input, options) (#2561); watch streams { state, cursor } and events ends with CaughtUp (#2579); Domain.Api takes { model } and api.entries is api.serves (#2820); testClient is clientInProcess (#2550).
Domain stories: externalSystems is stub, expectCall is call, resolve is succeed, every call needs a call step, and unasserted events fail the story (how to update).
Domain checks: a command’s target must be its aggregate’s id schema (#2563), and an adapter returning a value its schema rejects now dies (#2548).
Cloudflare DNS: foundationDns: true is nameservers: { type: "cloudflare.advanced" } (#2501).
Cloudflare.Access.Organization resets settings your stack doesn’t declare (#2291).
GCP.SQL.Instance: ipv4Enabled is ipConfiguration.ipv4Enabled, backupEnabled is backup.enabled (#2642).
GitHub: Ruleset rules are top-level props (#2582), and errors and credentials come from the distilled GitHub SDK (#2530).
Error fields named name are renamed, mostly to resourceName (#2689).
--log-ansi is removed, and telemetry no longer exports log records (#2765).

Effect 4.1

Alchemy now runs on Effect 4.1 (#2754):

bun add effect@^4.1.0 @effect/platform-node@^4.1.0

Effect 4.1 deletes effect/Crypto. Its SecureRandom and Digest services replace it, and the platform layer provides them, so StackServices changes with it:

export type StackServices =
  | FileSystem
  | Crypto
  | Digest
  | SecureRandom
  | Path

Foldkit projects need foldkit@^0.170 and @foldkit/vite-plugin@^0.29 (#2790).

Alchemy Domain

Alchemy Domain shipped 30 features this release. Thanks Taras Kornichuk, who built most of them!

Deploys roll out every change to a model

A Domain model’s views and projections are derived from its events. Change the model, and the deploy brings every consumer up to date from the history, with no script to write (#2725, #2875):

You change	The deploy
add a view or projection	feeds it every past event, in the order it was recorded
bump a view’s `version`	recomputes it, and every view and projection that reads it
bump a projection’s `version`	runs it again over the whole history
list a view as `lazy`	skips the backfill; each key fills itself on first read
add a policy	acts on new events only, so the past is never acted on twice
remove a view or projection	stops it

Adding a view is one line in the model:

// deploy 1
class Bank extends Domain.Model("Bank", { aggregates: [Account] }) {}

// deploy 2: AccountSummary folds every earlier event
class Bank extends Domain.Model("Bank", {
  aggregates: [Account],
  views: [AccountSummary],
}) {}

Changing what a view computes is a version bump:

export class AccountSummary extends Domain.View("AccountSummary", {
  from: [Account],
  key: Account,
  state: Schema.Struct({ net: Schema.Number }),
  initial: { net: 0 },
  evolve: {
    MoneyDeposited: (v, e) => ({ net: v.net + e.amount }),
    // new: applied to every past withdrawal
    MoneyWithdrawn: (v, e) => ({ net: v.net - e.amount }),
  },
  version: 1,
}) {}

The deploy picks the cheapest correct strategy. A view keyed by the one aggregate it reads is rebuilt in place: each key re-reads its own aggregate’s events the first time it’s touched, so the deploy waits for nothing. Any other view, such as a total across every account, is rebuilt from the history in new storage, and the deploy waits and reports progress:

[DomainBackfillRun] Backfilling view:Deposits reading history 41% (1,690/4,096 subtrees, 410,211 instances) (48s) ...
[DomainBackfillRun] Backfilled view:Deposits (112.4s)

Reads stay correct while new code rolls out, history.complete tells a screen when a view has caught up, and a deploy interrupted halfway picks up where it stopped.

How it scales

On Cloudflare the replay runs as Durable Objects, not on the deploying machine. Every aggregate instance lists itself in a directory on its first commit: a tree where each node holds up to 256 instances and splits into 16 children when it fills. A backfill’s root splits that directory into a few hundred subtrees and hands them to relays. A relay given more than six items splits them among six child relays. Six because a Cloudflare Worker invocation runs at most six outgoing calls at a time, so a seventh would only wait in line. The tree grows deeper instead of wider, about log₆ of the instance count: 6 levels for 10,000 instances, 8 for a million.

One path down the tree; at every level the other five relays do the same beside it. Each relay calls at most six at once, because a Cloudflare Worker invocation runs at most six outgoing calls at a time.

At the bottom, a view keyed by its aggregate reads its own instance’s events and applies them. A view that many instances feed, like a timeline, gets a scanner per instance that pushes each key its share; once every scanner has pushed, each key applies its events in the order they were recorded. Every part of the run is a class only the new code has, so nothing starts on the old code while Cloudflare rolls the deploy out.

We measured it on Cloudflare, rebuilding a view over accounts with 10 deposits each:

Accounts	Events	The deploy waited
10,000	100,000	13 s
100,000	1,000,000	58 s
1,000,000	10,000,000	8 min

Past about 100,000 accounts the limit isn’t the tree but Cloudflare’s cap on how fast one account can create and call Durable Objects. The run paces itself to that cap the way TCP does: it sends more while the account keeps up, halves when Cloudflare refuses calls, and resends the refused work. The million-account run held about 2,000 keys a second.

Docs: Consumers added later receive the history · Change a view: bump its version · Fill a view lazily · History at scale.

Alchemy upgrades your deployed model

A Domain model is more than code: on Cloudflare it is a set of Durable Object classes holding every aggregate, view row and running saga. Changing how those classes are laid out would normally mean a hand-written migration and a careful cutover. In Alchemy it’s part of the deploy.

From this release, the deployed layout is versioned. Every Worker that hosts a model records the Domain version it was deployed with, and the Worker’s reconciler upgrades older layouts on the next deploy, renaming classes in place in the same upload, so no data is copied or lost (#2560). Future layout changes ship as new upgrade steps in Alchemy, and your deploy applies them. A Worker deployed by a newer Alchemy is never moved back: an older one refuses with DomainVersionTooNew before uploading anything.

For the bank example, the first deploy with beta.85 changes the Worker like this:

Worker
  tag    (none)
  tag    alchemy:domain:v0
  class  AccountAggregate
  class  Bank.AccountAggregate
  class  OpenAccountWorkflow
  class  Bank.OpenAccountWorkflow

The renames ride in the same upload as the new code, as Cloudflare renamed_classes migrations, so every account and running saga keeps its storage and nothing is copied.

This is what DDD buys you here. Because Alchemy knows the shape of your model (its aggregates, views and sagas), it can own the infrastructure under it, and evolve that infrastructure for you the same way it evolves a view.

The first deploy with beta.85 upgrades every Worker that hosts a Domain model. Its Durable Object classes are renamed after their model, for example AccountAggregate becomes Bank.AccountAggregate, and their data moves with them.

If two models in one Worker listed the same aggregate, they shared one class and its data before this release, and the deploy fails with AmbiguousDomainLegacyData until you pick the model that keeps it:

export const BillingLive = Billing.layer(BillingHandlers, {
  legacyData: true, // Billing keeps the shared data; Audit starts empty
});

Each model now owns its data, so two models that list the same aggregate get separate instances, even in one Worker. And a model can keep all of it in a Cloudflare jurisdiction (#2601):

Layer.provide(DomainCloudflare.layerDurableObjects({ jurisdiction: "eu" }));

A jurisdiction is part of an object’s identity, so a model that already has data starts empty in its new jurisdiction, and its old objects stay where they were.

Docs: Upgrade without losing data · Keep the model in a jurisdiction.

Serve a Domain model over HTTP, MCP or the CLI

A Domain.Api names the parts of a model a client may reach (#2820):

export class BankApi extends Domain.Api("BankApi", {
  model: Bank,
  commands: ["DepositMoney", "WithdrawMoney"],
  views: ["AccountSummary"],
}) {}

Clients reach only what the Api lists. The aggregate, the policy, the projection and the external system stay inside, free to change.

The same Api can now be served to whoever needs it, through the same middleware and rejections, so an agent can do exactly what a signed-in client can and no more.

As an HTTP JSON API with an OpenAPI document, with live reads as Server-Sent Events, for partners, scripts and browsers (#2587):

const BankHttp = DomainHttp.toHttpApi(BankApi);

export const BankHttpLive = HttpApiBuilder.layer(BankHttp.api, {
  openapiPath: "/openapi.json",
}).pipe(Layer.provide(BankHttp.layer), Layer.provide(BankLive));

As an MCP server for agents, or as Effect AI tools for an agent inside your app (#2586):

export const BankMcp = DomainAi.toMcp(BankApi).pipe(
  Layer.provide(
    McpServer.layerHttp({ name: "bank", version: "1.0.0", path: "/mcp" }),
  ),
  Layer.provide(BankLive),
);

As a command-line tool, for people and agents in a terminal (#2588):

$ bank deposit-money --target a-1 --amount 1000
{ "reply": { "balance": 1000 }, "stream": "Account/a-1", "version": 1 }

$ bank withdraw-money --target a-1 --amount 5000   # exit code 1
{ "_tag": "InsufficientFunds", "balance": 1000, "requested": 5000 }

And as Foldkit commands and subscriptions for a web app (#2700).

Docs: HTTP API · MCP · CLI · Foldkit.

Stories run real adapters and show what went wrong

A story tests a model as given, when, then. Stories now tell you exactly what failed. A failing story prints every step, marked passed, failed or not run, with the events committed so far (#2475):

yield* story(
  Story.clock("2026-03-01T09:00:00Z"),
  Story.given(c1, new Incremented({ by: 2, total: 2 })),
  Story.when(c1, new Increment({ by: 3 })),
  Story.then(c1, new Incremented({ by: 4, total: 6 })),
  Story.replied({ total: 6 }),
);

StoryFailure: Then: on Counter/c-1

  ✓ 1 Clock      2026-03-01T09:00:00.000Z
  ✓ 2 Given      Counter/c-1: Incremented { by: 2, total: 2 }
  ✓ 3 When       Counter/c-1: Increment { by: 3 }
  ✗ 4 Then       Counter/c-1: expected Incremented { by: 4, total: 6 }
                              got      Incremented { by: 3, total: 5 }
    5 Replied    { total: 6 }
  events so far
    Counter/c-1: Incremented → Incremented

A story also fails on any event a command or policy committed that no step asserts, on every stream, so a side effect can’t slip past it (#2551):

StoryFailure: committed events no step asserts (assert them with then):
  Counter/c-1: Capped (from step 4)

Steps type-check against the last command, so a rejection it can’t return, or a reply it doesn’t give, is a compile error instead of a failing run (#2559):

story(
  Story.when(c1, new Increment({ by: 1 })),
  Story.rejected(new NotAnOperator()),
  // Type 'RejectedStep<NotAnOperator>' is not assignable to type
  //   '"Increment does not reject with NotAnOperator"'.
);

Time moves with Story.advance, and scheduled commands fire when they come due (#2629):

story(
  Story.when(c1, new Cap()),
  Story.then(c1, new Capped()),
  Story.advance("1 hour"),
  Story.then(c1, new Reminded()), // the scheduled reminder fired
);

Stories also changed how external systems are tested. Before, every external system a story listed was scripted, and nothing outside the model ran. Now you choose which systems to fake with stub, and the rest run for real through the adapter Layers you provide (#2477, #2481).

Either way, every call is asserted. Story.call checks what the model sent, and the next step settles how the call ended. For a stubbed system, that step supplies the answer. For a real one, it checks the answer the adapter gave:

// FraudCheck is stubbed: the story supplies its answer
Story.call(FraudCheck.score, { accountId: account.id, amount: 60_000 }),
Story.succeed(FraudCheck.score, { risk: 0.95 }),

// Payments runs for real: the story checks what the adapter returned
Story.call(Payments.refund, { settlementId: "st_1", amount: 500 }),
Story.returned(Payments.refund, { refundId: "re_st_1" }),

	Stubbed (`stub: [...]`)	Real (adapter Layer provided)
what was sent	`Story.call`	`Story.call`
success	`Story.succeed` supplies the value	`Story.returned` asserts the value
declared error	`Story.fail` supplies it	`Story.failed` asserts it
defect	`Story.die` supplies it	`Story.died` asserts it

A real call that no step asserts fails the story, so nothing an adapter does goes unchecked. Supplied answers are checked against the operation’s schemas, like a real adapter’s (#2548), and a story that leaves a system unstubbed requires its adapter Layer in its type:

const story = Story.make(Bank, { layer: BankHandlers, stub: [FraudCheck] });

it.effect("refunds through the real payments adapter", () =>
  story(
    Story.when(
      account,
      new RecordSettlement({ settlementId: "st_1", amount: 500 }),
    ),
    Story.then(
      account,
      new SettlementOnClosedAccount({ settlementId: "st_1", amount: 500 }),
    ),
    Story.call(Payments.refund, { settlementId: "st_1", amount: 500 }),
    Story.returned(Payments.refund, { refundId: "re_st_1" }),
  ).pipe(Effect.provide(StripePayments)), // required: Payments isn't stubbed
);

Update your stories

Rename the options and steps:

const story = Story.make(Bank, {
  layer: BankHandlers,
  externalSystems: [FraudCheck, Payments],
  stub: [FraudCheck, Payments],
});

story(
  Story.when(account, new WithdrawMoney({ amount: 60_000 })),
  Story.expectCall(FraudCheck.score, { amount: 60_000 }),
  Story.resolve(FraudCheck.score, { risk: 0.95 }),
  Story.call(FraudCheck.score, { amount: 60_000 }),
  Story.succeed(FraudCheck.score, { risk: 0.95 }),
);

Then fix what the stricter checks now catch:

Every call needs a Story.call step, stubbed or real. Before, a bare resolve answered the only pending call; now each answer follows the call that checks what was sent.
List every system you want faked in stub. A system left out runs for real, and the story’s type requires its adapter Layer.
Assert every committed event. A story fails on events no then asserts, including ones a policy writes on other instances. Add a Story.then for each.
Answer with values the schema accepts. A stubbed answer the operation’s success schema rejects now fails the policy.
Move the clock forward only. A Story.clock earlier than the current time, or a string that isn’t a time, now fails the story (#2564).
Use clientInProcess for Api tests. CustomerApi.testClient is now CustomerApi.clientInProcess (#2550).

Docs: Story · Answer outside systems · Assert real calls.

GCP

Cloud Run services and containers, redesigned

A Cloud Run service runs one or more containers in each instance. The first takes requests, and the rest run beside it on localhost. Cloud Run in Alchemy was rebuilt around that model. Any container can be an image or your own Effect program, and a container lists or binds the ones it needs (#2644, #2652, #2654, #2657).

One container

A service starts as a single image:

alchemy.run.ts

import * as Alchemy from "alchemy";
import * as GCP from "@alchemy.run/gcp";
import * as Effect from "effect/Effect";

export default Alchemy.Stack(
  "MyApp",
  { providers: GCP.providers(), state: GCP.state() },
  Effect.gen(function* () {
    const proxy = yield* GCP.Run.Service("Proxy", {
      template: {
        containers: [
          {
            image: "us-docker.pkg.dev/cloudrun/container/hello",
            ports: [{ containerPort: 8080 }],
          },
        ],
      },
    });
    return { url: proxy.uri };
  }),
);

Add a sidecar

GCP.Run.Container declares a container as a resource. List it after the first one, and dependsOn holds the proxy back until the cache passes its startup probe:

Effect.gen(function* () {
  const cache = yield* GCP.Run.Container("Cache", {
    image: "docker.io/library/redis:7-alpine",
    port: 6379,
    startupProbe: { tcpSocket: {} },
  });
  const proxy = yield* GCP.Run.Service("Proxy", {
    template: {
      containers: [
        {
          image: "us-docker.pkg.dev/cloudrun/container/hello",
          ports: [{ containerPort: 8080 }],
          dependsOn: [cache.name],
        },
        cache,
      ],
    },
  });
  return { url: proxy.uri };
}),

A plain container spec works in the list too. Every container takes startupProbe, livenessProbe and dependsOn.

Run your own program

Give the service main and an Effect, and Alchemy bundles your program into the first container. An Effect service binds its sidecars instead of listing them. bindPort adds the Cache to the revision, makes the service wait for it, and returns its address:

src/api.ts

import * as GCP from "@alchemy.run/gcp";
import * as Effect from "effect/Effect";
import * as HttpServerResponse from "effect/http/HttpServerResponse";

export const Cache = GCP.Run.Container("Cache", {
  image: "docker.io/library/redis:7-alpine",
  port: 6379,
  startupProbe: { tcpSocket: {} },
});

export default class Api extends GCP.Run.Service<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const cache = yield* GCP.Run.bindPort(Cache, 6379);
    // cache.url === "http://localhost:6379"
    return {
      fetch: Effect.succeed(HttpServerResponse.text("hello")),
    };
  }),
) {}

Run your own program in a sidecar

A Container with main runs your Effect program in its own image. Its methods become a typed client for whoever binds it, called over localhost, streams included. A program Container binds sidecars of its own:

src/worker.ts

import * as GCP from "@alchemy.run/gcp";
import * as Effect from "effect/Effect";
import * as Stream from "effect/Stream";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import { Cache } from "./api.ts";

export default class Worker extends GCP.Run.Container<Worker>()(
  "Worker",
  {
    main: import.meta.url,
    port: 3000,
    startupProbe: { httpGet: { path: "/health" } },
  },
  Effect.gen(function* () {
    const cache = yield* GCP.Run.bindPort(Cache, 6379);
    return {
      greet: (name: string) => Effect.succeed(`hello ${name}`),
      count: () => Stream.make(1, 2, 3),
      fetch: Effect.succeed(HttpServerResponse.text("ok")),
    };
  }),
) {}

The service binds the Worker with bindContainer and calls its methods:

src/api.ts

import Worker from "./worker.ts";

export default class Api extends GCP.Run.Service<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const cache = yield* GCP.Run.bindPort(Cache, 6379);
    const worker = yield* GCP.Run.bindContainer(Worker);
    return {
      fetch: Effect.succeed(HttpServerResponse.text("hello")),
      fetch: worker.greet("sam").pipe(Effect.map(HttpServerResponse.text)),
    };
  }),
) {}

Bindings chain, so one revision now runs three containers and starts them in order:

revision
├── start Cache  → TCP :6379
├── start Worker (dependsOn Cache)  → GET :3000/health
├── start Api    (dependsOn Worker) → GET :8080/health
└── Ready → traffic to Api

A service that runs an image lists its containers; a service or Container that runs your program binds them, which gives it a client and orders startup for it.

Docs: Sidecars · Cloud Run.

Call private Cloud Run services

InvokeService calls the methods of a private Cloud Run service, signed with the caller’s ID token, with types taken from the service class (#2653):

export default class Quotes extends GCP.Run.Service<Quotes>()(
  "Quotes",
  { main: import.meta.url }, // the IAM invoker check stays on
  Effect.gen(function* () {
    return {
      quote: (symbol: string) => Effect.succeed({ symbol, price: 42 }),
      ticks: (symbol: string) => Stream.make(41, 42, 43),
    };
  }),
) {}

// in another service
const quotes = yield* GCP.Run.InvokeService(Quotes);
const { price } = yield* quotes.quote("GOOG");

Pass an Effect RPC schema or an HttpApi api to InvokeService or bindContainer for a client with typed errors, and serve it with ServeRpc or ServeHttpApi (#2654):

const tasks = yield* GCP.Run.InvokeService(TaskBackend, { schema: TaskRpcs });
// Effect<Task, TaskNotFound | …>
const task = yield* tasks.getTask({ id: "t1" });

A service that returns methods but turns off the invoker check fails to deploy, so RPC methods are never public by accident.

Docs: Call it from another service · Run it as a sidecar.

Connect AWS and GCP without keys

A GCP binding on a Lambda, ECS task, EC2 instance or App Runner service no longer creates a service account key. The host’s IAM role impersonates the service account through workload identity federation (#2648). Your code doesn’t change:

export default Worker.make(
  { main: import.meta.url, functionUrl: true },
  Effect.gen(function* () {
    const publish = yield* GCP.PubSub.Publish(yield* Events);
    return {
      fetch: publish({ body: { messages: [{ data: btoa("hello") }] } }).pipe(
        Effect.as(HttpServerResponse.text("published")),
      ),
    };
  }).pipe(Effect.provide(GCP.PubSub.PublishHttp)),
);

WorkerServiceAccount         GCP.IAM.ServiceAccount
WorkerServiceAccountKey      GCP.IAM.ServiceAccountKey
AwsWorkloadIdentityPool      GCP.IAM.WorkloadIdentityPool
AwsWorkloadIdentityProvider  GCP.IAM.WorkloadIdentityProvider
WorkerWorkloadIdentityUser   GCP.IAM.Member

The other direction works the same way: Cloud Run and Cloud Functions assume their AWS role with a Google ID token, with no IAM user or access key (#2645). WorkloadIdentityPool and WorkloadIdentityProvider are resources too, for keyless CI from GitHub Actions or any OIDC issuer (#2130).

Docs: GCP federated identity · AWS federated identity.

Migrations on Cloud SQL, AlloyDB and Spanner

Every GCP SQL database applies migrations on deploy, like D1, Neon, PlanetScale, Turso, RDS and DSQL (#2651):

const db = yield* GCP.SQL.Database("App", {
  instance: instance.instanceName,
  migrations: "./migrations",
  migrationsUser: user.userName,
  migrationsPassword: password.text,
});

Cloud SQL runs them over its data API by default, which needs no network route, or through the Cloud SQL connector. Spanner resumes a failed migration at the statement that failed. GCP.SQL.Instance can now be private-IP only, with SSL mode and backup retention in the stack (#2642), and Pub/Sub subscriptions write straight into BigQuery (#2213). Thanks Lucas Duailibe!

Docs: Cloud SQL.

A GCP profile signs in through a named gcloud configuration, the way an AWS profile uses aws sso login (#2635, #2680):

gcloud auth login --configuration=work
alchemy profile edit --add GCP --method gcloud --set configuration=work

alchemy profile edit --add GCP lists your configurations, or creates one and opens the browser. Each run asks gcloud for a fresh token, and nothing is copied into the profile. Signed in as yourself, you can also create projects without an organization or folder (#2616).

Docs: GCP credentials.

Custom domains with any DNS provider

A custom domain’s DNS no longer has to live with the platform that serves it. domain.dns names the DNS provider that holds the records, on every platform (#1888):

yield* AWS.Lambda.Function("Api", {
  main: "./src/handler.ts",
  domain: {
    name: "api.example.com",
    dns: Cloudflare.DNS.Adapter(),
  },
});

yield* Cloudflare.Worker("Web", {
  main: "./src/web.ts",
  domain: {
    name: "app.example.com",
    zoneId: saasZone.zoneId,
    cnameTarget: fallback.origin,
    dns: AWS.Route53.Adapter(),
  },
});

yield* Fly.Website.Vite("Docs", {
  domain: {
    name: "docs.example.com",
    dns: Hetzner.DNS.Adapter(),
  },
});

Alchemy publishes whatever the platform asks for: certificate validation records, ACME challenges, verification TXTs and aliases. Cloudflare, Route 53 and Hetzner adapters ship today, and an adapter for another DNS provider is three functions. Thanks Dan Myles and bjorntechTobbe!

Docs: DNS adapters.

Cloudflare State Store v8

The Cloudflare state store is now deployed with direct API calls instead of a stack, as state store v8, and you choose its Worker name, account and domain (#2385).

Choose the Worker name

workerName sets the store’s Worker name. Without it, you get the same default store as before:

state: Cloudflare.state({ workerName: "team-a-state" }),

It replaces name, which prefixed the Worker name with alchemy-state-store-. A store you named that way keeps its Worker and secrets when you pass the full name:

Alchemy.Stack(
  "MyApp",
  {
    providers: Cloudflare.providers(),
    state: Cloudflare.state({ name: "team-a" }),
    state: Cloudflare.state({ workerName: "alchemy-state-store-team-a" }),
  },
  Effect.gen(function* () {}),
);

--name takes the Worker name too:

alchemy state list --backend cloudflare --name alchemy-state-store-team-a

Pin the account and serve it on your domain

Pin the account so a login against another one can’t read or deploy the store there, and serve it on a hostname in one of your zones for networks that can’t reach workers.dev:

state: Cloudflare.state({
  accountId: "c8eeff0e...",
  domain: "alchemy-state.example.com",
}),

Upgrade from v7

Your next alchemy deploy asks to upgrade the store. In CI, pass --yes, or upgrade it ahead of time:

alchemy state bootstrap

The upgrade keeps the store’s auth token, encryption key and state, and only ever creates a secret that’s missing, so a deploy can’t rotate the token or replace the key. A store that has lost its key isn’t given a new one unless you confirm.

Docs: Cloudflare state store · More than one store.

AWS state now uses DynamoDB and plans 270× faster

AWS.state() keeps state in one on-demand DynamoDB table per account and region, and a deploy loads the stage with one Query (#2683, #2691):

	S3	DynamoDB
plan, 250 resources	21.6 s	0.08 s
unchanged redeploy, 1,000 resources	195 s	0.5 s
destroy, 1,000 resources	162 s	12.5 s

Existing stages move with one command. Older Alchemy versions are fenced out of the S3 copy, and nothing in S3 is deleted:

$ alchemy state migrate
my-app/prod: migrated (42 records)

$ alchemy state migrate --rollback   # back to S3, before downgrading

Docs: AWS state store · Migrating from S3.

Alchemist: the Alchemy CLI as a programmatic API

The alchemy CLI is now a thin layer over alchemy/Alchemist. Everything it does (plan, apply, drift, nuke, logs, state) is one call you can make from your own program, and every step is a typed event you can handle (#2765):

import * as Alchemist from "alchemy/Alchemist";

const program = Effect.gen(function* () {
  const plan = yield* Alchemist.plan({
    stack: Stack,
    operation: "deploy",
    stage: "prod",
  });
  if (Alchemist.hasChanges(plan)) yield* Alchemist.apply(plan);

  const scan = yield* Alchemist.Drift.scan({ stack: Stack, stage: "prod" });
  if (Alchemist.Drift.hasDrift(scan)) yield* Alchemist.Drift.execute(scan);
}).pipe(
  Alchemist.onEvent((event) => Effect.log(event.type)),
  Effect.provide(Alchemist.layer()),
  Effect.scoped,
);

Build your own CLI, a deploy bot or a CI step on the same API the alchemy command uses. Every run also writes one NDJSON log under .alchemy/log/, child processes and sidecars included. Thanks Rahul Mishra!

Docs: CLI API.

@alchemy.run/test: a test runner for Effect

Alchemy’s own test runner is now on npm as @alchemy.run/test (#2452). It is small and built only for Effect: tests are Effects, and every test file runs in one bun process, with files and tests in flight at once.

bun add -d https://pkg.alchemy.run/@alchemy.run/test/pr:2930:a10573e effect
bunx alchemy-test

import { describe, expect, it } from "@alchemy.run/test";
import * as Effect from "effect/Effect";

const charge = (amount: number) => Effect.succeed(amount > 5000 ? 402 : 200);

describe("Checkout", () => {
  it.live("charges the card", () =>
    Effect.gen(function* () {
      yield* Effect.log("POST /charges { amount: 9000 }");
      const status = yield* charge(9000);
      if (status !== 200) {
        yield* Effect.logError(`payment provider returned ${status}`);
      }
      expect(status).toBe(200);
    }),
  );
});

It prints one line per test as it finishes, with a running count, so you can follow a long run as it goes. Each test’s stdout and stderr are buffered on their own. A passing test’s output stays quiet; a failing test prints its error and its output at once, in one piece, never interleaved with tests running beside it. The last line links one log file holding every test’s output, passes included:

running 4 tests from 1 files

[1/4 ✓1 ✗0] ✓ test/Checkout.test.ts > Checkout > adds an item to the cart (1ms)
[2/4 ✓2 ✗0] ✓ test/Checkout.test.ts > Checkout > applies a discount (151ms)
[3/4 ✓2 ✗1] ✗ test/Checkout.test.ts > Checkout > charges the card (0ms)
  AssertionError: expected 402 to be 200
      at <anonymous> (test/Checkout.test.ts:21:42)
--- captured output ---
POST /charges { amount: 9000 }
payment provider returned 402
--- end output ---
[4/4 ✓3 ✗1] ✓ test/Checkout.test.ts > Checkout > sends a receipt (82ms)

Tests: 1 failed | 3 passed (1 files, 250ms)

Full log: .alchemy/log/test/2026-11-02T19-02-29-pid37920.log (2.6 KB)

That last line is there for agents. An agent running the suite reads the log to see what happened in any test, without piping output to a file or running the tests again. When nothing finishes for 10 s, the runner lists the tests still running and how long each has taken, so a hang names itself.

--stage <name> gives each git worktree its own stage, so agents in parallel worktrees test against one cloud account without colliding (#2613). Test.make, which deploys a stack for a test file, lives in the same package and works with bun test and Vitest too.

Docs: Test harness · Worktrees.

Lambda aliases, streaming and partial batch failures

alias publishes a version on each deploy and routes every event source, URL and integration through it, so a rollback is one update-alias call (#2504):

export default class Api extends AWS.Lambda.Function<Api>()(
  "Api",
  { main: import.meta.url, alias: "live", functionUrl: true },
  Effect.gen(function* () {
    yield* AWS.SQS.consumeQueueMessages(jobs, processJob); // → api:live
    return { fetch: handleHttp }; // URL on qualifier "live"
  }),
) {}

SQS, Kinesis and DynamoDB Streams handlers receive the Lambda event and can return its batch response, so only the failed records are retried (#2508):

yield* AWS.SQS.consumeQueueMessages(
  queue,
  Effect.fn(function* (event) {
    const failed = yield* Effect.filter(event.Records, (record) =>
      handle(record.body).pipe(
        Effect.as(false),
        Effect.catchCause(() => Effect.succeed(true)),
      ),
    );
    return {
      batchItemFailures: failed.map((r) => ({ itemIdentifier: r.messageId })),
    };
  }),
);

A RESPONSE_STREAM Function URL streams an Effect response body instead of buffering it (#2502), and a handler that runs past its timeout is interrupted, so finalizers run and telemetry flushes before Lambda kills the sandbox (#2682):

timeout: Duration.seconds(30), // handler interrupted at 30 s
timeoutMargin: Duration.seconds(2), // Lambda configured for 32 s

Docs: Lambda.

95 bug fixes

Most of this release is fixes, many found by new test suites rather than by users. About 900 provider failures that were a plain Error are now tagged errors you can catch (#2711), and ECR images hash only what .dockerignore keeps, so hashing a large repo dropped from 344 s to 8 s (#2351).

One conformance suite for every workflow engine

Every WorkflowEngine implementation now runs the same 28-case conformance suite: the Durable Object engine, Cloudflare Workflows and Lambda durable functions (#2916). The cases cover results, idempotent starts, durable sleeps, signals, compensations, defects, retries, interrupts and child workflows. The suite found 12 of the 15 engine bugs fixed in this release, including:

Sleeps ran later on every hop, because wake-ups inherited the Durable Object alarm’s retry backoff. Four one-second sleeps took over 45 s; they now take about 4 s.
A repeated or late signal hung for three minutes, then died.
An interrupt sent right after start was dropped, or stopped the run without running its compensations.
Activity.retry saw attempt 1 on every retry.
Activity.raceAll hung forever on the two engines that can’t support it; it now fails at once and points to the Durable Object engine.

Drift only reports real changes

alchemy drift now sees every setting that Lambda, DynamoDB, S3, SQS, EventBridge, Step Functions, WAF, ELB, ECS and EC2 networking manage, so a change made in the console shows up (#2661, #2705). Untouched resources no longer show up as drifted (#2496, #2169, #2647):

$ alchemy deploy && alchemy drift
[Api] drifted
[Db] drifted
Plan: no changes

--repair recreates deleted resources in dependency order (#2495), and EC2 creates are idempotent, so a retry never launches a second instance (#2598). Thanks DivMode, Gjermund Garaba and Ahmed Hesham!

Deploys never take over a resource they don’t own

A resource in a dependency cycle checks ownership before it’s created, so it can’t overwrite a Worker or Lambda someone else owns (#2195, #2620).
A replacement is refused before it touches anything when its new name belongs to someone else (#2200).
Recovering an interrupted create never deletes a same-named resource by guessing (#2199, #2534).
A ref to a resource in the same stack is a dependency, so destroy no longer races it (#2913).
alchemy destroy plans from state without running your program, so a dev stage tears down without cloud credentials (#2491).

Thanks Nacho Vazquez!

Cloudflare

A secret removed from a Worker’s env is unbound instead of staying live forever (#2327).
forceDestroy deletes an R2 bucket holding unfinished multipart uploads (#2537).
A new container-backed Durable Object deploys in one pass, and a local-only Container image works (#2342, #2922).
Preview Workers keep json bindings and JWKs as written (#2127), and two async Workers can bind each other (#2681).
The login picker lists every account, not the first 20 (#2902), and a Secrets Store with more than 20 secrets finds them (#2443).

Thanks Patt O’Brien, Drew Powers, Andoni Enriquez and Harry Solovay!

Local dev

A Vite app with publicDir: false no longer serves files from your machine through ASSETS (#2615), and the Bun RPC sidecar listens on loopback only (#2845).
Vite plugins and server.proxy keep their own WebSockets (#2516), and large responses behind a local reverse proxy aren’t truncated (#2841).
alchemy dev runs on NixOS with dev.workerd or ALCHEMY_WORKERD_PATH (#2791), and Docker is contacted only for Workers with containers (#2784).
Concurrent processes on one OAuth profile no longer revoke it (#1923).

Thanks Yanqi Zong and 0xMilkEnjoyer!

Also in this release

Alchemy Domain

Aggregate.predict runs a command’s rules on the client, so a UI shows the outcome before the server answers (#2568), and View.snapshot returns state with the cursor to follow it live from (#2567). Docs.
Views, projections and policies can be keyed by a Schema value instead of an aggregate (#2554), and a scheduled command can be cancelled with unschedule (#2547).
External system calls are checked against their schemas, and an operation can declare several errors (#2548, #2553).

Cloudflare

codeUpdateStrategy sets how running Durable Objects move onto new code (#2863). Docs.
Workers import any file through rules (#2792), and Flagship flags evaluate locally in alchemy dev (#2746).
consumeNotifications handles Cloudflare alerts in code, and Effect logs reach Workers Logs at their own level (#2519).
Workflows, Queues and R2 buckets take a jurisdiction (#2734, #2538, #2758), and Email Routing takes subdomains and subaddressing (#2762).

AWS

Smaller runtime bundles: a Lambda ships 0.51 MB instead of 1.30 MB, minified with source maps (#2492).
EventBridge.Endpoint global endpoints, regional NAT gateways, and Auto Scaling by instance attributes (#2507, #2498, #2817).

Tooling

Docker builds take args and BuildKit secrets, and Docker.Container takes hardening options (#2225, #2623).
Drizzle 1.0 rc.5 asks rename-or-create questions during plan (#2433).
Command.Dev takes a port or waits for its URL (#2750). Docs.
A stack can declare its stages, so a misspelled stage is a type error (#2131).

See the CHANGELOG for every other change, and thanks to everyone who contributed.

Where to go next

Alchemy Domain · Backfill · HTTP API · MCP · CLI
Cloud Run · Sidecars · GCP federated identity · GCP credentials
DNS adapters · State stores · Lambda · CLI API
Compare v2.0.0-beta.84 → v2.0.0-beta.85

Hillclimbing distilled

Sat, 24 Oct 2026 16:00:00 GMT

Every Alchemy resource talks to its cloud through distilled, our Effect-native SDKs covering 88 providers. Bindings use it too: under the hood, a binding makes HTTP calls to the cloud’s API, so every Worker or Lambda with a binding bundles distilled.

That puts distilled’s size in every deploy and every bundle, and until recently it was heavy: one API call bundled to 57 KB, and importing all of AWS took 227 MB of memory.

So we hillclimbed it. We built a benchmark for every SDK, put it on a dashboard, and pointed an agent at it with one job: make every number go down. It ran the benchmark after every change, kept what helped and dropped what didn’t. Over 123 commits and 84 benchmark runs, a single call’s bundle shrank by a third and importing all of AWS went from 227 MB to 13.9 MB.

Distilled today vs distilled before this work

−33%bundle size57.1 → 38.3 KB gzip
−79%added latency per call19.5 → 4.0 µs
−74%import memory2.15 → 0.57 MB
16×less memory to import all of AWS227 → 13.9 MB

These are medians over 98 “programs”: one credentials layer plus one operation, for every SDK and every wire protocol it uses. Here is how that compares with the official SDKs today:

Distilled vs the official SDKs

official SDKdistilled

AWS SDK v36 calls

cloudflareworkers.scripts.list

@google-cloud/storagegetBuckets

Bundle size

Bundle size2.6×smaller

Bundle size2.2×smaller

Bundle size6.0×smaller

Added latency

Added latency5.8×faster

Added latency5.1×faster

Added latency108.9×faster

Import memory

Import memory3.3×less

Import memory23.5×less

Import memory7.5×less

Cold start

Cold start2.0×faster

Cold start3.0×faster

Cold start1.2×faster

Distilled compared with each official SDK, same call on both sides. Hover a cell for the numbers. Cold start is import plus the first call in a fresh process, bundled as deployed.

How we kept score

We can’t make AWS or Cloudflare faster, only the SDK in front of them, so real API calls would only add noise. Effect helps here: every distilled request goes through the HttpClient service, so the benchmark swaps in a fake one that answers instantly:

const MockHttp = Layer.succeed(
  HttpClient.HttpClient,
  HttpClient.make((request) =>
    Effect.succeed(
      HttpClientResponse.fromWeb(request, new Response(canned.body, canned)),
    ),
  ),
);

That leaves only distilled’s own cost: bundle size, added latency per call, import memory and a few more. Each one is measured twice. The second time turns on strict mode, where distilled checks every response against the API spec before your code sees it, so a missing or mistyped field fails right away as a typed error. Strict mode costs time and bytes, so it gets its own dotted line on the charts.

Of all those numbers, memory mattered most to us. It matters for your Workers and Lambdas, but it also limits how we build Alchemy itself. Our resource factory runs many agents at once, and each one type-checks, imports every provider and runs live tests. On our machines memory runs out before CPU does, so halving the heap lets us run about twice as many agents.

Every run lands on a dashboard that lives in the distilled repo, one dot per commit, so each chart reads like a loss curve. The benchmarks now run on every distilled PR too, so a regression shows up before it merges.

The whole project came down to one dashboard and one chat thread. With every change on a chart, we could follow the work without reading a single diff. Our job became checking in every 30 minutes or so: is it still on track, and are the changes extreme enough? They often weren’t. The rest of this post climbs from the fixes any reviewer would approve to the ones that only happened because we kept telling the agent to get weirder.

How we said it mattered. The louder and stranger our messages got, the bolder the ideas the agent came back with. Each section below opens with a real message from the thread, typos included.

Runtime memory · median per program · lower is betterImport heap: V8 heapUsed after importing the SDK modules, minus before (fresh Node, Effect preloaded).

normalstrict

The sane fixes

hillclimb optimizing bundle size and memory footprint; be ambitious, dont be afraid to boil the ocean

This part you can get by just telling an agent to optimize. It follows the worst number on the dashboard back to its cause, fixes it, runs the benchmark again, and repeats. That loop never stopped. It kept running in the main thread the whole time, even while other agents went off to try much stranger ideas, which we’ll get to.

Small imports with big bills

The single worst line was in a tiny file:

import { Effect, Predicate } from "effect";

In a bundler that’s fine. In Node, importing from the effect package root loads every Effect module, and that line cost 3.3 MB and 36 ms on every import of every SDK. Importing effect/Effect and effect/Predicate directly fixed it. That’s how the Effect team recommends importing anyway, and the Effect language service has a rule for it (importFromBarrel). We just don’t run it on generated code. The same pattern hid in smaller places: effect/Config for a few environment variables, Schedule for retries, Stream.flatMap for pagination. Each now has a small replacement in core, and your own ConfigProvider or Schedule still works.

Heap this line adds0 KB

Modules loaded0

Import time0 ms

effect · 138 modules

needed not needed

One `/@PURE/` does not cover its arguments

A bundle with only EC2’s describeRegions still kept 1,695 schemas. The generator marked each top-level call /*@__PURE__*/, but that marker only covers the outer call. The calls in its arguments still count as side effects, so the bundler keeps everything they reference:

// Foo is never used, so the bundler tries to drop it.
const Foo = /*@__PURE__*/ S.Struct({ // dropped: marked pure
  items: S.Array(Big.pipe(S.optional)), // unused, but kept: not marked
});

The generator now marks every nested call too, so the whole thing goes:

const Foo = /*@__PURE__*/ S.Struct({
  items: /*@__PURE__*/ S.Array(/*@__PURE__*/ Big.pipe(S.optional)),
});

The EC2 bundle dropped from 137 KB to 75 KB.

A tree-shaking bug in rolldown

Every program that made an HTTP call kept about 15 KB gzip of Effect Schema, even ones that never validated anything, because of one rarely used class in Effect’s HTTP client. Rolldown 1.2.5 and 1.2.6 failed to tree-shake it, and 1.2.7 fixed that. That one upgrade is the cliff in this chart:

Bundle size · median per program · lower is betterMinified rolldown bundle of a program that sets up auth and calls 1 operation, gzip -9.

normalstrict

At this point the agent said the numbers looked good and suggested stopping. Every agent does this. It finds the safe wins, reports them, and waits.

Stranger, but defensible

Okay can you keep improving, we want all of these wayyyy wayyyy lower. Do insane stuff, hillclimb the f*** out of this

The sane fixes left the numbers better, but still far from where we wanted them. So every time the agent reported progress, we asked for something bigger and stranger, and fed it hunches we couldn’t prove yet: that the specs were full of duplicate shapes, and that schemas were most of the cost. The agent measured each hunch first, then turned the ones that held up into code.

One em dash doubles a module’s memory

V8 keeps every module’s source text in memory. If one character is outside Latin-1, it stores the whole file at two bytes per character. Escaping three characters in S3’s module cut its import memory from 2,240 KB to 1,570 KB. Shipped code is now Latin-1 only, and a test enforces it.

The same schema, thousands of times

API specs are repetitive. Stripe alone has 12,529 named shapes, and most of them are copies: dozens of enums that are all just “a string”, empty response objects, and the same struct redeclared on every endpoint. Each copy became its own object at import.

The generator now keeps one of each. Comparing shapes field by field breaks down when shapes refer to themselves, so it uses the algorithm compilers use to shrink state machines, partition refinement: assume everything of the same kind is the same, then keep splitting groups until every member of a group points at the same groups. A split can make the shapes that point at it split in the next round, so changes ripple up one level at a time. Shapes that only point at themselves never split, so recursion just works. Stripe went from 12,529 shapes to 2,720, and its import memory from 9.9 MB to 0.86 MB.

15 schemas

Stripe 12,529 → 2,720Cloudflare Workers 2,643 → 491EC2 3,851 → 2,553

Made-up schemas above · real services below

Faster calls

Every call used to run as a generator, with one yield* per step:

Effect.gen(function* () {
  const protocol = yield* Protocol;
  const client = yield* HttpClient.HttpClient;
  const request = yield* protocol.encode({ input, inputAst, config });
  const response = yield* client.execute(request);
  return yield* protocol.decode({ response, outputAst, errors, config });
});

Each yield* is a trip through Effect’s runtime, and encode and decode were generators too. Now, on the first call of an operation, the protocol compiles a plan for its schemas: which fields go in the path, the query and the body. Every later call builds the request from that plan with plain JavaScript, sends it, and decodes the same way. The only effect left in the middle is the HTTP request.

This is added latency per call across the whole project. The strict line took longer to come down, for reasons the next section explains.

Runtime speed · median per program · lower is betterAdded latency: p50 of a call against a mocked HTTP response minus p50 of a bare mocked round trip.

normalstrict

Faster, smaller AWS signing

AWS also signs every request, and signing was the single most expensive part of an AWS call. SigV4 used to take six async WebCrypto steps, each one a promise round trip. Switching to synchronous hashing with node:crypto alone took S3 listBuckets from 352 µs to 149 µs of added latency, DynamoDB listTables from 218 µs to 103 µs and STS getCallerIdentity from 282 µs to 125 µs. Preparing keys once and building the canonical request without parsing URLs took the rest. S3 listBuckets now adds 19.4 µs. A side-by-side check of 33,798 cases across 24 AWS services gave identical requests and results.

Synchronous hashing has a trade-off: it blocks the event loop while it runs. For a request, that’s a few microseconds of hashing, less than one async round trip, which also costs a trip through the event loop and evicts whatever was in the CPU cache. A huge request body is where blocking would start to matter. The hashing goes through a swappable Crypto service, so runtimes without Node use WebCrypto, and you can plug in your own.

We also pulled the signer out into its own small package, @distilled.cloud/aws4signer. Cloudflare R2 speaks the S3 API and needs SigV4 signing too, so code that signs R2 requests no longer pulls in the rest of the AWS SDK.

Where that left us

Before the big rewrites started, the numbers already looked like a finished project. Compared with where we began, added latency per call was down from 17.3 µs to 10.7 µs, and import memory from 2.10 MB to 0.84 MB. Most people would stop here.

The bundle barely moved, though: 57.0 KB to 54.0 KB. Every program still carried Effect Schema, whether it validated anything or not. To fix that, we had to stop tuning distilled and start replacing parts of it.

Experiments, and our own schema library

experiments should be radical shifts boiling the ocean; ambitious sh*t; agents are phenomenal and can do extreme things

The biggest wins came from ideas that might not work, and trying one can take a long time. If the one agent doing the work stops to try it, everything else stops too. So we told it to keep the main thread on the slowest number and hand radical ideas to new agents. That split the work into three roles that run at the same time:

The main thread hillclimbs. It runs the benchmark after every change, picks the worst number, and fixes it with small, safe commits. Along the way it writes down the wild ideas it doesn’t have time for.
Subagents chase the wild ideas. Each one gets its own worktree and one idea: lazy error classes, bundling each SDK into a few files, rewriting the AWS call path, Node-only service stubs. It builds the idea for real and benchmarks it as an experiment against the current head. The dashboard keeps experiments off the timeline and shows each one next to its baseline.
The main thread merges what worked. An experiment that beats its baseline without regressing anything else gets merged. One that doesn’t stays behind as a data point, so nobody tries it again.

An experiment is just a benchmark run with a name:

pnpm bench -- --experiment "schema-free generated code"

It stays off the commit timeline and shows up on every chart as a flat dashed line, so we could see at a glance whether an idea beat the branch:

Bundle size · median over the 96 programs every experiment ran · lower is betterEach experiment is a flat line across the commit timeline.

normalstrictE2E3E4

While a subagent worked on a big bet, the main thread kept landing small wins. 38 of our 84 benchmark runs were experiments. Some ideas took three or four experiments to try different implementations, and we kept the best one. The biggest experiment was replacing Effect Schema, and the dashed line at the bottom of the chart above is the version that won.

Why Effect Schema had to go

Every generated schema was a real Effect Schema object. That put about 37 KB gzip of Schema code into every bundle, and built thousands of schema objects at import. Most of that was never used. Encoding a request and reading a response only need the schema’s structure: field names, which field goes in the path or a header, how a timestamp is formatted, and so on. Effect Schema’s parser only matters when you turn on strict validation.

We didn’t set out to write a schema library. The agent tried everything else first, on real shapes from EC2, S3, DynamoDB, Stripe and Cloudflare Workers. Stripe, after dedupe:

Option	Import memory	First-use memory	µs per validation	1-op bundle gz
Effect Schema (lazy)	0.86 MB	11.3 MB	24	27.5 KB
valibot	20 MB	0.2 MB	25	6.0 KB
zod/mini (before dedupe)	114 MB	0.7 MB	40	9.3 KB
TypeBox (before dedupe)	14 MB	1.9 MB	206	27.9 KB
schema-lite (ours)	2.3 MB	0.17 MB	13	4.6 KB

Every library lost on at least one axis we cared about. Effect’s own compilers didn’t help either: the ahead-of-time compiler can’t compile through recursive shapes, so it generated 4.6 MB of code for EC2, and the JIT mode doubled first-use memory. An earlier attempt, PR #671, replaced schemas with descriptors that only carry wire metadata. It was small, but it couldn’t validate, so strict mode broke.

Our problem is smaller

A general schema library has to handle any schema a user can write: transformations, refinements, defaults, branded types, async checks, self-referencing structures in full generality, and detailed error reports for all of it. That machinery costs bytes and memory.

Distilled needs almost none of it. Every schema is generated from an API spec and fixed at build time. They use about a dozen node kinds: strings, numbers, booleans, literals, structs, arrays, records, unions and optional fields. A recursive shape is just a named reference to another generated shape. And there is only one question to answer: does this decoded JSON match the shape the spec promised? So we wrote @distilled.cloud/core/schema-lite: plain data, plus one small validator.

Same API, plain objects

schema-lite is a small subset of Effect Schema. It exports the functions generated code already calls (Struct, Array, optional, Union, suspend and so on) with the same names and types, so the switch was one import line in every generated file:

import * as S from "@distilled.cloud/core/schema";
import * as S from "@distilled.cloud/core/schema-lite";

If you know Effect Schema, you can read distilled’s generated code. What changed is what each call returns: a plain object with the same fields as an Effect Schema AST node, and nothing else.

S.Struct({ id: S.String, tags: S.optional(S.Array(S.String)) });

// builds this, and only this:
{
  _tag: "Objects",
  propertySignatures: [
    { name: "id", type: { _tag: "String" } },
    {
      name: "tags",
      type: {
        _tag: "Union",
        context: { isOptional: true },
        types: [
          { _tag: "Arrays", elements: [], rest: [{ _tag: "String" }] },
          { _tag: "Undefined" },
        ],
      },
    },
  ],
}

Protocols run unchanged

Distilled’s protocol code (REST and AWS’s six wire protocols) already worked by walking the AST: _tag, propertySignatures, annotations. A lite node has exactly those fields, so the protocols didn’t need to know anything changed. AWS also needs to turn timestamps and base64 blobs into wire values, and lite nodes carry that in an encoding field with the same shape Effect uses. We checked the switch by encoding 1,516 requests and decoding 426 responses through both implementations. The bytes were identical.

Strict mode, and still faster than the official SDKs

Official SDKs trust the API. Providers change their APIs without warning, smaller ones especially (cough Cloudflare cough). The request still succeeds, so bad data flows into your app until something breaks far from the cause. Strict mode turns that into a controlled failure: a typed ParseError with the path to the bad field, right at the call. It’s one line:

program.pipe(Effect.provide(ResponseValidation.strict));

Under schema-lite, each node compiles once into a small checker, and the compiler itself only loads if you turn strict mode on. A test checks that it accepts and rejects exactly what Effect Schema does.

Distilled also types every error, so each operation ships the full union of errors it can fail with. We kept both, and compared them with the official AWS SDK v3, cloudflare and @google-cloud/storage packages, each imported the way its users would:

Bundle size of one call (gzip)

official SDK
distilled
distilled, strict

The ratio compares the official SDK with distilled in strict mode.

Latency each SDK adds to one call (p50)

official SDK
distilled
distilled, strict

GCP's official bar is cut to fit. The ratio compares the official SDK with the slower of distilled's two modes. Differences of a microsecond or two, like Cloudflare's strict bar, are within run-to-run noise.

Distilled with strict mode on is still 5 to 96 times faster per call than official SDKs that check nothing.

Per call isn’t the whole story for a CLI or a Lambda function. What they wait for is the cold start: import the SDK, set up a client and make the first call, in a fresh process. Bundled the way Alchemy deploys to Lambda and Workers, distilled starts 2.0× faster than the official SDK on AWS, 3.0× on Cloudflare and 1.2× on GCP. We measured this with a separate local harness that isn’t part of the benchmark suite yet.

Unbundled, in plain node_modules like a CLI, distilled is slower on AWS (107.5 ms against 42.8 ms) and GCP (96.0 ms against 67.2 ms), and still faster on Cloudflare (94.3 ms against 156.2 ms), because Node spends about 77 ms loading Effect’s ~150 separate modules, which a bundle turns into one file.

The first call on its own is about 1.5 ms slower in distilled on Cloudflare. The official SDK is a thin wrapper around fetch, and about 0.9 ms of the gap is the tracing span Effect opens for every request.

Meta tree shaking

SURELY we can’t be at the limit yet! KEEP GOING, like ride this crazy wave all the way into the volcano mannnnnnnn! kawabunga!

That is the most unhinged message we sent the whole time, and it produced the most unhinged idea. Importing all of AWS still took 35 MB, and the agent had told us that was close to the floor. After the volcano message, it came back with this: do a bundler’s tree shaking at run time, inside Node, on code that was never bundled.

Operations as data

Importing a service used to build every operation in it. EC2 has hundreds of operations and AWS about 19,500. Now each operation waits until someone calls it. We call this meta tree shaking. In spirit, the published JavaScript looks like this:

let built;
export const getDomain = (input) => {
  // First call: build the real operation, then remember it.
  built ??= API.make(() => ({
    input: GetDomainRequest,
    output: Domain,
    errors: [UnknownResendError],
    protocol: ResendProtocol,
  }));
  return built(input);
};

The real output stores the description as a short string instead of code, because a string takes less memory than the code that builds the same object. Error classes work the same way, so a call that succeeds never builds one.

Tree shaking at run time

A bundler drops unused code before you deploy. The Alchemy CLI doesn’t bundle, so we do the same cut at run time instead. Every service ships as two files: a tiny stub that Node loads, and the full module, which stays on disk with an index at the end saying where each operation’s bytes are and what it needs. This is the real start of the stub for Fly.io’s machines service, exactly as it ships:

import{$L}from"../_bundle/lazy.js";
const{o:$o,e:$e,E:$E}=/*@__PURE__*/$L("../services.full/machines.js","ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo",55605,7533);

Yes, that’s 99 os, one empty placeholder per operation. No human would write this, and no human has to read it. The two numbers say where the index is. The index looks like this:

#    name           bytes          needs
44   getMachine     19123..19407   13 sdk.js helpers, __d6
60   listMachines   25842..26325   16 sdk.js helpers, __d6
110  __d6           48375..48982   8 sdk.js helpers, __d3, __d5, __d4, __d22

That’s the dependency graph a bundler builds, written down for Node. The first call to a placeholder reads just that operation’s bytes, then follows needs the same way. Helpers in sdk.js are already loaded with the stub, so they cost nothing.

No `eval`, ever

Reading part of a JavaScript file and running it sounds like it needs eval or new Function. That would ruin the whole idea. Every eval makes V8 parse and compile new code, which costs the time and memory we were trying to save. It also means running bytes read from disk as code, which security tools flag and many runtimes block outright.

So the full module never stores operations as code. It stores them as data. This is the real entry for getMachine:

{input:#1,output:#9:4,errors:[$10,$11],protocol:$12,retry:$13}

#1 is another entry in the same operation, and #9:4 is an entry in the shared holder for Machine. $10 to $13 are values already in memory: the two error classes, the protocol and the retry policy. The loader is a small interpreter for this format. It reads the bytes, follows the references and calls the same schema-lite functions the code would have called, so the result is identical. Nothing it reads from disk is ever run as code, and V8 never compiles a single extra line.

Step through a real traced run that calls getMachine, then listMachines, then getMachine again. If you want to see how unhinged it really is, tick the box under the figure for the shipped code:

Your program

In memory · what it has loaded

On disk · the full module, by byte offset

I can handle the truth

Three calls read 13,629 of the file’s 63,178 bytes, and 7,533 of those are the index.

Don’t worry: none of this touches your code unless you ask for it. Stubs load only when Node resolves with the distilled-lazy export condition (node --conditions=distilled-lazy). Plain Node and every bundler get the normal full module.

Importing a whole provider

Programs that import a whole provider are where meta tree shaking pays off most. AWS went from 227 MB to 13.9 MB.

Memory to import every service of a provider

before
after

Import time fell too: AWS from 1.61 s to 0.14 s, Cloudflare from 0.63 s to 0.05 s.

Heap, provider imported · total over all providers · lower is betterRetained V8 heap after importing every service module of each provider in a fresh Node process.

The same metric summed over every provider: 924 MB at the start of the branch, 94 MB at the end.

Most of what’s left for AWS is V8 itself. Every module Node loads costs about 4.8 KB, and every named export about 325 bytes, even if nothing reads it. All of AWS is 438 modules and tens of thousands of exports, which comes to about 10 MB before any distilled code runs. The only way below that is to export fewer names, which is an API change.

Breaking changes

Try meta tree shaking in Alchemy

The Alchemy CLI ships with meta tree shaking turned off. To opt in, pass --fast-distilled, or set ALCHEMY_FAST_DISTILLED=1:

alchemy deploy --fast-distilled

The flag makes the CLI load distilled with the distilled-lazy condition, so every provider your app imports starts as a stub. It applies under Node. Under Bun it has no effect.

2.0.0-beta.84 - Monorepo, Domain & Faster Distilled

Thu, 22 Oct 2026 09:00:00 GMT

beta.84 splits alchemy into one package per provider, so you install @alchemy.run/aws or @alchemy.run/cloudflare next to alchemy instead of importing alchemy/AWS. Every AWS, GCP and Cloudflare binding now works from any host, so a Worker can call SQS and a Lambda can write to R2.

It also adds @alchemy.run/domain, a domain-driven design framework that runs on Durable Objects, and rebuilt distilled SDKs that add 5–100× less overhead per call than the official AWS, Cloudflare and GCP SDKs, in bundles a third smaller than before. On AWS, there are Lambda Web Functions with canary deploys. On Cloudflare, alchemy dev for Vite sites now behaves like @cloudflare/vite-plugin, and the runtime bindings use a lot less CPU.

Breaking changes

Providers moved into their own packages (#2348, #2316, #2313, #2311, #2309). Install the packages you use and update your imports. See below.
State store commands moved under alchemy state (#2288). The old commands print the new one and exit 1:
```
# Cloudflare state store
alchemy provider cloudflare bootstrap
alchemy state bootstrap --backend cloudflare
alchemy prisma generate
alchemy provider prisma generate
```
In CI, a missing or outdated state store fails unless you pass --yes. AWS.state({ name }) is now a short logical name. Use bucketName to pass a full bucket name.
AWS.Lambda.isBindingHost is removed (#2260, #2347). Custom AWS bindings use AWSBindings.Bind and AWSBindings.withCredentials. EC2, LaunchTemplate, AppRunner and Batch hosts now get IAM grants, so they plan new IAM resources on the next deploy.
Distilled error classes are no longer Effect Schemas (#2345). Match them with their is guard. Generated request and response schemas are no longer exported; reach them through the operation:
```
// match a distilled error
Schema.is(TooManyRequests)(error)
TooManyRequests.is(error)
PutDispatchNamespaceScriptRequest.ast
putDispatchNamespaceScript.input.ast
```
Prisma and Neon env values use the runtime wire format (#2244). Reading them through Prisma.Connect or the Neon clients is unchanged. Code that reads process.env directly sees secrets as {"_tag":"Redacted","value":"…"}.
AWS framework sites run on Web Functions by default (#2282, #2300). The next deploy creates a WebServer Web Function and deletes the old server Lambda, keeping the CloudFront distribution and domain. Set server: "function" to keep a Lambda Function URL server.
Effect 4.0.5 (#2372). Bump effect and @effect/* to ^4.0.5.

One package per provider

alchemy keeps the engine, the CLI, and the local and in-memory state stores. Every cloud and vendor now has its own package, and each one brings its own resources, bindings and state store, such as AWS.state() or Cloudflare.state() (#2348, #2316, #2313, #2311, #2309):

bun add https://pkg.alchemy.run/alchemy/bea0366 https://pkg.alchemy.run/@alchemy.run/cloudflare/bea0366 https://pkg.alchemy.run/@alchemy.run/aws/bea0366

import * as Alchemy from "alchemy";
import * as AWS from "alchemy/AWS";
import * as Cloudflare from "alchemy/Cloudflare";
import * as Neon from "alchemy/Neon";
import * as Drizzle from "alchemy/Drizzle";
import * as Postgres from "alchemy/SQL/Postgres";
import * as AWS from "@alchemy.run/aws";
import * as Cloudflare from "@alchemy.run/cloudflare";
import * as Neon from "@alchemy.run/neon";
import * as Drizzle from "@alchemy.run/drizzle";
import * as Postgres from "@alchemy.run/sql/Postgres";

The same goes for gcp, fly, railway, hetzner, prisma, planetscale, turso, stripe, github, git, acme, axiom, doppler, infisical, docker, kubernetes, redis and domain. Each package exports its directories and files, so @alchemy.run/aws/S3 and @alchemy.run/aws/S3/Bucket both resolve.

A few things moved within packages:

import * as Cloudflare from "@alchemy.run/cloudflare";
solver: ACME.Cloudflare.ZoneSolver(zone),
solver: Cloudflare.ACME.ZoneSolver(zone),
Stripe.Cloudflare.ConsumeEventsLive
Stripe.ConsumeEventsLive
GitHub.Cloudflare.RepositoryEventSourceLive
GitHub.RepositoryEventSourceLive
import { ServerHost } from "alchemy/Server";
import { ServerHost } from "alchemy/Runtime/Process";
import { LibSQL } from "alchemy/SQL/LibSQL";
import { LibSQL } from "@alchemy.run/sql/SQLite";

The CLI finds each provider’s auth, state store and alchemy provider commands once your project depends on its package, through a new Contributions module (#2288). Named state stores come with it:

state: Cloudflare.state({ name: "team-a" }),

alchemy state bootstrap --backend cloudflare --name team-a

Runtime bundles shrank along the way. A Worker no longer bundles the stack builder or CLI auth code (346 KB → 216 KB, #2240), and a Lambda that imports the Cloudflare barrel drops from 3.26 MB to 0.84 MB (#2267). Thanks Rahul Mishra, who did most of this split!

OAuth can now create Account API Tokens

Cloudflare OAuth can now grant Account API Token Provisioning, so alchemy can mint scoped API tokens on your behalf. To add it, re-run the Cloudflare login and pick All Scopes:

alchemy profile edit --reconfigure Cloudflare

Then turn the scope on under Sensitive scopes on Cloudflare’s consent page. It’s off by default:

Login now goes through the Cloudflare CLI’s (cf) OAuth client with device auth, the same flow as cf login (#2444). Existing profiles keep refreshing.

Docs: Cloudflare setup.

Every binding works from every cloud

In beta.83, only the S3, Lambda and DynamoDB bindings worked outside AWS, no GCP binding worked outside GCP, and Cloudflare’s *Http bindings crashed on any host that wasn’t a Worker. As part of the package split, every binding now works on any host: all ~2,850 AWS bindings across 205 services (#2260), all 192 GCP bindings across 57 services (#2347), and every Cloudflare *Http binding (#2267).

A Cloudflare Worker sends to SQS with the same binding a Lambda uses. You provide its *Http layer:

import * as AWS from "@alchemy.run/aws";
import * as Cloudflare from "@alchemy.run/cloudflare";
import * as Effect from "effect/Effect";
import * as HttpServerResponse from "effect/http/HttpServerResponse";

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const queue = yield* AWS.SQS.Queue("Jobs");
    const sendMessage = yield* AWS.SQS.SendMessage(queue);
    return {
      fetch: sendMessage({ MessageBody: "hello" }).pipe(
        Effect.map(() => HttpServerResponse.text("queued")),
      ),
    };
  }).pipe(Effect.provide(AWS.SQS.SendMessageHttp)),
) {}

On AWS hosts, a binding grants its permissions to the host’s own role. On any other host, such as a Worker or Cloud Run, Alchemy creates a least-privilege IAM user and role for it and signs each call with that role. GCP works the same way with a service account and key. The other direction works too: a Lambda writes to R2 through Cloudflare.R2.WriteBucketHttp, which binds a scoped Cloudflare API token. Hosts that run as a role or service account leave this code out of their bundles. Thanks Rahul Mishra!

Docs: Bindings.

Domain-driven design with `@alchemy.run/domain`

@alchemy.run/domain models your backend in your business’s terms (#2176). Commands ask for changes, aggregates decide them, and events record what happened. Views, policies, sagas and projections react to those events. The same model runs in memory for tests and on Durable Objects in production.

A command declares its target, input, events, rejections and reply:

import * as Domain from "@alchemy.run/domain";

export class MoneyDeposited extends Domain.Event("MoneyDeposited", {
  amount: Schema.Int,
  balanceAfter: Schema.Int,
}) {}

export class DepositMoney extends Domain.Command("DepositMoney", {
  target: AccountId,
  input: { amount: Schema.Int },
  events: [MoneyDeposited],
  rejects: [NotOpen],
  reply: { balance: Schema.Int },
}) {}

The aggregate decides it against its current state:

DepositMoney: (s, cmd) =>
  s._tag !== "Open"
    ? new NotOpen()
    : [new MoneyDeposited({ amount: cmd.amount, balanceAfter: s.balance + cmd.amount })],

A story tests it in memory: given this history, when this command, then these events.

story(
  Story.given(account, new AccountOpened({ owner: "sam" })),
  Story.when(account, new DepositMoney({ amount: 100 })),
  Story.then(account, new MoneyDeposited({ amount: 100, balanceAfter: 100 })),
  Story.replied({ balance: 100 }),
);

On Cloudflare, provide DomainCloudflare.DurableObjects and every aggregate, view key and policy gets its own Durable Object. Views are security boundaries, and clients can watch them live over WebSockets. The package ships an alchemy-domain skill so your coding agent can build a model with you.

Docs: Domain · Tutorial · Cloudflare Durable Objects.

Smaller, faster distilled SDKs

Alchemy’s cloud SDKs come from distilled. This release picks up a rebuilt distilled (distilled#873, #2345) that dedupes schemas, builds them lazily, and replaces Effect Schema with a lighter schema tree. Medians over 98 one-auth, one-call programs:

	Before	After	Change
Bundle size (gzip)	57.1 KB	38.3 KB	−33%
Added latency per call (p50)	19.5 µs	4.0 µs	−79%
Import heap	2.15 MB	0.57 MB	−74%
First call (cold)	4.9 ms	3.3 ms	−34%

Importing a whole provider is where it shows most. AWS has 438 services, GCP 318 and Cloudflare 129:

Provider	Import heap	Import time
AWS	227 MB → 13.9 MB	1.61 s → 0.14 s
GCP	111 MB → 9.4 MB	0.75 s → 0.09 s
Cloudflare	76 MB → 3.2 MB	0.63 s → 0.05 s

The packages you install from npm shrink too:

Package	Download (tgz)	Unpacked
`@distilled.cloud/aws`	23.3 MB → 19.3 MB	211 MB → 143 MB
`@distilled.cloud/gcp`	42.3 MB → 36.1 MB	345 MB → 262 MB
`@distilled.cloud/cloudflare`	9.5 MB → 5.8 MB	112 MB → 58 MB

Faster than the official SDKs

The same calls through the official SDKs: AWS SDK v3, the Stainless-built cloudflare package, and @google-cloud/storage. Each official program imports one client. Each distilled program imports the whole provider and is still smaller:

Call	Added latency per call	Bundle (gzip)	Import heap
GCP `storage.getBuckets`	674 → 6.2 µs	239 → 40 KB	5.1 → 0.7 MB
S3 `ListBuckets`	140 → 19 µs	157 → 61 KB	4.4 → 1.1 MB
EC2	97 → 16 µs	265 → 55 KB	12.2 → 1.5 MB
DynamoDB	87 → 14 µs	145 → 54 KB	3.3 → 1.0 MB
Lambda	79 → 15 µs	141 → 55 KB	3.6 → 1.1 MB
Cloudflare `workers.scripts.list`	15.5 → 3.0 µs	125 → 56 KB	15.3 → 0.7 MB

Distilled adds 5–100× less overhead per call, ships bundles 2–6× smaller, and imports with 3–22× less memory. Its first cold call is faster too, except on Cloudflare, where it takes 3.4 ms against the official SDK’s 1.9 ms.

The Cloudflare package now signs R2 presigned URLs with the standalone @distilled.cloud/aws4signer, so it no longer depends on the AWS SDK (#2370). Thanks Michael K!

Plan and apply scale linearly

Plan and apply used to do work proportional to the square of the stack’s resource count. Apply rebuilt every resource’s outputs once per resource, and plan scanned every node to find each node’s dependents. Both are now linear (#2419):

Stack shape	Resources	Before	After
Independent	4,000	3.4 s	1.7 s
Independent	8,000	9.5 s	3.8 s
20 dependencies each	1,000	1.2 s	1.1 s
20 dependencies each	2,000	3.3 s	2.1 s

Timings are engine overhead only, measured with no-op providers. Thanks gpu004 for profiling it!

Foldkit SSR and prerendering

Foldkit apps can now render on the server and prerender pages, on every website provider (#1313). Turn on ssr.build in the Foldkit Vite plugin:

vite.config.ts

export default defineConfig({
  plugins: [
    foldkit({
      ssr: {
        serverEntry: "/src/entry.server.ts",
        clientEntry: "/src/entry.ts",
        build: { prerender: true },
      },
    }),
  ],
});

Alchemy deploys the server Foldkit generates and serves prerendered pages as static files. On Cloudflare, Fly, Hetzner, Railway, Neon, Prisma and GCP, the build decides whether the site is an SPA, static, SSR or a hybrid:

const site = yield* Cloudflare.Website.Foldkit("Web");

On AWS, you choose between a server and a static site:

const app = yield* AWS.Website.Foldkit("Web", { output: "server" });
const docs = yield* AWS.Website.Foldkit("Docs", { output: "static", errorPage: "404.html" });

Foldkit pairs with @alchemy.run/domain for the front end of a domain model. Thanks Filip Falcon!

Docs: Foldkit on Cloudflare · Foldkit on AWS.

Lambda Web Functions

AWS.Lambda.WebFunction runs your HTTP server on Lambda Web Functions (#2243). Each environment serves up to 128 requests at once, responses stream, and every function gets an HTTPS endpoint. An Effect Web Function returns fetch, and existing bindings work unchanged:

export default class Api extends AWS.Lambda.WebFunction<Api>()(
  "Api",
  { main: import.meta.url, authType: "ApplicationManaged" },
  Effect.gen(function* () {
    const bucket = yield* AWS.S3.Bucket("Uploads");
    const putObject = yield* AWS.S3.PutObject(bucket);
    return {
      fetch: Effect.gen(function* () {
        yield* putObject({ Key: "hello.txt", Body: "Hello!" });
        return HttpServerResponse.text("Saved");
      }).pipe(Effect.orDie),
    };
  }).pipe(Effect.provide(AWS.S3.PutObjectHttp)),
) {}

Or bring your own server (Hono, Express, node:http). It listens on AWS_LAMBDA_HTTP_ENDPOINT:

yield* AWS.Lambda.WebFunction("Api", {
  main: "./src/server.ts",
  authType: "ApplicationManaged",
  regions: ["us-east-1", "eu-west-1"], // one global domain
});

canary sends a share of traffic to each new deploy (#2280). Edit the weight to promote or roll back:

canary: { weight: 10 }, // the new revision gets 10%, the previous one 90%

Every server-rendered AWS.Website (Nuxt, SvelteKit, Astro, React Router, SolidStart, TanStack Start, Waku, Octane, Vinext) now runs on a Web Function by default (#2282). Next.js runs as its own standalone server with an S3 cache, without OpenNext, SQS or DynamoDB (#2300). Existing sites roll forward on the next deploy.

Docs: Web Functions · Next.js.

Effect workflows on every engine

alchemy/Workflows runs effect/workflow workflows on Durable Objects, Cloudflare Workflows, and Lambda durable functions (#2252, #2268, #2390).

Workflows.layer implements a workflow. Pass it an Effect that resolves bindings, here an R2 bucket, and return the handler that uses them:

src/Onboard.ts

import * as Cloudflare from "@alchemy.run/cloudflare";
import * as Workflows from "alchemy/Workflows";
import * as Effect from "effect/Effect";
import * as Schema from "effect/Schema";
import { Activity, DurableClock, Workflow } from "effect/workflow";

export const Profiles = Cloudflare.R2.Bucket("Profiles");

export const Onboard = Workflow.make("Onboard", {
  payload: { userId: Schema.String },
  success: Schema.String,
  idempotencyKey: ({ userId }) => userId,
});

export const OnboardLive = Workflows.layer(
  Onboard,
  Effect.gen(function* () {
    const profiles = yield* Cloudflare.R2.WriteBucket(Profiles);
    return Effect.fn(function* ({ userId }) {
      yield* Activity.make({
        name: "create-profile",
        execute: profiles
          .put(`${userId}.json`, JSON.stringify({ userId, plan: "trial" }))
          .pipe(Effect.orDie),
      });
      // the run suspends for a week and costs nothing while it waits
      yield* DurableClock.sleep({ name: "trial", duration: "7 days" });
      yield* Activity.make({
        name: "end-trial",
        execute: profiles
          .put(`${userId}.json`, JSON.stringify({ userId, plan: "free" }))
          .pipe(Effect.orDie),
      });
      return `onboarded ${userId}`;
    });
  }),
);

The Worker starts runs with Workflows.RunWorkflow and reads them back. Give it the implementation, the R2 binding and an engine, here Durable Objects:

src/Api.ts

import * as Cloudflare from "@alchemy.run/cloudflare";
import * as Workflows from "alchemy/Workflows";
import * as Effect from "effect/Effect";
import { HttpServerRequest } from "effect/http/HttpServerRequest";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import * as Layer from "effect/Layer";
import { Onboard, OnboardLive } from "./Onboard.ts";

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const onboard = yield* Workflows.RunWorkflow(Onboard);
    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        const url = new URL(request.url, "http://localhost");
        if (request.method === "POST") {
          const userId = url.searchParams.get("user")!;
          const run = yield* onboard.start({ userId });
          return HttpServerResponse.text(run.executionId);
        }
        const runId = url.searchParams.get("run")!;
        // NotStarted | Running | Completed | Failed | Interrupted | Died
        const status = yield* onboard.get(runId).status;
        return HttpServerResponse.text(status._tag);
      }).pipe(Effect.orDie),
    };
  }).pipe(
    Effect.provide(
      OnboardLive.pipe(
        Layer.provide(Cloudflare.R2.WriteBucketBinding),
        Layer.provideMerge(Cloudflare.Workflows.DurableObjectEngine),
      ),
    ),
  ),
) {}

Swap DurableObjectEngine for Cloudflare.Workflows.NativeEngine to run it on Cloudflare Workflows instead. On AWS, host workflows in an AWS.Lambda.WorkflowFunction and start them from other functions with AWS.Lambda.DurableFunctionEngine.

Docs: Cloudflare · AWS.

Vite dev that matches `@cloudflare/vite-plugin`

A Website.Vite Worker now behaves in alchemy dev as it does deployed, and as it does under @cloudflare/vite-plugin (#2367, #2365, #2144). Durable Objects from other Workers, Workflows, Containers, WebSockets, ctx.access, Node.js polyfills, HTTPS dev servers and Wrangler’s /cdn-cgi/local/* endpoints all work in dev. Asset routing follows your htmlHandling, notFoundHandling and runWorkerFirst:

yield* Cloudflare.Website.Vite("App", {
  main: "./api/index.ts",
  assets: { notFoundHandling: "single-page-application", runWorkerFirst: ["/api/*"] },
});
// dev before: /api/some-file.txt → the file on disk
// dev now:    /api/some-file.txt → the Worker, as deployed

A Vite config that keeps cloudflare() from @cloudflare/vite-plugin now runs, so RedwoodSDK, Flue and the Agents SDK build as documented. Tests run the official plugin next to Alchemy’s on the same projects and compare config, build output and runtime behavior. The full list is in PARITY.md.

The dev server also refuses .env, .dev.vars and .alchemy/, and no longer forwards a request like //127.0.0.1:47667/x to another local port (#2381). Thanks Arman Charan!

Faster Cloudflare runtime

Dan van der Merwe measured the runtime bindings on deployed Workers and Durable Objects and cut their CPU time:

Workload	Mean CPU before → after
Copy a 16 MiB R2 object with `get` + `put` (#2276)	630 → 3.8 ms
Prepare five 1 MiB Workers AI images (#2274)	270 → 10.6 ms
1,000 workflow result round trips (#2271)	358 → 32 ms
2 MiB through the RPC codec (#2272)	85 → 20 ms
Pack 500 queue messages (#2275)	235 → 92 ms
Drain 1,000 Durable Object scheduled events (#2277)	33 → 8.4 ms
2,000 env reads in a Durable Object (#2279)	29 → 4.9 ms

SQL cursors allocate only what you use (#2281). RPC streams whose values arrive after the method returns now deliver every value (#2273), and durable callbacks that keep failing now back off and park after eight attempts instead of waking forever (#1908).

RDS migrations everywhere

migrations now works on every PostgreSQL, MySQL and MariaDB DBInstance, standalone or Aurora (#2125, #2289). Aurora runs them over the Data API. A public database connects directly, and a private one runs them from a Lambda in the VPC:

const runner = yield* AWS.RDS.MigrationRunner("MigrationRunner", {
  subnetIds: network.privateSubnetIds,
  securityGroupIds: [runnerSecurityGroup.groupId],
});

const db = yield* AWS.RDS.DBInstance("Db", {
  engine: "mysql",
  // ...
  migrations: "./migrations",
  migrationsTransport: runner,
});

Thanks gegi!

Docs: RDS · Drizzle on Aurora.

GCP state store

GCP.state() keeps deploy state in a Cloud Storage bucket in your project (#2379):

export default Alchemy.Stack(
  "MyApp",
  { providers: GCP.providers(), state: GCP.state() },
  program,
);

alchemy state bootstrap --backend gcp

AWS.state() now locks each stack and stage too, so two concurrent deploys of one stage can no longer mix their state (#2145). Thanks Arman Charan! The GCP docs are rebuilt around a five-part tutorial (#2374).

Docs: GCP · GCP setup.

Fly remote builds

Fly.Service images now build on Fly’s remote builders, the same ones fly deploy uses (#2472). Only your bundled app leaves your machine: the builder pulls the base image, builds, and pushes to registry.fly.io right next to it. Deploys no longer upload the whole ~86 MB node:26-slim image for every Service, which made them slow on home and CI connections. Nothing to change in your stack:

// builds on a Fly remote builder
yield* Fly.Service("Api", { main: import.meta.url });

// build and push with your local Docker engine instead
yield* Fly.Service("Api", { main: import.meta.url, build: { remote: false } });

Docs: Fly services.

Also in this release

GCP.IAM.ServiceAccount and ServiceAccountKey resources (#2347).
Cloudflare.Hyperdrive.lookup (#1345) binds an existing Hyperdrive configuration without managing it. Thanks Franz Rebaza!
ctx.props and ctx.exports in Effect Workers and Durable Objects (#2251), and hibernation tags on Cloudflare.upgrade() (#2265). Thanks gegi!
Container placement jurisdiction and regions are typed (#2253), local containers can mount FUSE filesystems (#2362), and detached or adopted container applications redeploy cleanly (#2378, #2283). Containers built from inline Dockerfile content deploy (#2341), and monitor() fails with the same typed placement errors as start() (#2340). Thanks Jakub Sieczczyński, Jonathan Beckman, Yannic Charlon and Drew Powers!
localUploads on Cloudflare.R2.Bucket (#2424).
Cloudflare fixes: a failed ruleset read no longer wipes a zone’s other rules when a Worker sets domain.redirects or version.affinity (#2339), WorkerEntrypoint targets a cross-stack Worker.ref (#2414), a rotated MtlsCertificate uploads the new PEM (#2428), and a Hyperdrive config replaces when its CA pin is dropped (#2429). Thanks Drew Powers!
Cloudflare website builds receive env, so NEXT_PUBLIC_*, VITE_* and similar values reach the client bundle (#2238), and a full Worker deploy returns its versionId and deploymentId (#2241). Thanks Kevin!
Local dev fixes: /.well-known/ assets serve (#2212), large D1 migrations and importFiles apply (#2380, #2258), publicDir files serve through ASSETS (#2290), StaticSite takes dev.port (#2331), tail consumers receive events and each Worker gets its own Cache store (#2383), port probes stay on loopback (#2237), and early responses no longer reset the connection (#2242). Thanks birbprophet, Altay, Kevin and Matthew Ruiters!
Cloudflare deploys on Node 26 use HTTP/1.1 for API calls, avoiding stream resets (#2155), and Durable Object RPC retries through deploy propagation (#2294).
metadataOptions on AWS.EC2.Instance and LaunchTemplate (#2426), Redacted userData on Instance (#2421), and a VPC whose create was interrupted is recovered instead of leaked (#2416).
AWS.RDS.Aurora accepts Outputs for kmsKeyId and migrations (#2364). Thanks gegi!
AWS fixes: Lambda.KafkaEventSource grants the EC2 permissions MSK mappings need (#2401), EMRContainers.VirtualCluster waits for a new EKS cluster’s connection (#2412), and DataZone.EnvironmentBlueprintConfiguration removes the Lake Formation admins DataZone added (#2411).
~200 more AWS resources run on floci in alchemy dev (#1803).
AgentCore Runtime V2 with platformVersion (#2301), ECS dev watcher keeps the recorded task definition (#2091). Thanks Henry Marks and TBIQ007!
Railway ephemeral environments (#2117) and a 768 MiB Prisma Compute upload cap (#2257). Thanks Mikkel and Aman Varshney!
GitHub.consumeRepositoryEvents generates a webhook secret when you omit one, so every delivery’s signature is checked (#1932). GitHub.Ruleset takes allowedMergeMethods and requireExtraApprovalForUnattributedChanges (#2397) and adopts an existing ruleset by name (#2129), and GitHub.BranchProtection deploys with requiredStatusChecks.checks (#2076). Thanks Jason Kuhrt, Patt O’Brien and Arman Charan!
Core fixes: declaring a logical id already used by another type fails with DuplicateLogicalIdError (#2063), afterAll(destroy(Stack)) no longer hangs under Vitest (#2142), a Docker.Context missing from a fresh CI runner is re-created (#2187), log redaction no longer leaks the tail of a secret that extends a shorter one (#2418), tarballs keep long non-ASCII file names intact (#2420), and alchemy/State type-checks under exactOptionalPropertyTypes (#2413). Thanks Arman Charan and Patt O’Brien!
The CLI runs on Node 22.22.3+ again (#2403), and alchemy profile refresh --provider matches case-insensitively (#2410). Thanks Rahul Mishra!
alchemy profile no longer crashes with Cannot find package 'react' (#2295), and Workers bundle less core code (#2240). Thanks birbprophet and Juliaan!

Where to go next

Getting started · Cloudflare setup · AWS setup · GCP setup
Domain · Domain tutorial · Foldkit
Web Functions · Next.js on AWS · RDS
Effect workflows on Cloudflare · on AWS
Vite on Cloudflare
CHANGELOG
Compare v2.0.0-beta.83 → v2.0.0-beta.84

2.0.0-beta.83 - Cloudflare Birthday Week

Mon, 12 Oct 2026 09:00:00 GMT

beta.83 supports Cloudflare’s Birthday Week launches. Containers can now be managed by Durable Objects: bind one Container per image and start the one you need. K2 gives you durable event streams, and Basin turns Pipelines and the R2 Data Catalog into one data platform. Workers KV Instant, Workers Issues, and vinext 1.0 work out of the box.

Outside Birthday Week, Workers can reach private databases through Hyperdrive and Workers VPC, set Workers Cache per entrypoint, and serve one hostname from many Workers with federated APIs, and take over existing Cloudflare Access apps. Durable Objects now deploy with Cloudflare’s declarative exports. Kubernetes resources send Redacted secrets to the cluster. There is also a new Turso provider, AWS console login, DSQL migrations, and Neon.Role.

It also ships 93 bug fixes and closes 51 issues. See Bug fixes. This post covers beta.82 and beta.83.

Breaking changes

Containers start explicitly, and one Container is one image (#1905, #2223). Cloudflare.Containers.layer is removed. yield* Sandbox binds the container without starting it; call sandbox.start() before you use it:
```
const sandbox = yield* Sandbox;
return { ping: () => sandbox.ping() };
const start = sandbox.start({ enableInternet: true });
return { ping: () => start.pipe(Effect.andThen(sandbox.ping())) };
```
A Durable Object-managed Container declares a single image (or dockerfile). The images map from beta.82 is removed: declare one Container per image and bind each to the Durable Object. On an async Worker, the Container’s className is replaced by the Durable Object binding’s containers, and a Durable Object-managed Container placed directly in env fails with DurableObjectContainerBindingError:
```
env: {
  AGENT: Cloudflare.DurableObject("Agent", { containers: [Node, Python] }),
}
```
A container’s RPC shape can no longer declare members the handle already has (start, exec, image, getTcpPort, …), and RPC on a stopped container fails with ContainerNotRunningError.
Pipelines streams are private by default (#2010). A Pipelines.Stream declared without http no longer gets a public, unauthenticated ingest endpoint. Set http: { enabled: true, authentication: false } to keep one.
Durable Objects deploy with exports, and you can’t go back (#2135). After a Worker with Durable Objects deploys on beta.82, older Alchemy releases can no longer deploy it. Upgrade every machine and CI job that deploys the stack together. The first deploy after upgrading must go out at 100% traffic. See below.

InstanceId is now ResourceContext (#2160). Custom providers read the instance id from the resource context:

import * as Effect from "effect/Effect";
import { InstanceId } from "alchemy";
const instanceId = yield* InstanceId;
import { ResourceContext } from "alchemy";
const { instanceId } = yield* ResourceContext;

The CLI needs Node 24.11.1+ or Bun (#2151). Node 22 and 23 are no longer supported.
Bundles are written to .alchemy/bundles (#2133), not dist/. Workers and Lambdas redeploy once after you upgrade because their sourcemap paths change. Set build.output.dir to choose a location.
Git.BlobStoreR2 needs a ReadWriteBucket implementation (#2102). Provide Cloudflare.R2.ReadWriteBucketBinding (or ReadWriteBucketHttp) on the Worker.
Removed GCP resources (#2159, #2024). Google removed the APIs behind GCP.WorkspaceEvents.TasksPushNotificationConfig and the GCP.Dataplex data taxonomy resources.
An MtlsCertificate in env is an mTLS binding (#2051), typed as a Fetcher, instead of a JSON binding.

Cloudflare Birthday Week

Containers managed by Durable Objects

Cloudflare rebuilt Containers so a Durable Object can start one directly (#1905, #2223). Declare one Container per image with schedulingPolicy: "durable_object":

export class Node extends Cloudflare.Container<Node>()("Node", {
  schedulingPolicy: "durable_object",
  image: "node:24-slim",
}) {}

export class Python extends Cloudflare.Container<Python>()("Python", {
  schedulingPolicy: "durable_object",
  dockerfile: "./python/Dockerfile",
  context: "./python",
}) {}

Bind as many as you need in the Durable Object. Each handle’s start() starts its own image, with the instance size and entrypoint you choose:

export class Agent extends Cloudflare.DurableObject<Agent>()(
  "Agent",
  Effect.gen(function* () {
    const node = yield* Node;
    const python = yield* Python;
    return Effect.succeed({
      run: (cmd: string[]) =>
        Effect.gen(function* () {
          yield* node.start({
            instance: "lite",
            entrypoint: ["sleep", "infinity"],
            enableInternet: false,
          });
          return yield* (yield* node.exec(cmd)).output();
        }).pipe(Effect.scoped),
    });
  }),
) {}

A Durable Object runs one container at a time, so start one image and destroy() it before you switch.

A plain async Durable Object lists its Containers on its binding. A Container can back several classes:

alchemy.run.ts

const Node = Cloudflare.Container("Node", {
  schedulingPolicy: "durable_object",
  image: "node:24-slim",
});
const Python = Cloudflare.Container("Python", {
  schedulingPolicy: "durable_object",
  image: "python:3.13-slim",
});
const Rust = Cloudflare.Container("Rust", {
  schedulingPolicy: "durable_object",
  image: "rust:1.90-slim",
});

export const Worker = Cloudflare.Worker("App", {
  main: "./src/worker.ts",
  env: {
    AGENT: Cloudflare.DurableObject("Agent", { containers: [Node, Python] }),
    REVIEWER: Cloudflare.DurableObject("Reviewer", { containers: [Node, Rust] }),
  },
});

The class finds each image in ctx.container.images under its Container’s id:

src/worker.ts

import { DurableObject } from "cloudflare:workers";

export class Agent extends DurableObject {
  async run(cmd: string[]) {
    const container = this.ctx.container!;
    if (!container.running) {
      container.start({
        image: container.images.Node,
        entrypoint: ["sleep", "infinity"],
        enableInternet: false,
      });
    }
    return (await container.exec(cmd)).output();
  }
}

Snapshots, SSH, and stdin streaming are supported, and the same code runs under alchemy dev. Thanks Dan van der Merwe!

Docs: Containers · Container lifecycle.

K2 event streams

Cloudflare.K2.Stream is a durable event stream stored in R2 (#2010). A Worker writes to it through a binding:

export const Orders = Cloudflare.K2.Stream("Orders", {
  retention: "7 days",
});

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const orders = yield* Cloudflare.K2.WriteStream(Orders);
    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        yield* orders.send([{ content: yield* request.text }]);
        return HttpServerResponse.empty({ status: 202 });
      }),
    };
  }).pipe(Effect.provide(Cloudflare.K2.WriteStreamBinding)),
) {}

Long-running hosts consume the stream with consumeStreamRecords. Here a Fly Service reviews large orders:

yield* Cloudflare.K2.consumeStreamRecords(
  Orders,
  { startAt: "earliest", concurrency: 4 },
  (records) =>
    records.pipe(
      Stream.map((record) => record.value),
      Stream.filter((order) => order.amountCents > 100_000),
      Stream.runForEach((order) => Effect.log(`review ${order.orderId}`)),
    ),
);

Docs: K2.

Basin

Cloudflare renamed its data platform Basin: Pipelines, the R2 Data Catalog, and SQL. The same resources are now also exported as Cloudflare.Basin.* (#2010). A pipeline reads a stream and writes to an Iceberg table with SQL:

const lake = yield* Cloudflare.R2.Bucket("Lake");
const catalog = yield* Cloudflare.Basin.Catalog("Catalog", { bucket: lake });
const views = yield* Cloudflare.Basin.Stream("PageViews", { schema: PageView });

const table = yield* Cloudflare.Basin.Sink("PageViewTable", {
  type: "basin_catalog",
  catalog,
  table: { namespace: "web", name: "page_views" },
  token: yield* Config.Redacted("CATALOG_TOKEN"),
});

yield* Cloudflare.Basin.Pipeline("PageViewEtl", {
  sql: Output.interpolate`
    INSERT INTO ${table.name}
    SELECT userId, path, at FROM ${views.name}`,
});

Alchemy checks the SQL with Cloudflare during plan, so a bad statement fails before anything changes.

Basin.Table creates an Iceberg table directly, with columns from an Effect Schema:

const orders = yield* Cloudflare.Basin.Table("Orders", {
  catalog,
  namespace: "sales",
  schema: Order,
  partitionBy: ["day(at)"],
});

Docs: Pipelines · Iceberg tables.

Workers KV Instant

Cloudflare.KV.InstantNamespace creates a namespace in Cloudflare’s new Instant mode, for small configuration that is read often (#2027). The existing KV capabilities accept it, and alchemy dev emulates it:

const config = yield* Cloudflare.KV.InstantNamespace("Config");

// in a Worker
const kv = yield* Cloudflare.KV.ReadNamespace(config);
const enabled = yield* kv.get("feature-enabled");

Switching a namespace between classic and Instant replaces it and does not copy its data. Thanks BlankParticle!

Workers Issues

Turn on Workers Issues error detection for a Worker (#1992). Version uploads and gradual rollouts keep the setting:

yield* Cloudflare.Worker("Api", {
  main: "./src/worker.ts",
  observability: { issues: { enabled: true } },
});

vinext 1.0

Website.Vinext supports vinext 1.0, including hybrid App and Pages Router builds (#2025). Thanks BlankParticle!

Private databases with Hyperdrive

A Hyperdrive connection can now reach a database that has no public endpoint, through a Workers VPC service (#2218). Point the origin at the service with serviceId:

const hyperdrive = yield* Cloudflare.Hyperdrive.Connection("Hyperdrive", {
  origin: {
    scheme: "postgres",
    serviceId: service.serviceId,
    database: "app",
    user: "app",
    password: password.text,
  },
});

The guide connects a Worker to Aurora in private AWS subnets through a Cloudflare Tunnel, and examples/cloudflare-hyperdrive-aws-vpc deploys the whole thing.

Docs: Private databases.

Workers Cache per entrypoint

entrypoints sets Workers Cache for each entrypoint of a Worker (#2216). An entrypoint you don’t list uses the Worker’s cache setting:

yield* Cloudflare.Worker("Api", {
  main: "./src/worker.ts",
  entrypoints: {
    default: { cache: { enabled: false } },
    Public: { cache: { enabled: true } },
  },
});

Durable Objects deploy with exports

Alchemy now uploads Durable Objects with Cloudflare’s declarative exports instead of migrations (#2135). Your code doesn’t change. Alchemy can now deploy and adopt Workers that were last deployed by Wrangler 4.107 or later.

The first deploy after upgrading must go out at 100% traffic. If you use gradual deployments, remove version.traffic for that one deploy; otherwise it fails with WorkerVersionConfigError.

Removing a Durable Object binding no longer deletes its namespace while the class is still exported. Remove the class from your code to delete it. Previews still use migrations.

Docs: Durable Objects · Gradual deployments.

Federated APIs

Serve one hostname from several Workers, each with only the permissions it needs, using zone routes (#2088). alchemy dev applies the same routing locally:

yield* Cloudflare.Worker("Home", {
  main: "./src/home.ts",
  domain: "api.example.com",
});

yield* Cloudflare.Worker("Orders", {
  main: "./src/orders.ts",
  routes: [{ pattern: "api.example.com/orders*" }],
});

Docs: Federated APIs.

Cloudflare Access: adopt apps and SaaS

Access.Application can take over an existing app by its Cloudflare id (#1848). The id and aud stay the same, so JWT validation keeps working, and no --adopt is needed:

const grafana = yield* Cloudflare.Access.Application("Grafana", {
  applicationId: "4f8e3c1a-5b2d-4e6f-9a7b-1c2d3e4f5a6b",
  type: "self_hosted",
  domain: "grafana.example.com",
});

If the id doesn’t exist, the deploy fails with DeclaredApplicationNotFound instead of creating a new app.

SAML and OIDC SaaS apps are supported too. The values Cloudflare generates, such as the SSO endpoint and client id, come back as outputs:

const looker = yield* Cloudflare.Access.Application("Looker", {
  type: "saas",
  saasApp: {
    authType: "saml",
    spEntityId: "https://example.looker.com",
    consumerServiceUrl: "https://example.looker.com/saml/acs",
  },
});

Access.Policy gains SSH and RDP connection rules, approval groups, and a justification prompt:

yield* Cloudflare.Access.Policy("SshOps", {
  decision: "allow",
  include: [{ emailDomain: "example.com" }],
  connectionRules: { ssh: { usernames: ["root", "ubuntu"] } },
  approvalGroups: [{ approvalsNeeded: 1, emailAddresses: ["lead@example.com"] }],
  purposeJustificationRequired: true,
});

Updates no longer reset settings you leave out of the props. A field you omit keeps its live value; pass [] or false to clear it. Thanks spinx and Chinoman10!

Docs: Access.

Turso

A new Turso provider creates groups and databases, with migrations, and binds them to Workers and Lambdas (#2138):

import * as Turso from "alchemy/Turso";

export const Group = Turso.Group("Group", { location: "aws-us-east-1" });

export const Db = Effect.gen(function* () {
  const group = yield* Group;
  return yield* Turso.Database("Db", {
    group: group.name,
    migrations: "./migrations",
  });
});

Query it with Drizzle or SQL.LibSQL:

const conn = yield* Turso.Connect(Db);
const db = yield* Drizzle.LibSQL(conn);

Turso.ManageDatabases creates a database per tenant at runtime:

const tenants = yield* Turso.ManageDatabases(Tenants);
const acme = yield* tenants.create("acme");

Docs: Turso · Tutorial.

Authenticate an AWS profile with aws login (AWS CLI 2.32+), with no long-lived keys (#1759). alchemy profile refresh signs in again when the session expires:

aws login --profile my-console
alchemy profile edit --add AWS --method console-login --set loginProfile=my-console

Thanks jperezrealini!

Docs: AWS setup.

DSQL migrations

AWS.DSQL.Cluster applies SQL migrations when it deploys (#1544). Each statement runs in its own transaction, and CREATE INDEX becomes CREATE INDEX ASYNC. SQL that DSQL can’t run is rejected before the cluster is touched:

const database = yield* AWS.DSQL.Cluster("Database", {
  migrations: "./migrations",
});

Thanks carlulsoe!

Docs: Drizzle on DSQL.

Neon roles

Neon.Role creates a Postgres role on a branch, with a stable password (#2078):

const app = yield* Neon.Role("App", { branch });
const owner = yield* Neon.Role("Owner", { branch, name: "app_owner", noLogin: true });

Every Neon role has owner-level access to the branch’s databases.

Docs: Roles.

Kubernetes secrets and drift

Redacted values in a Kubernetes.Manifest or Kubernetes.HelmChart now reach the cluster as the real secret (#1948). Before, the cluster stored the placeholder <redacted>. Plans and state still keep the value wrapped:

yield* Kubernetes.Manifest("Token", {
  cluster,
  manifest: {
    apiVersion: "v1",
    kind: "Secret",
    metadata: { name: "token" },
    stringData: { token: Redacted.make(token) },
  },
});

yield* Kubernetes.HelmChart("App", {
  cluster,
  chart: "./chart",
  values: { apiKey: Redacted.make(apiKey) },
});

API errors and Helm output are scrubbed of those secrets, including their base64 and JSON-escaped forms. Destroy fails when the cluster refuses a delete (403 or 5xx) instead of reporting success, and calls to an unreachable API server time out. alchemy drift now reports in-cluster edits to the fields you declared, such as an image or replica count.

Kubernetes.Deployment also takes the cluster resource directly, so its props can be a plain object (#2005):

export default Kubernetes.Deployment(
  "Api",
  Effect.gen(function* () {
    return { main: import.meta.url, cluster: yield* Gke, port: 3000 };
  }),
  { main: import.meta.url, cluster: Gke, port: 3000 },
  impl,
);

Neon.Function takes branch and project the same way.

Docs: Kubernetes.

93 bug fixes

This release merges 93 fixes: 29 for Cloudflare and its local runtime, 23 for AWS, 8 for Docker, and the rest across PlanetScale, the CLI, Prisma, GCP, frontend frameworks, Neon, floci, and more.

One of them, #2174, fixes the resource leaks, slow deletes, and flaky tests that kept the live AWS, Cloudflare, and GCP suites from passing with clean accounts. For example, deleting a Lambda function no longer waits about 40 seconds for its log group, interrupted creates on CloudFront and Vertex AI are cleaned up instead of leaked, and a replaced ACM PCA certificate authority no longer keeps its old policy.

The full list is in the CHANGELOG.

Also in this release

QueueSink (#1781) drains an Effect Stream into a Queue, in batches Cloudflare accepts.
Bind a Worker’s own entrypoints (#2115, #2161) — Cloudflare.WorkerEntrypoint<Api>("Api") without a Worker targets the Worker that declares it, and Effect Workers call themselves through ctx.exports.
R2 bucket locks (#1984) with locks on R2.Bucket, and R2.S3Credentials tokens are scoped to their bucket (#1985) instead of every bucket in the account. Thanks 0x0f0f0f!
AI crawler policies on BotManagement (#1911), Ssl.CertificateTransparencyAlerting (#1913), and email sending events on Queues (#1914). Thanks birbprophet!
MtlsCertificate.Fetch (#2051) calls an origin with a client certificate from an Effect Worker. Thanks TBIQ007!
Durable Object namespaces support jurisdiction (#2007) and get, idFromName, idFromString, newUniqueId (#852). Thanks Makisuo and Butch78!
Workers AI reports billed neurons on finish parts (#1724), and streamed text, tool calls, and reasoning are fixed (#2064).
DynamoDB HTTP bindings from Cloudflare Workers (#1782).
logging.retention on Lambda Functions and ECS Tasks (#2042) and an opt-in recoveryWindowInDays on Secrets Manager secrets (#2053). Thanks TBIQ007!
Lambda timeouts are traced (#1494) — the root span ends and telemetry flushes timeoutMargin before the timeout.
AWS.providers() and AWS.state() use a provided AWSEnvironment (#1933). Thanks Bjorn Pagen!
GCP: IAM service accounts, project services, and private GKE (#1995), BigQuery views and external tables (#2082), and in-place databaseVersion upgrades on Cloud SQL (#2029). Thanks connyay and bartek671!
PlanetScale deletionProtection (#1861) — thanks agcty! — and an edited migration that already ran now replaces a dev branch or fails on production (#1489).
Docker runtime options (networkMode, capAdd, devices) and ordered envFiles (#1946, #1947), Podman (#2095), and authenticated image builds (#1858). Thanks bjorntechTobbe, armancharan, and EthanShoeDev!
Railway.Service delete only removes its own environment’s instance (#2184).
SvelteKit 3.0 (#2060) and a faster CLI with a simpler launcher (#2151). Thanks BlankParticle!
alchemy dev on AWS no longer hangs when Docker can’t publish an emulator port (#2215, #2217).

Where to go next

Containers · Container lifecycle
K2 · Pipelines · Iceberg tables
Hyperdrive private databases · Federated APIs
Durable Objects · Workers · Access
Kubernetes
Turso · AWS setup · Drizzle on DSQL · Neon roles
CHANGELOG
Compare v2.0.0-beta.81 → v2.0.0-beta.83

2.0.0-beta.80 - GCP, Neon & Secret Providers

Tue, 29 Sep 2026 09:00:00 GMT

beta.80 has three headline additions. Google Cloud arrives with about 1,050 resources across 190 services, Effect-native runtimes on Cloud Run, Cloud Functions, and GKE, and bindings that grant each host the narrowest IAM role GCP allows. Neon becomes a full backend provider: Functions, object storage, managed Auth, the Data API, AI Gateway, and 13 Neon.Website frameworks, all in one stack. Secret providers let a stack load its Config from dotenv files, Doppler, or Infisical, per stage, with browser login on your machine and OIDC in CI.

Effect 4.0 stable is now the baseline. Prisma ORM v8 also lands with an Effect-native Postgres runtime. A Fly.Service is now its own App with a public URL, typed calls to other Services, blue/green deploys, and multi-container Machines, and --include / --exclude deploy a slice of a stack. On Cloudflare: durable callbacks, hibernating WebSocket RPC, presigned R2 URLs under alchemy dev, and Queue subscriptions from any resource.

Breaking changes

Effect 4.0 stable is the new baseline (#1894, #1899). Upgrade effect and the Effect platform packages together:

bun add https://pkg.alchemy.run/alchemy/bea0366 effect@^4.0.0 @effect/platform-bun@^4.0.0 @effect/platform-node@^4.0.0

Better Auth 1.7.5+ (#1732). Drizzle users install @better-auth/drizzle-adapter, adopt Relations v2, and regenerate the auth schema. Custom secondary storage must implement increment(key, ttlSeconds) with a required TTL, and increment / getAndDelete must be atomic. See Upgrading from 1.6 to 1.7.
Cloudflare.AI.Model is now the Workers AI catalog resource (#1722). The AI Search model-name type that used this name is now AI.SearchModel.
JavaScript Workers default to new_module_registry (#1663) in deploys, alchemy dev, and Vite preview. Opt out with compatibility: { flags: ["legacy_module_registry"] }. Python Workers are unchanged.
Fly.Machine has no url (#1794). Use a Fly.Service when you need an endpoint.
Durable Object transactions are stricter (#1668). Storage access from a sibling fiber inside storage.transaction, and writes after txn.rollback(), now fail.
@distilled.cloud/hetzner exports services from the package root (#1784). Only affects code that calls the SDK directly:
```
import { Services } from "@distilled.cloud/hetzner";
Services.servers.getServer({ id });
import * as Hetzner from "@distilled.cloud/hetzner";
Hetzner.servers.getServer({ id });
```
The latest distilled also renames Fly’s updateMachineMetadata to patchMachineMetadata and PlanetScale’s createKeyspaceResizeRequest to updateKeyspaceResizeRequest, and the Railway SDK moves to Query.fn lenses (#1891).

Google Cloud

alchemy/GCP is a new provider (#1336) — thanks Michael K! It covers about 1,050 resources across 190 services, with Effect-native runtimes on every GCP compute host:

Host	Effect runtime
`GCP.Function` (a Cloud Run Service)	`fetch`
`GCP.Run.Job`	`run`, exits on completion
`GCP.Run.WorkerPool`	`run`, long-lived
`GCP.CloudFunctions.Function`	`fetch` on Node 22
`Kubernetes.Deployment` / `Job` on GKE	same as EKS, through Workload Identity

Bindings follow the same shape as AWS and Cloudflare. Each yield* grants one role to the host’s runtime service account, scoped as tightly as GCP allows, and the grant is revoked when the binding is removed.

Here is an order service: a Cloud Run API that stores orders in Firestore and publishes an event, and a second service that consumes those events from Pub/Sub. Start with the database and the queue:

src/resources.ts

import * as GCP from "alchemy/GCP";

export const Orders = GCP.Firestore.Database("Orders", {
  location: "us-central1",
  type: "FIRESTORE_NATIVE",
});

export const OrderEvents = GCP.PubSub.Topic("OrderEvents", {});

Websites on Cloud Run

GCP.Website adds framework websites and StaticSite on Cloud Run (#1898). Choose from Next.js, Nuxt, Astro, SvelteKit, TanStack Start, React Router, SolidStart, Waku, Vite, Vocs, Vinext, Foldkit, and Octane. The shared options cover public access, ingress, scaling, and container resources.

const site = yield* GCP.Website.Nextjs("Web", {
  rootDir: "./web",
});

A database

The API writes each order to Firestore and announces it on the topic:

src/Api.ts

import * as GCP from "alchemy/GCP";
import * as Effect from "effect/Effect";
import { HttpServerRequest } from "effect/http/HttpServerRequest";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import { OrderEvents, Orders } from "./resources.ts";

export default class Api extends GCP.Function<Api>()(
  "Api",
  { main: import.meta.url, location: "us-central1", invokerIamDisabled: true },
  Effect.gen(function* () {
    // datastore.user, under an IAM Condition naming only this database
    const db = yield* GCP.Firestore.ReadWriteDatabase(Orders);
    // pubsub.publisher on this topic only
    const events = yield* GCP.PubSub.WriteTopic(OrderEvents);

    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        const { email, total } = (yield* request.json) as { email: string; total: number };
        const orderId = crypto.randomUUID();

        yield* db.set(`orders/${orderId}`, { email, total, status: "created" });
        yield* events.publish({ data: JSON.stringify({ orderId, email, total }) });

        return yield* HttpServerResponse.json({ orderId }, { status: 202 });
      }).pipe(Effect.orDie),
    };
  }).pipe(
    Effect.provide([GCP.Firestore.ReadWriteDatabaseHttp, GCP.PubSub.WriteTopicHttp]),
  ),
) {}

A queue consumer

The Fulfillment service subscribes to the topic and marks each order fulfilled. consumeTopicMessages creates the push subscription and the route it delivers to:

src/Fulfillment.ts

import * as GCP from "alchemy/GCP";
import * as Effect from "effect/Effect";
import * as Stream from "effect/Stream";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import { OrderEvents, Orders } from "./resources.ts";

export default class Fulfillment extends GCP.Function<Fulfillment>()(
  "Fulfillment",
  { main: import.meta.url, location: "us-central1" },
  Effect.gen(function* () {
    const db = yield* GCP.Firestore.WriteDatabase(Orders);

    yield* GCP.PubSub.consumeTopicMessages(OrderEvents, (messages) =>
      messages.pipe(
        Stream.runForEach(({ message }) =>
          Effect.gen(function* () {
            const { orderId } = JSON.parse(
              Buffer.from(message.data ?? "", "base64").toString("utf8"),
            ) as { orderId: string };
            yield* db.update(`orders/${orderId}`, { status: "fulfilled" });
          }),
        ),
        // A failure answers the push with a 500, so Pub/Sub redelivers.
        Effect.orDie,
      ),
    );

    return { fetch: Effect.succeed(HttpServerResponse.text("ok")) };
  }).pipe(
    Effect.provide([GCP.Run.TopicEventSource, GCP.Firestore.WriteDatabaseHttp]),
  ),
) {}

Fulfillment has no public URL. Pub/Sub signs each push with an OIDC token for the service’s own account, which gets run.invoker on the service, and every request’s token is verified before the handler runs. Jobs and WorkerPools consume the same topic by pulling instead, with GCP.Run.TopicPullEventSource.

Add both services to a stack:

alchemy.run.ts

import * as Alchemy from "alchemy";
import * as GCP from "alchemy/GCP";
import * as Effect from "effect/Effect";
import Api from "./src/Api.ts";
import Fulfillment from "./src/Fulfillment.ts";

export default Alchemy.Stack(
  "Orders",
  { providers: GCP.providers(), state: Alchemy.localState() },
  Effect.gen(function* () {
    const api = yield* Api;
    yield* Fulfillment;
    return { url: api.uri };
  }),
);

Storage, Pub/Sub, Firestore, and BigQuery have Read / Write / ReadWrite clients. GCP.SQL.Connect reaches Cloud SQL, GCP.Run.InvokeService calls another private service with a Google-signed ID token, and GCP.AIPlatform.GenerateContent calls Gemini. Besides Pub/Sub, event sources cover Storage, Cloud Scheduler, and Eventarc.

The default region comes from your profile (else us-central1), and GCP.Region("europe-west1") overrides it for a stack. Reconciles wait until GCP reports a resource ready, deletes wait until it is gone, and pnpm nuke:gcp clears a test project. Sixteen examples — including gcp-pubsub-fanout, gcp-event-pipeline, gcp-cloud-sql-drizzle, gcp-vertex-ai, and gcp-gke — each pass a live deploy-and-destroy test.

Docs: GCP · Setup · Bindings · Event pipeline.

Neon: Functions, storage, Auth, and websites

alchemy/Neon grows from Projects and Branches into a full backend (#1695). A Neon.Function runs a native Fetch handler or an Effect program on Node 24, and bindings wire in Postgres and object storage without passing your deployment API key to the application:

src/resources.ts

export const Backend = Effect.gen(function* () {
  const project = yield* Neon.Project("Db", {
    region: "aws-us-east-2",
    migrations: "./migrations",
  });
  const uploads = yield* Neon.Bucket("Uploads", { project, access: "private" });
  return { project, uploads };
});

src/api.ts

export default class Api extends Neon.Function<Api>()(
  "Api",
  Effect.gen(function* () {
    const { project } = yield* Backend;
    return { project, main: import.meta.url };
  }),
  Effect.gen(function* () {
    const { project, uploads } = yield* Backend;
    const db = yield* Neon.Connect(project);
    const sql = yield* SQL.Postgres({ url: db.connectionString });
    const files = yield* Neon.WriteBucket(uploads);

    return {
      fetch: Effect.gen(function* () {
        const rows = yield* sql`SELECT now() AS time`;
        yield* files.put("latest.json", JSON.stringify(rows));
        return yield* HttpServerResponse.json(rows);
      }).pipe(Effect.orDie),
    };
  }).pipe(Effect.provide([Neon.ConnectHttp, Neon.WriteBucketHttp])),
) {}

Thirteen frameworks deploy as Fetch Functions, with the same props as on the other providers:

alchemy.run.ts

export default Alchemy.Stack(
  "App",
  { providers: Neon.providers(), state: Alchemy.localState() },
  Effect.gen(function* () {
    const api = yield* Api;
    const site = yield* Prisma.Website.Astro("Blog", {
    const site = yield* Neon.Website.Astro("Blog", {
      rootDir: "./apps/blog",
      env: { API_BASE: api.url },
    });
    return { url: site.url };
  }),
);

Also in the box:

Storage — Bucket, typed Object<T> seed values, Read/Write/ReadWrite bucket and object bindings, and presigned GET/PUT URLs.
Auth — managed Better Auth with AuthOAuthProvider, AuthTrustedDomain, and a ConnectAuth binding for the Auth and JWKS URLs.
Data API — DataApi configures PostgREST; QueryDataApi forwards the caller’s JWT so row-level security applies.
AI Gateway — QueryAIGateway plus makeLanguageModelLayer for Effect AI’s LanguageModel.
Events — CronEventSource and BucketEventSource register a typed handler and its trigger in one call.
Operations — Credential, CustomDomain, and experimental organization governance: API keys, member roles, spending limits, and VPC endpoints.

alchemy dev runs each website’s native framework server and a local Fetch runtime for Functions; .pipe(Alchemy.remote()) deploys one for real.

Docs: Neon · Tutorial · Preview branches · Production Auth.

Secret providers: dotenv, Doppler, and Infisical

A stack now chooses where its secrets come from (#1728) — thanks Rahul Mishra! Every Config.Redacted("DATABASE_URL") in your program — in the stack, in a resource provider, or captured by a Worker or Lambda — resolves from the list you give Alchemy.Stack’s new secrets option. Nothing is written to process.env or to disk.

alchemy.run.ts

import * as Alchemy from "alchemy";
import * as Cloudflare from "alchemy/Cloudflare";
import * as Doppler from "alchemy/Doppler";
import * as Effect from "effect/Effect";
import Api from "./src/api.ts";

export default Alchemy.Stack(
  "MyApp",
  {
    providers: Cloudflare.providers(),
    state: Cloudflare.state(),
    secrets: [
      Doppler.Secrets(({ stage }) => ({
        project: "my-app",
        config: stage === "prod" ? "prd" : "dev",
      })),
      Alchemy.Secrets.DotEnv(),
    ],
  },
  Effect.gen(function* () {
    const api = yield* Api;
    return { url: api.url };
  }),
);

The Worker reads the secret the same way it always has:

src/api.ts

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const databaseUrl = yield* Config.Redacted("DATABASE_URL");
    const sql = yield* SQL.Postgres({ url: Effect.succeed(databaseUrl) });
    return {
      fetch: Effect.gen(function* () {
        return yield* HttpServerResponse.json(yield* sql`SELECT now() AS time`);
      }).pipe(Effect.orDie),
    };
  }),
) {}

Rotating the value in Doppler and running alchemy deploy now ships it: a changed Config value read during a Worker’s Init plans an update (#1837).

Precedence

Later entries override earlier ones. A missing key falls through to the next source, and an empty string counts as a value. The process environment is always the implicit last entry, so a one-off DATABASE_URL=… alchemy deploy or a CI runner’s exported variables still win. List Alchemy.Secrets.ProcessEnv() yourself to rank it elsewhere, or pass { disabled: true } to leave the shell out.

Per stage

secrets and every provider’s options also accept a callback that receives the stage, so one stack serves dev, pr-42, and prod from different places:

secrets: ({ stage }) =>
  stage === "dev"
    ? Alchemy.Secrets.DotEnv({ path: [".env", ".env.local"] })
    : Infisical.Secrets({ project: "my-app", environment: stage, path: "/api" }),

Logging in, locally and in CI

On your machine, alchemy profile edit --add Doppler opens a browser login, and alchemy profile edit --add Infisical stores a Universal Auth machine identity or a user token. In CI, set DOPPLER_TOKEN / INFISICAL_TOKEN, or skip long-lived tokens entirely with OIDC: set DOPPLER_IDENTITY_ID or INFISICAL_IDENTITY_ID, and Alchemy exchanges the platform’s identity token on GitHub Actions, GitLab CI, Vercel, or Google Cloud for a short-lived one on every run:

jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    steps:
      - run: bun alchemy deploy --stage prod --yes
        env:
          DOPPLER_IDENTITY_ID: ${{ vars.DOPPLER_IDENTITY_ID }}

--log-level debug prints which variable names each source loaded, never their values. Any Effect Layer that provides a ConfigProvider works as a custom entry.

Docs: Secret providers · Doppler · Infisical.

Prisma ORM v8

Prisma ORM v8 runs on an Effect-native Postgres runtime (#1198). Queries, prepared statements, streams, and transactions are Effects with typed errors and per-execution connection cleanup. Write the contract in TypeScript or in Prisma Schema Language (PSL); both use the same runtime. Prisma stays an optional peer.

TypeScript-first

Define the contract with Prisma’s own builders:

src/prisma/contract.ts

import { defineContract } from "alchemy/Prisma/ORM";

export const contract = defineContract({}, ({ field, model, rel }) => ({
  models: {
    User: model("User", {
      fields: {
        id: field.id.uuidv7Native(),
        email: field.text().unique(),
        name: field.text(),
      },
      relations: { posts: rel.hasMany("Post", { by: "authorId" }) },
    }),
    Post: model("Post", {
      fields: {
        id: field.id.uuidv7Native(),
        title: field.text(),
        authorId: field.uuidNative(),
      },
      relations: { author: rel.belongsTo("User", { from: "authorId", to: "id" }) },
    }),
  },
}));

Pass it straight to Postgres — no generated code:

src/api.ts

import * as Cloudflare from "alchemy/Cloudflare";
import * as PrismaPostgres from "alchemy/Prisma/ORM/Postgres";
import * as Effect from "effect/Effect";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import { Hyperdrive } from "./db.ts";
import { contract } from "./prisma/contract.ts";

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const conn = yield* Cloudflare.Hyperdrive.Connect(Hyperdrive);
    const db = yield* PrismaPostgres.Postgres(conn.connectionString, { contract });

    return {
      fetch: Effect.gen(function* () {
        const users = yield* db.orm.public.User.include("posts").all();
        return yield* HttpServerResponse.json({ users });
      }).pipe(Effect.orDie),
    };
  }).pipe(Effect.provide(Cloudflare.Hyperdrive.ConnectBinding)),
) {}

PSL-first

Keep contract.psl authoritative:

src/prisma/contract.psl

model User {
  id    id.uuidv7Native()
  email String @unique
  name  String
  posts Post[]
}

model Post {
  id       id.uuidv7Native()
  title    String
  authorId Uuid
  author   User @relation(fields: [authorId], references: [id])
}

prisma.config.ts

import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";
import { definePrismaConfig } from "prisma/config";
import { withEffect } from "alchemy/Prisma/ORM/generator";

export default definePrismaConfig({
  orm: withEffect(
    ormConfig({
      contract: "./src/prisma/contract.psl",
      output: "./src/prisma/generated",
    }),
    { client: true, schemas: true },
  ),
});

The Worker imports the generated makeDatabase instead of the contract; queries are identical:

import * as PrismaPostgres from "alchemy/Prisma/ORM/Postgres";
import { contract } from "./prisma/contract.ts";
import { makeDatabase } from "./prisma/generated/client.ts";

  Effect.gen(function* () {
    const conn = yield* Cloudflare.Hyperdrive.Connect(Hyperdrive);
    const db = yield* PrismaPostgres.Postgres(conn.connectionString, { contract });
    const db = yield* makeDatabase(conn.connectionString);

Both forms can also produce standalone Effect Schemas for rows — makeSchemas(contract) or the generated schemas.ts. The cloudflare-neon-prisma and cloudflare-neon-prisma-psl examples run each form end to end on Neon through Hyperdrive, with migrations applied on deploy by Prisma.Contract and Prisma.Migrate.

Docs: Contracts · Postgres · Migrations.

Fly: a Service owns its App

A Fly.Service is now its own Fly App with its own public URL (#1794). You no longer declare an App and an IP address first:

export const Site = Fly.App("Site");
export const PublicIp = Fly.IpAssignment("Shared", { app: Site, type: "shared_v4" });

export default class Api extends Fly.Service<Api>()(
  "Api",
  { app: Site, main: import.meta.url },
  { main: import.meta.url },
  Effect.gen(function* () {
    return { fetch: Effect.succeed(HttpServerResponse.text("hello")) };
  }),
) {}

public: false keeps a Service off the internet. A Service can return methods beside fetch, and another Service binds it with Fly.bindService for a typed client:

src/users.ts

export default class Users extends Fly.Service<Users>()(
  "Users",
  { main: import.meta.url, public: false },
  Effect.gen(function* () {
    return { list: () => Effect.succeed(USERS) };
  }),
) {}

// src/gateway.ts
export default class Gateway extends Fly.Service<Gateway>()(
  "Gateway",
  { main: import.meta.url },
  Effect.gen(function* () {
    const users = yield* Fly.bindService(Users);
    return {
      fetch: Effect.gen(function* () {
        return yield* HttpServerResponse.json(yield* users.list());
      }).pipe(Effect.orDie),
    };
  }),
) {}

Calls are plain HTTP over Flycast. Each one carries the caller’s token and Fly’s signed Fly-Src header, so only Services that bind Users can call it. network: yield* Fly.stackNetwork isolates Services on a private network per stack and stage, and region: ["iad", "lhr"] runs count Machines in each region behind one hostname.

Blue/green deploys

Add deploy: { strategy: "bluegreen" } and the next alchemy deploy starts a checked replacement before stopping the running version (#1706). shutdown gives in-flight responses time to finish:

export default class Api extends Fly.Service<Api>()(
  "Api",
  {
    main: import.meta.url,
    deploy: { strategy: "bluegreen" },
    shutdown: { timeout: "60 seconds" },
  },

Websites take the same two props. An interrupted rollout resumes on the next deploy, and a failed readiness check leaves the old version serving. Rolling updates stay the default and remain the only option for volume-backed Services.

Multi-container Machines

Run an API and its sidecar in one Machine with Fly’s native container groups, rolling or blue/green (#1768, #1769) — thanks Florian Bienefelt!

export const App = Fly.App("Preview");

export const Preview = Fly.Machine("Preview", {
  app: App,
  containers: [
    {
      name: "api",
      image: "ghcr.io/acme/api:v3",
      healthChecks: [{ http: { port: 3000, path: "/health" } }],
    },
    {
      name: "worker",
      image: "ghcr.io/acme/worker:v3",
      dependsOn: [{ name: "api", condition: "healthy" }],
    },
  ],
});

Florian also added Flycast private_v6 addresses to Fly.IpAssignment (#1749) and made rolling updates wait for service checks before touching the next replica (#1670). Fly bindings now carry their values through the runtime context (#1554) — thanks Michael K!

Docs: Services · Connecting Services · Deployments · Networking.

Deploy part of a stack

--include and --exclude reconcile a subset of resources and Actions (#1757). Each flag takes an FQN, a logical ID, or a glob, and can repeat:

alchemy deploy --stage pr-123 --include 'Database/**'
alchemy dev --exclude 'Services/Background/**'
alchemy plan --include 'Database/Branch' --include 'Database/Password'

Dependencies of included resources come along automatically; excluding one fails the plan with its dependency chain. Excluded state is left untouched. Test.make’s deploy takes the same filters:

const { test, deploy } = Test.make({ providers: Cloudflare.providers() });

test(
  "migrates the database",
  Effect.gen(function* () {
    yield* deploy(Stack, { include: ["Database/**"] });
  }),
);

Durable callbacks

Alchemy.makeCallback schedules typed work that survives the request (#1668). Durable Objects are the first host: jobs live in SQLite and fire from native alarms, and scheduling joins the storage transaction, so the write and the job commit together:

export default class Document extends Cloudflare.DurableObject<Document>()(
  "Document",
  Effect.gen(function* () {
    const state = yield* Cloudflare.DurableObjectState;
    return Effect.gen(function* () {
      const onSnapshot = yield* Alchemy.makeCallback(
        "snapshot",
        Effect.fn(function* (payload: { revision: string; body: string }) {
          yield* state.storage.put(`revisions:${payload.revision}`, payload.body);
        }),
      );

      return {
        save: Effect.fn(function* (revision: string, body: string) {
          yield* state.storage.transaction(
            Effect.gen(function* () {
              yield* state.storage.put("document", { revision, body });
              yield* onSnapshot.schedule(revision, {
                after: "30 seconds",
                payload: { revision, body },
              });
            }),
          );
        }),
      };
    });
  }),
) {}

Delivery is at least once with retries. Existing scheduleEvent jobs keep running beside callbacks on the object’s single alarm. Alarm updates are now batched once per transaction (#1701).

Docs: Durable Objects → Register a durable callback.

Hibernating WebSocket RPC

An RpcDurableObject that returns its handler Layer now serves Effect RPC over hibernating WebSockets as well as HTTP (#1705). The request picks the transport; your code doesn’t change.

Define the RPCs once and share them between server and client:

rpcs.ts

import * as Schema from "effect/Schema";
import { Rpc, RpcGroup } from "effect/rpc";

export class CounterRpcs extends RpcGroup.make(
  Rpc.make("increment", { payload: {}, success: Schema.Number }),
) {}

Implement them in an RpcDurableObject:

counter.ts

import * as Cloudflare from "alchemy/Cloudflare";
import * as Effect from "effect/Effect";
import { CounterRpcs } from "./rpcs.ts";

export default class Counter extends Cloudflare.RpcDurableObject<Counter>()(
  "Counter",
  { schema: CounterRpcs },
  Effect.gen(function* () {
    const state = yield* Cloudflare.DurableObjectState;
    return Effect.gen(function* () {
      return CounterRpcs.toLayer({
        increment: () =>
          state.storage.transaction(
            state.storage.get<number>("count").pipe(
              Effect.map((n) => (n ?? 0) + 1),
              Effect.tap((n) => state.storage.put("count", n)),
            ),
          ).pipe(Effect.orDie),
      });
    });
  }),
) {}

The Worker picks an object by name and forwards the connection to it:

worker.ts

import * as Cloudflare from "alchemy/Cloudflare";
import * as Effect from "effect/Effect";
import { HttpServerRequest } from "effect/http/HttpServerRequest";
import * as HttpServerResponse from "effect/http/HttpServerResponse";
import Counter from "./counter.ts";

export default class CounterWorker extends Cloudflare.Worker<CounterWorker>()(
  "CounterWorker",
  { main: import.meta.url },
  Effect.gen(function* () {
    const counters = yield* Counter;
    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        const path = new URL(request.url, "https://worker").pathname;
        const name = /^\/counters\/([\w-]+)$/.exec(path)?.[1];
        if (!name) return HttpServerResponse.empty({ status: 404 });
        return yield* counters.fetch(name, request);
      }),
    };
  }),
) {}

In the browser, alchemy/Cloudflare/RpcWebSocketClient builds a typed client over one WebSocket. It imports only Effect modules, so it is safe to bundle:

client.ts

import * as RpcWebSocketClient from "alchemy/Cloudflare/RpcWebSocketClient";
import * as Context from "effect/Context";
import * as Effect from "effect/Effect";
import * as Layer from "effect/Layer";
import * as RpcClient from "effect/rpc/RpcClient";
import type { RpcClientError } from "effect/rpc/RpcClientError";
import * as Socket from "effect/socket/Socket";
import { CounterRpcs } from "./rpcs.ts";

class CounterClient extends Context.Service<
  CounterClient,
  RpcClient.FromGroup<typeof CounterRpcs, RpcClientError>
>()("CounterClient") {}

const CounterClientLive = RpcWebSocketClient.layer(
  CounterClient,
  CounterRpcs,
  "wss://example.com/counters/alice",
).pipe(Layer.provide(Socket.layerWebSocketConstructorGlobal));

const program = Effect.gen(function* () {
  const counter = yield* CounterClient;
  return yield* counter.increment({});
}).pipe(Effect.provide(CounterClientLive));

Every call on that socket goes to the "alice" object. While the connection is idle the Durable Object can hibernate; the next call wakes it and is answered on the same socket. Alchemy handles the heartbeats and restores the connection after a wake. In-flight calls are not replayed: if the object restarts mid-call, the socket closes with code 1012.

Docs: Effect RPC → HTTP and WebSocket RPC · Forward browser connections.

Typed WebSocket attachments

If you write your own WebSocket handlers on a plain DurableObject instead of using RPC, you can now validate the data you attach to each socket with an Effect Schema (#1723). A session read back after hibernation comes back decoded and typed, where deserializeAttachment used to return an unchecked value:

room.ts

import * as Cloudflare from "alchemy/Cloudflare";
import * as Effect from "effect/Effect";
import * as Schema from "effect/Schema";

const Session = Schema.Struct({
  id: Schema.String,
  joinedAt: Schema.DateFromString,
});

export default class Room extends Cloudflare.DurableObject<Room>()(
  "Rooms",
  Effect.gen(function* () {
    return Effect.gen(function* () {
      return {
        fetch: Effect.gen(function* () {
          const [response, socket] = yield* Cloudflare.upgrade();
          const joinedAt = yield* Effect.sync(() => new Date());
          yield* socket.setAttachment(Session, { id: crypto.randomUUID(), joinedAt });
          return response;
        }),
        webSocketMessage: Effect.fn(function* (socket: Cloudflare.WebSocket) {
          const session = yield* socket.getAttachment(Session); // joinedAt: Date
          yield* socket.send(`joined ${session.joinedAt.toISOString()}`);
        }),
      };
    });
  }),
) {}

A missing or invalid attachment fails with a typed WebSocketAttachmentError, so you decide whether to close the socket or ignore it.

Docs: Hibernatable WebSockets → Validate attachments after hibernation.

Presigned R2 URLs in `alchemy dev`

Presigned R2 URLs and S3 clients work under alchemy dev with no extra configuration (#1793). The same code signs against the Worker’s local dev URL in dev and against r2.cloudflarestorage.com when deployed:

export const Uploads = Cloudflare.R2.Bucket("Uploads");

export default Cloudflare.Worker(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const presignPut = yield* Cloudflare.R2.PresignPutObject(Uploads);
    return {
      fetch: Effect.gen(function* () {
        const url = yield* presignPut({ key: "uploads/a.png", contentType: "image/png" });
        return yield* HttpServerResponse.json({ url });
      }).pipe(Effect.orDie),
    };
  }).pipe(Effect.provide(Cloudflare.R2.PresignPutObjectToken)),
);

Async Workers get the same thing through Cloudflare.R2.S3Credentials(bucket, { access: "write" }), which delivers an endpoint and scoped keys for any S3 client. The local S3 endpoint runs inside the Worker’s existing workerd process, and the dev proxy now answers Expect: 100-continue, which took a 3 MB AWS SDK PutObject from ~6 s to ~130 ms.

Docs: R2 presigned URLs.

Queue subscriptions from any resource

Cloudflare.Queues.Subscription accepts a resource or a .ref(...) as its source (#1722, #1505) — including one owned by another stack:

export const BucketEvents = Effect.gen(function* () {
  const queue = yield* Cloudflare.Queues.Queue("Events");
  const uploads = yield* Cloudflare.R2.Bucket.ref("Uploads", {
    stack: "storage",
    stage: "prod",
  });
  return yield* Cloudflare.Queues.Subscription("BucketEvents", {
    source: uploads,
    events: ["bucket.created", "bucket.deleted"],
    queueId: queue.queueId,
  });
});

Sources include Images, KV, R2, Vectorize, Workers, Workflows, and two new resources: AI.Model, a handle on a Workers AI catalog model, and R2.SuperSlurperJob, a one-off migration into R2 from S3 or another bucket. Thanks Alex for the Workflow sources and Cloudflare.Workflow.ref!

Docs: Queues → Use resources as event sources.

ACME certificates

alchemy/ACME issues and renews certificates from Let’s Encrypt or any ACME CA, independent of where they are used (#1702). Cloudflare.DNS.AcmeSolver answers DNS-01 challenges:

export const Site = Fly.App("Site");

export const Wildcard = Effect.gen(function* () {
  const account = yield* ACME.Account("LetsEncrypt", {
    ca: ACME.LetsEncrypt,
    termsOfServiceAgreed: true,
  });
  const certificate = yield* ACME.Certificate("Wildcard", {
    account,
    identifiers: ["*.example.com"],
    solver: Cloudflare.DNS.AcmeSolver({
      zoneId: Config.String("CLOUDFLARE_ZONE_ID"),
    }),
  });
  return yield* Fly.Certificate("Upload", {
    app: Site,
    hostname: "*.example.com",
    kind: "custom",
    fullchain: certificate.chain,
    privateKey: certificate.privateKey,
  });
});

ACME.IssueCertificate binds an account into a Worker or Service for runtime issuance, and Fly.WriteCertificates manages an App’s certificates at runtime.

Docs: ACME · Getting started.

Kubernetes on any cluster

Kubernetes.LocalCluster starts a kind cluster with a local image registry, and any connection can now name a registry, so workloads built from main or a Docker context deploy to GKE, AKS, k3s, or your laptop (#1779):

export const Cluster = Effect.gen(function* () {
  const stage = yield* Alchemy.Stage;
  if (stage === "prod") {
    // any cluster kubectl can reach
    return Kubernetes.KubeConfig({
      context: "prod",
      registry: { server: "ghcr.io/acme" },
      architecture: "arm64",
    });
  }
  return yield* Kubernetes.LocalCluster("Cluster", { name: "alchemy" });
});

Editing a Job or Deployment’s main program now redeploys it. A new /kubernetes docs hub has a five-part tutorial that starts on LocalCluster and ends on your own cluster.

Docs: Kubernetes · Tutorial · Local cluster.

Workflow tasks keep typed errors

Cloudflare.Workflows.task accepts fallible Effects (#1723). A failure follows the task’s retry policy; once retries run out, catchTag sees your error, including after Cloudflare replays the step:

class CardDeclined extends Data.TaggedError("CardDeclined")<{
  reason: string;
}> {}

const chargeCard = (orderId: string) =>
  Effect.fail(new CardDeclined({ reason: `insufficient funds for ${orderId}` }));

export default class Checkout extends Cloudflare.Workflow<Checkout>()(
  "Checkout",
  Effect.gen(function* () {
    return Effect.fn(function* (input: { orderId: string }) {
      return yield* Cloudflare.Workflows.task("charge", chargeCard(input.orderId), {
        retries: { limit: 2, delay: "1 second", backoff: "exponential" },
      }).pipe(
        Effect.catchTag("CardDeclined", (error) =>
          Effect.succeed({ status: "declined" as const, reason: error.reason }),
        ),
      );
    });
  }),
) {}

Effect.orDie still makes a failure terminal. Workflows can also take an explicit account-global workflowName (#1460) — thanks Odysseas Papadimas! A retries-only step config no longer crashes the engine (#1142) — thanks apostoli! Each attempt gets its own scope (#1701).

Docs: Workflows → Application errors across replay.

Vinext support

Website.Vinext deploys vinext apps on Cloudflare, AWS, Fly, Hetzner, Railway, and Prisma (#1515) — thanks Ray! Keep your ordinary vinext() Vite config; no Alchemy plugin is needed.

export default Alchemy.Stack(
  "Web",
  { providers: Cloudflare.providers(), state: Cloudflare.state() },
  Effect.gen(function* () {
    const site = yield* Cloudflare.Website.Vinext("Web", {
      rootDir: "./app",
      env: { GREETING: "Hello from vinext!" },
    });
    return { url: site.url };
  }),
);

On Cloudflare it deploys a Worker with KV caching and prerender seeding, without Wrangler or OpenNext. AWS runs it on streaming Lambda with an S3 cache behind CloudFront. Fly, Hetzner, Railway, and Prisma run vinext’s Node server, with an in-memory cache by default and Redis through REDIS_URL. Swap the provider namespace to move the same app:

export default Alchemy.Stack(
  "Web",
  { providers: Cloudflare.providers(), state: Cloudflare.state() },
  { providers: AWS.providers(), state: AWS.state() },
  Effect.gen(function* () {
    const site = yield* Cloudflare.Website.Vinext("Web", {
    const site = yield* AWS.Website.Vinext("Web", {
      rootDir: "./app",
      env: { GREETING: "Hello from vinext!" },
    });
    return { url: site.url };
  }),
);

alchemy dev runs vinext’s native dev server with HMR, and .pipe(Alchemy.remote()) deploys it for real.

Docs: Cloudflare · AWS · Fly · Hetzner · Railway · Prisma.

Next.js and Octane with less config

Next.js on Cloudflare no longer needs open-next.config.ts, and writable ISR is one prop (#1747):

export const IncCache = Cloudflare.KV.Namespace("NextIncCache");
export const TagCache = Cloudflare.KV.Namespace("NextTagCache");

export const Website = Cloudflare.Website.Nextjs("Website", {
  env: {
    NEXT_INC_CACHE_KV: IncCache,
    NEXT_TAG_CACHE_KV: TagCache,
    NEXT_CACHE_DO_QUEUE: Cloudflare.DurableObject("NEXT_CACHE_DO_QUEUE", {
      className: "DOQueueHandler",
    }),
  },
  isr: { incrementalCache: IncCache, tagCache: TagCache },
});

Octane apps no longer need a hosting adapter in octane.config.ts on any provider (#1747, #1755, #1756). SvelteKit moves to 3.0.0-next.27, and the Node target now ships client assets and prerendered pages (#1709) — thanks Cameron McEvenue! The Next.js Node and Neon servers start from the built config, so a read-only deploy no longer tries to download SWC (#1805) — thanks Aman Varshney!

Docs: Frontend frameworks · Next.js · Octane.

Local development

No credentials needed for local-only stacks (#1801). Cloudflare authentication is deferred until a cloud call needs it, so a stack of local Workers, KV, R2, and D1 runs without a profile.
Provider credentials resolve on first use (#1902). Loading provider layers no longer requires credentials for every provider. When a cloud operation needs missing or unreadable credentials, plan and apply fail with CredentialsRequired.
workerd restarts after a crash (#1772) on the same ports, so the dev URL keeps working. Raise the isolate’s heap with ALCHEMY_WORKERD_V8_FLAGS=--max-old-space-size=4096 (#1771), and the Vite module runner no longer retains every old module graph across HMR edits (#1770). Thanks Alex!
Private Websites answer service-binding calls in dev (#1798) for SvelteKit, Nuxt, Octane, Next.js, Astro, Waku, and Vocs, and a Vite Worker with SPA fallback plus runWorkerFirst starts again (#1799). Thanks Rahul Mishra!

Also in this release

Provider requirements retain their types (#1895) — fixes prevent any and unknown from hiding required services in provider layers, with stronger validation for provider implementations.
Provider and runtime fixes for Effect stable (#1899) — Worker preview creation reuses an existing preview after a conflict, and lifecycle fixes cover ACME, CloudFront KeyValueStore, ECS, IAM SAML providers, IVS stream keys, Cloudflare AI evaluations, and Railway.
AWS Client VPN (#1714) — ClientVpnEndpoint, ClientVpnTargetNetworkAssociation, ClientVpnAuthorizationRule, and ClientVpnRoute.
AWS.EC2.DefaultSecurityGroup (#1630) manages the rules on a VPC’s default security group, and ECS Services deploy again after a failed rollout (#1650). Thanks Henning Pokriefke!
RDS master secret policy and security drift — masterUserSecretResourcePolicy on DBInstance (#1598), security settings converge from desired state (#1599), and a stopped or failed instance fails fast with DBInstanceReadinessBlocked (#1597). Thanks Bjorn Pagen!
Least-privilege AWS bindings (#1357) — exact IAM actions per capability, versioned S3 reads and copies, and S3 notification reconciliation across Lambda, SQS, SNS, and EventBridge. SQS queues also reconcile adoption and Standard ↔ FIFO changes. Thanks Saatvik Arya!
Cloudflare.Access.McpServer (#1658) registers upstream MCP servers with Access. Thanks Dillion Verma!
Container images shared across stages (#1692) — Container builds are cached by default, and publish: { repository: "web" } reuses images and layers across stages. Thanks Dan van der Merwe!
Cloudflare.Container.ref (#1750) — another stack can read a container application like any other resource. Thanks Cyberistic!
Durable Object SQL migrations load at construction (#1736) — yield* Cloudflare.SqlMigrations("./drizzle") replaces importing drizzle-kit’s migrations.js, and each migration commits atomically with its history row.
Worker build input options (#1700) — build.input passes Rolldown input options such as resolve.alias.
Cloudflare fixes — full deploys keep version.tag and version.message (#1754, thanks Luke O’Malley!), prebuilt Workers keep explicit compatibility flags (#1725), Workers-for-Platforms uploads keep _headers and _redirects (#1802), and DNS records only treat a missing record as gone (#1800).
Engine fixes — completed Actions reuse their outputs when inputs are unchanged, so downstream resources plan as no-ops (#1379, thanks Leonardo E. Dominguez!); changing a Config value read during a Worker’s Init now plans an update (#1837); and destroy cleans up every generation left by an interrupted replacement (#1704).
alchemy plan --adopt (#1811). Thanks Pedro Toledo!
Railway region places replicas (#1766) on Service and Function.
PlanetScale withReplication (#1777) on PostgresRole for logical-replication consumers. Thanks Makisuo!
Better Auth tutorial (#1732) — a six-part walkthrough from an Auth service to GitHub sign-in, adapted from work by xofromthemoon.
Prisma fixes — dev commands default to NODE_ENV=development (#1703) and alchemy/Prisma, Fly, Hetzner, Railway, and Neon import without @alchemy.run/frontend-frameworks installed (#1815). Thanks Aman Varshney, and Kristof Siket for live branch attachment coverage (#1359)!
Smaller installs — @effect/vitest is an optional peer again (#1816), and @aws-sdk/credential-providers, aws4fetch, and undici are gone (#1665, thanks Michael K!).
Runtime directories and process cleanup — a configured .alchemy directory is honored everywhere (#1726), and Command wrappers get SIGTERM and a second to clean up (#1760).
Declaration metadata (#1490) — Api.LogicalId keeps its literal type, and Stack references expose stackName.
Leaner preview packages (#1727, #1681) — a PR publishes only the packages it affects plus their dependencies, and fork PRs install from pkg.alchemy.run/alchemy/pr:<number>:<sha>. The CLI ships plain JavaScript entrypoints with generated package exports (#1707). Thanks Rahul Mishra!
Test runner tags and plans (#1773) — alchemy-test gains --tags expressions, phased --plan runs, and a --dry-run preview.
Faster API reference (#1767, #1774) — one page per service: 4,368 pages become 406, the docs build is 4× faster, and old URLs redirect.
SQL guides (#1737, #1744) — a database comparison and deployment guides for AWS (including Aurora and DSQL), Fly, Hetzner, Prisma, and Railway.
A new landing page (#1775, #1797) built around the dev → test → review → deploy loop, with a PR lifecycle benchmark you can run from examples/cloudflare-preview-benchmark.

Where to go next

GCP · Setup · Bindings
Neon · Tutorial
Secret providers · Doppler · Infisical
Prisma ORM contracts
Fly Services · Connecting Services · Deployments
Durable Objects · Effect RPC
R2 presigned URLs
ACME · Kubernetes
CHANGELOG
Compare v2.0.0-beta.79 → v2.0.0-beta.80

Optimizing Alchemy's CI Workflows

Thu, 24 Sep 2026 16:00:00 GMT

As of writing this, Alchemy is a monorepo of almost 100 packages (86 of them are distilled SDKs), with a docs website with thousands of generated pages, regular CI checks, preview package publishing, tests for our local cloudflare runtime and a release pipeline that publishes to npm. Over past few weeks we made several CI improvements to make it so the contributors and their agents can iterate fast.

Swapping out GitHub runners and Tooling

Our first immediate improvement came from moving our workflows to Blacksmith runners (#1162). Just by doing this we saw a huge improvement, let’s take a look at some numbers:

Workflow	Before	After
check	7.8 min	4.8 min	−38%
cloudflare-tools	16.2 min	5.3 min	−67%
pr-package	5.0 min	3.2 min	−36%

These numbers are compiled from a very short numbers of runs we had immediately after switching, since I started optimizing the CI pipeline soon after we don’t have much data to compare, but it’s clear that just by switching to Blacksmith made a difference already.

We also switched our package manager from bun to pnpm (#1214). Bun kept us giving trouble: it behaves weirdly around updating lock files when manually add/removing deps from package.json, fails randomly during install failures in CI, broke our publishing of packages when using workspace: and catalog: in dependencies, doesn’t respect publishConfig overrides, didn’t have deduping until 1.4, doesn’t work without pkg.alchemy.run preview URLs since it doesn’t dedupe tarball url deps, and the list goes on.

We are still supporting and using bun as our runtime, but our repo is stuck on bun 1.3.13 since later versions introduced a bug in AsyncLocalStorage which breaks our test runner. This is yet to be fixed and our blocker for upgrading bun.

All of our CI now runs on Blacksmith, except for npm releases. Npm trusted publishing only allows publishing from GitHub-hosted runners, GitLab.com, and CircleCI cloud. So we had to split releases in two jobs: build on Blacksmith, publish on GitHub. We don’t want this extra complexity, but npm has yet to allow trusted publishing from any other CI provider.

name: Release
jobs:
  build:
    runs-on: blacksmith-8vcpu-ubuntu-2404
    # Build, Pack, Upload tarballs
  publish:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      id-token: write
    # Publish tarballs using pnpm publish which handles everything

Making our website deploy faster

Our docs site is a content heavy site. It used to have over 4k+ pages (and paired OG image for each page), most of them being generated specs from our jsdoc. It would take up to 25 min building and deploying all those pages and assets. Astro 7.2 shipped experimental incremental builds, which skip building pages that haven’t changed. We enabled it, patched Starlight to support it, and persisted the cache across CI runs (#1128, #1136). Now a warm build restores most of the pages and almost all OG images.

But the biggest improvement came from changing how the API references are generated. We had one page per resource totaling to 4,368 pages. We merged them into one page per service (#1767, #1774).

	Before	After
Reference pages	4,368	406
Cold build	162 s	39 s
Output size	3.64GB	438MB
Website CI run (median)	8.0 min	4.1 min

Along with that, Website previews in PRs used to deploy a new Worker each time. Now they’re versions of a single stable preview Worker, so assets already uploaded from main are reused (#1267). Deploys on PRs are still only triggered when deploy-website tag is used, and doesn’t work on fork PRs yet.

Conditional Test runs, workflow concurrency and cancellation

We went through our runs to find where we were burning minutes (#1362).

New pushes in the PR didn’t cancel the already ongoing runs, so every commit was still running the full CI even though our agents had already pushed more commits to the branch. Now we cancel the old runs in the same group.
Cloudflare tooling tests always ran, regardless of if anything related to it happened in the PR. Now we have scoped it to only run when its packages change.
We were accidentally deleting our stable preview workers. Now that’s fixed, so wiping our test account doesn’t force a full asset upload.

Rewriting `pkg.alchemy.run`

@alchemy.run/pkg publishes every PR’s packages to an installable URL, like pkg.pr.new. We built our own version of this as soon as we hit pkg.pr.new’s limits, and we host it on Cloudflare with Alchemy. We recently rewrote it so now it supports everything:

Fork PRs can publish without secrets, because each publish is verified against the GitHub Actions run that built it (#1681).
Previews can publish only the packages a change affects (#1727).
Previews stay alive while their PR is open (#1511).

Thanks to Blacksmith

Huge shoutout to our friends at Blacksmith for sponsoring our CI runners. We are utilizing their fast Linux, macOS, and Windows runners. We found Github runners so slow that we were splitting our workloads. With blacksmith’s fast runners we just throw our tests across platforms, deploy our content-heavy website, and run checks without having to even think about it.

2.0.0-beta.78 - Git Hosting, Stripe & Worker Previews

Thu, 17 Sep 2026 09:00:00 GMT

beta.78 ships alchemy/Git, an embeddable, pluggable git server built from Effect Layers. Mount it inside any Effect HTTP API and pick where refs and bytes live — Durable Objects and R2 on Cloudflare, S3 and Lambda on AWS, or a store of your own. A new Stripe provider provisions Stripe resources and binds them to your Workers and Functions. Worker Previews give every branch its own URL and isolated Durable Objects. The GitHub provider gains ten resources, alchemy dev runs on half the memory, and a round of fixes to RDS, S3, and security groups repairs drift and restores defaults when props are removed.

Breaking changes

effect >=4.0.0-rc.115 is the new minimum peer (#1562, #1601). rc.113 renamed the Config and Flag constructors to PascalCase — see below.
SecurityGroup egress: [] now means no outbound traffic (#1623). It used to fall back to AWS’s allow-all default, the same as omitting egress. Omit the prop to keep the default. Rules that exist in AWS but not in your program are now removed on the next deploy (#1592, #1664) — SecurityGroupRule resources in the same stack are preserved.
RDS parameter groups reset undeclared overrides (#1589). An omitted parameters is {}: values edited in the console converge back to engine defaults.

Alchemist leaves the root barrel (#1614) so that importing alchemy no longer loads every cloud:

import * as Alchemy from "alchemy";
Alchemy.Alchemist
import * as Alchemist from "alchemy/Alchemist";

import { S3BucketEventSource } from "alchemy/Server";
import { S3BucketEventSource } from "alchemy/Server/S3BucketEventSource";

Prisma.Database branch props are no longer nullable (#1582) — Prisma’s API now attaches every database to a Branch. Omit both branchId and branchGitName to use the project default.
Test.make defaults to stage test_$USER (#1579), matching live_$USER / dev_$USER. Pass stage to keep test.

effect rc.115

alchemy now requires effect >=4.0.0-rc.115 (#1562, #1601):

bun add https://pkg.alchemy.run/alchemy/bea0366 effect@rc @effect/platform-bun@rc @effect/platform-node@rc

rc.113 renamed the Config and Flag constructors to PascalCase:

Config.string("HOST")
Config.String("HOST")
Config.mapOrFail(...)
Config.mapEffect(...)
Flag.boolean("yes")
Flag.Boolean("yes")
Flag.choice("backend", …)
Flag.Literals("backend", …)

rc.113 also replaced @effect/sql-pg’s pg dependency with a native wire client, which sent no SNI and rejected sslmode=prefer. Both broke Aurora DSQL, Neon, and local Hyperdrive; alchemy’s SQL.Postgres, Drizzle.Postgres, and postgresState now derive the TLS config from the URL (#1580, #1582), and rc.115 fixes the SNI half upstream (Effect-TS/effect#8174).

An embeddable, pluggable Git server

alchemy/Git is a pluggable, embeddable git server (#1187, #1621). It speaks smart HTTP to any git client, serves a typed REST plane with pull requests, and answers the GitHub REST v3 API so gh api and Octokit work against it unchanged. Nothing ships a Worker — every part is an Effect service with swappable Layers, assembled into a Worker you own:

import * as Git from "alchemy/Git";
import * as Http from "alchemy/Http";

export const GitObjects = Cloudflare.R2.Bucket("GitObjects");

const GitLive = Git.ApiLive.pipe(
  Layer.provide(Git.ApiHandlersLive),      // the engine's route handlers
  Layer.provide(Authentication.layer),     // yours: who may call what
  Layer.provide(Git.ReposDurableObject),   // refs, objects, pull requests
  Layer.provide(Git.RegistryDurableObject), // owner/name → repo
  Layer.provide(Git.HasherInline),         // push verification
  Layer.provide(Git.BlobStoreR2(GitObjects)), // packs, bundles, large pushes
);

export default Cloudflare.Worker(
  "Git",
  { main: import.meta.url, ...Git.GIT_WORKER_OPTIONS },
  Effect.gen(function* () {
    const fetch = yield* HttpRouter.toHttpEffect(
      GitLive.pipe(Layer.provide(Http.Platform)),
    );
    return { fetch };
  }),
);

Each line is one decision with its own implementations. Change a line and only that decision changes — here the bytes move to S3:

const GitObjects = Cloudflare.R2.Bucket("GitObjects");
const GitObjects = AWS.S3.Bucket("GitObjects");

const GitLive = Git.ApiLive.pipe(
  Layer.provide(Git.ApiHandlersLive),
  Layer.provide(Authentication.layer),
  Layer.provide(Git.ReposDurableObject),
  Layer.provide(Git.RegistryDurableObject),
  Layer.provide(Git.HasherInline),
  Layer.provide(Git.BlobStoreR2(GitObjects)),
  Layer.provide(Git.BlobStoreS3(GitObjects)),
);

Embedded by design

You build the HTTP server and mount alchemy/Git’s routes into it. Git.Api is an Effect HttpApi group and Git.Handlers supplies the default implementation of every route as a plain function. Add the group to your own API and put your own HttpApiMiddleware in front of it, and every request — git clone and git push, the REST API, and the GitHub-compatible API gh uses — goes through your authentication and your user management. The engine itself holds no users, no credentials, and no policy.

The middleware is native HttpApiMiddleware. Declare what it provides, add the Git groups to your API, and put it in front:

class Authentication extends HttpApiMiddleware.Service<
  Authentication,
  { provides: CurrentUser }
>()("app/Authentication", { error: Unauthorized }) {}

class AppApi extends HttpApi.make("app")
  .addHttpApi(Git.Api)   // repos, refs, objects, pulls, protocol, github
  .add(AppRoutes)        // your own routes beside them
  .middleware(Authentication) {}

Its implementation is an ordinary Layer — resolve a session cookie, an API key, or the password git sends over HTTP Basic, and provide CurrentUser to the endpoint. examples/cloudflare-git-service does this with Better Auth.

Because the handlers are yours to call, a route can be overridden with a few lines of application code. Here receivePack reuses the defaults for the read routes and wraps the push with a branch rule that reads the CurrentUser the middleware provided:

const ProtocolLive = HttpApiBuilder.group(AppApi, "protocol", (h) =>
  Effect.gen(function* () {
    const git = yield* Git.Engine;
    const defaults = yield* Git.Handlers;
    return h
      .handleRaw("infoRefs", defaults.protocol.infoRefs)
      .handleRaw("uploadPack", defaults.protocol.uploadPack)
      .handleRaw("receivePack", ({ params, request }) =>
        Effect.gen(function* () {
          const repo = yield* git.repositories.get(params);
          const push = yield* GitHttp.ReceivePack.decode(request);
          const user = yield* CurrentUser; // provided by Authentication

          if (push.updates.some((u) => u.ref === "refs/heads/main" && user.id !== repo.owner)) {
            return GitHttp.ReceivePack.reject(push, "only the owner moves main");
          }

          const prepared = yield* git.preparePush(repo, push.input);
          return GitHttp.ReceivePack.response(push, yield* git.commitPush(prepared));
        }),
      );
  }),
);

preparePush verifies the pack without moving refs; commitPush moves them atomically. The same host runs behind a shared secret, Better Auth, or anything else — the tutorial walks from one to the other, ending with the full version of this handler in Protect a branch.

Performance

We benchmarked it against GitHub with real git from the same client and edge: a 36 MiB, 15.6k-object repository, a fresh repository on each host.

Operation	`alchemy/Git`	GitHub
Full `git clone`	0.7 s best, 1.3 s typical	1.3 s best, 2.1 s typical
Clone throughput	80 MiB/s best, 33 MiB/s typical	28 MiB/s best, 17 MiB/s typical
Incremental fetch	0.4–0.6 s	0.3–0.5 s
Incremental push	0.2–0.4 s	1.2 s
44 MiB push, whole blobs	4.8–6.4 s	4.6 s
40 MiB push, delta-heavy	5.9–6.5 s	3.3 s

GitHub’s throughput is the pack size divided by its clone time; the incremental fetch is a git fetch with one new commit to pick up. Clones are fast because the work is done ahead of time. After every push the repository writes a ready-to-serve bundle to R2, and a git clone is the Worker streaming that file to the client. The Durable Object is not involved, so the number of concurrent clones a repository can serve is limited by R2 and Workers, not by one object: four clones at once reached 93 MiB/s aggregate. Everyday pushes, which move a few commits, are faster than GitHub; incremental fetches are about even. Large pushes are the one place GitHub is ahead. The largest real push so far is the alchemy monorepo, 44k objects in a 67 MiB pack, hosted on git.alchemy.run and cloned back byte-identical under git fsck --strict.

Where the hashing runs

Before a ref moves, every object in a push is inflated, SHA-1 hashed, and delta-resolved. For a kilobyte push that is nothing; for a 40 MiB push it is a lot of CPU, and Workers are a poor place for it. A Worker’s CPU is slow for exactly this kind of work — tight loops over bytes, inflate, and hashing run several times slower than on a laptop — and there is one thread to run it on: a service binding call executes on the caller’s thread, so fanning out to another Worker buys nothing. The first version hashed on the request thread and took 10–13 seconds for the 40 MiB push:

Layer.provide(Git.HasherInline)

Git.Hasher is the Layer where a chunk gets hashed, so the fix was a second implementation, not a change to the engine. HasherWorkerLoader bundles the hasher as a module inside your Worker and loads it into four fresh isolates per push, each with its own 128 MB and its own thread. Nothing new is deployed, nothing leaves Cloudflare, and the same push drops to 5.9–6.5 seconds:

import * as GitHasher from "alchemy/Git/Hasher";

const GitLive = Git.ApiLive.pipe(
  Layer.provide(Git.ApiHandlersLive),
  Layer.provide(Authentication.layer),
  Layer.provide(Git.ReposDurableObject),
  Layer.provide(Git.RegistryDurableObject),
  Layer.provide(Git.HasherInline),
  Layer.provide(GitHasher.HasherWorkerLoader()),
  Layer.provide(Git.BlobStoreR2(GitObjects)),
);

HasherLambda is the third implementation — one Lambda invocation per chunk, all at once, on a 3 GB function — for pushes wider than four chunks when an AWS account is already in the stack. If a hasher fails, the Worker hashes the chunk inline; a push never fails because its hasher did. Incremental pushes take 0.2–0.4 s on every one of them, so start with HasherInline and swap when large pushes start to matter.

Scaling and Hasher have the full numbers; the design notes in DESIGN.md record every step of the sweep.

It is a git remote you own, with an API, that you can build on — not a GitHub replacement. No issues, reviews, or Actions.

Docs: Git · Getting Started · Tutorial · Building blocks · Scaling.

Stripe

A new Stripe provider for managing Stripe with alchemy (#1298) — thanks Michael K! It comes with resources (Product, Price, Coupon, PromotionCode, PaymentLink, BillingPortalConfiguration, WebhookEndpoint, and Connect’s Account), bindings for calling Stripe from a Worker (CreateCustomer, CreateCheckoutSession, Retrieve*, …) that wire the API key into the Worker for you — each one registers the permission it needs, so there is no key to copy into env — and consumeEvents, an event source that provisions the webhook endpoint from the Worker’s URL and hands your handler a typed event:

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const product = yield* Stripe.Product("Pro", { name: "Pro" });
    const price = yield* Stripe.Price("ProMonthly", {
      product,
      currency: "usd",
      unitAmount: 2000,
      recurring: { interval: "month" },
    });
    const priceId = yield* price.id;

    const createCustomer = yield* Stripe.CreateCustomer();
    const createCheckout = yield* Stripe.CreateCheckoutSession();

    yield* Stripe.consumeEvents(
      "Events",
      { events: [Stripe.CheckoutSessionCompleted, Stripe.InvoicePaymentFailed] },
      Effect.fn(function* (event) {
        yield* Effect.log(event.type);
      }),
    );

    return {
      fetch: Effect.gen(function* () {
        const customer = yield* createCustomer({ email: "a@example.com" });
        const session = yield* createCheckout({
          mode: "subscription",
          customer: customer.id,
          line_items: [{ price: yield* priceId, quantity: 1 }],
          success_url: "https://example.com/welcome",
          cancel_url: "https://example.com/pricing",
        });
        return HttpServerResponse.redirect(session.url!);
      }).pipe(Effect.orDie),
    };
  }).pipe(
    Effect.provide([
      Stripe.CreateCustomerHttp,
      Stripe.CreateCheckoutSessionHttp,
      Stripe.ConsumeEventsLive,
    ]),
  ),
) {}

consumeEvents verifies signatures (a bad one is a 401) and creates the WebhookEndpoint for you; declare one directly only when you own the delivery URL.

Two runnable examples: examples/stripe-billing (Checkout, Billing Portal, and an entitlement record in KV kept current by webhooks) and examples/stripe-connect (Express accounts, hosted onboarding, and account.updated driving a D1 merchant table).

Docs: Stripe · Sell a subscription · Onboard merchants with Connect · React to Stripe events.

Worker Previews

preview is the sibling of version (#1563): a named copy of another Worker with its own URL, its own bindings, and isolated same-Worker Durable Objects. Production traffic is untouched.

const parent = yield* Cloudflare.Worker.ref("Api", { stage: "prod" });

const api = yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  preview: { of: parent },
});
// api.url → https://<stage>-<worker>.<account>.workers.dev

The Preview name defaults to the stack stage (pr-123). Destroying the Preview Worker deletes the Preview; the parent stays up. Enable domain: { name: "app.example.com", previews: true } on the parent and Previews serve at https://<preview-name>.app.example.com.

preview.of          // branch / PR — own URL, isolated DOs
version.parent      // canary of another stage
version.traffic     // gradual rollout of this Worker
version.traffic: 0  // upload without routing

Docs: Worker Previews.

GitHub: rulesets, protection, releases, and more

Ten new resources on the GitHub provider. BranchProtection (#1514) covers the classic protection API — thanks 99andytang! — and Agusti F. contributed the other nine: Ruleset, Label, Milestone, Issue, PullRequest, Release, Collaborator, TeamAccess, and WikiPage (#1565–#1578). Thanks both!

yield* GitHub.Ruleset("main-protection", {
  owner: "my-org",
  repository: "my-repo",
  name: "main protection",
  target: "branch",
  conditions: { include: ["refs/heads/main", "refs/heads/release/*"] },
  rules: {
    nonFastForward: true,
    deletion: true,
    requiredLinearHistory: true,
    pullRequest: {
      requiredApprovingReviewCount: 2,
      requireCodeOwnerReview: true,
      dismissStaleReviewsOnPush: true,
    },
  },
});

yield* GitHub.TeamAccess("platform", {
  owner: "my-org",
  repository: "my-repo",
  teamSlug: "platform",
  permission: "push",
});

Docs: GitHub.

`alchemy dev` runs lighter

The alchemy dev process tree drops from 3.6 GB to 1.9 GB on the Vite example under Node, and a cold import of alchemy/Cloudflare from 523 MB to 214 MB.

One sidecar, not one per provider group (#1613). A group is imported the first time a stack uses one of its types, so a Cloudflare-only stack never loads the AWS emulator.
Less engine in every process (#1614). ProviderLayer.dual stops building its default variant at registration, the CLI bins skip the alchemy/Cli barrel, and the Cloudflare provider no longer imports all 122 distilled services for one helper. Sidecar heap: 193 MB → 98 MB.
Transforms are cached on disk (#1615). The Oxc loader writes output to a per-user cache keyed by path, size, mtime, and tsconfig instead of re-transpiling the source graph (with inline source maps) in every Node process. ALCHEMY_TRANSFORM_CACHE=0 disables it.
The workerd proxy is a node:net byte pipe (#1612) instead of a second workerd per Worker. HTTP/1.1, streaming, and WebSockets pass through untouched; the Worker sees the real Host, so request.url is the public URL (#1573); a request during a broken build gets a 502 with the build error.

Two beta.77 crashes are fixed too: alchemy dev under Bun could not import any stack because the dev probe intercepted the root’s own node_modules (#1617, thanks Austin!), and the interactive CLI died with ReactSharedInternals.H.useMemo when a consumer’s install hoisted a different React — Sigil now bundles its own (#1636).

RDS, S3, and security group fixes

A run of provider fixes from Bjorn Pagen and Henning Pokriefke — thanks both! — closes gaps where RDS, S3, and EC2 security groups trusted state instead of the cloud: drift went unrepaired on unchanged deploys, and removing a prop left the old value in place instead of restoring the documented default.

Security groups apply rule deltas instead of revoke-and-recreate (#1592, #1664), and an inline-rule update no longer deletes SecurityGroupRule resources attached to the same group (#1624). egress has three distinct states (#1623):

// Omitted: AWS's default — allow all outbound IPv4.
AWS.EC2.SecurityGroup("DefaultEgress", { vpcId });

// Explicitly empty: no outbound traffic.
AWS.EC2.SecurityGroup("NoEgress", { vpcId, egress: [] });

// Non-empty: only what is listed.
AWS.EC2.SecurityGroup("HttpsEgress", {
  vpcId,
  egress: [{ ipProtocol: "tcp", fromPort: 443, toPort: 443, cidrIpv4: "0.0.0.0/0" }],
});

RDS DBInstance reconciles storage as one configuration — allocation, type, IOPS, throughput, and the autoscaling limit sent together when AWS requires it (#1593, #1594) — compares the observed endpoint port (#1595), and restores the engine-default parameter group and the VPC default security group when their associations are removed (#1596). DBParameterGroup converges to declared overrides and reads back settled values (#1589, #1590).

yield* AWS.RDS.DBInstance("Db", {
  engine: "postgres",
  dbInstanceClass: "db.t3.micro",
  masterUsername: "admin",
  manageMasterUserPassword: true,
  allocatedStorage: 20,       // a minimum — RDS cannot shrink storage
  maxAllocatedStorage: 100,   // remove it to disable autoscaling
});

S3 buckets and AWS.state() gain encryption.blockedEncryptionTypes: ["SSE-C"] (#1588), compare decoded KMS key values so matching keys skip PutBucketEncryption (#1587), propagate configuration read failures instead of reconciling over them (#1586), and check ownership with GetBucketLocation so configuration-only operators no longer need s3:ListBucket (#1585).

Docs: RDS · S3.

Also in this release

Preview packages at pkg.alchemy.run (#1516) — every PR, branch, and commit publishes installable packages from a Cloudflare Worker registry that verifies each publication against the GitHub Actions run that built it, so fork PRs publish with no secrets. Dependencies are content-addressed, so shared packages deduplicate across PRs.
```
pnpm install https://pkg.alchemy.run/alchemy/pr:1516
pnpm install https://pkg.alchemy.run/alchemy/branch:main
```
Typed named entrypoint bindings (#1415) — Cloudflare.WorkerEntrypoint<Api>(target, "Api") types env.API as Service<Api>, so env.API.greet("alice") typechecks. Thanks Michael K!
Railway sandboxes: domains, sizing, forks, checkpoints (#1661) — publicDomains, resources: { cpu, memoryGB }, and Railway.SandboxCheckpoint to snapshot a prepared box and restore it as a template. Railway reconcilers now select only the GraphQL fields they need (#1604), and MountVolume actually attaches the disk (#1584).
Prisma Compute serves static apps (#1208) — build: "auto" recognizes Vite SPA output and adds the Bun entrypoint Prisma requires; build: { type: "static", spa: true } serves a prebuilt directory. Thanks Aman Varshney! The Prisma provider also moves onto the distilled SDK (#1290, #1669) — thanks Will Madden!
Cloudflare Containers — a batch from Dan van der Merwe, thanks! memoryMib is forwarded (#1521), Dockerfile builds export straight to the registry with buildx build --push (#1524), identical images publish once per deploy (#1525), a cached identity that no longer matches Cloudflare plans a visible replacement instead of erroring (#1523), interrupted creates recover by generated name (#1526), and an unresolved Worker namespace no longer detaches the container’s DO (#1150). The dev egress interceptor pulls host-native, fixing containers on Apple Silicon (#1459) — thanks Erik Müller!
R2 put forwards options on the stream path (#1602) — a declared sha256/md5 on an Effect Stream body is now verified by R2 instead of silently dropped.
Crons fire in Website.Vite dev workers (#1641). Thanks zawaki!
alchemy/Cloudflare/Bridge (#1643) — the Worker bridge generated wrappers import is a runtime-only entry, so deploy tooling stays out of the bundle. Thanks Alex!
EC2 instances with a fixed private IP replace delete-first (#1667) — the successor can’t take the address while the predecessor holds it. Thanks dawson!
AWS Organizations rewrite missing ownership tags (#1637) instead of reporting them restored. Thanks Henning Pokriefke!
Log group ARNs from state are normalized before tagging (#1575) — a :* suffix persisted by an old adoption no longer fails every converge with Invalid resourceArn. Thanks Evan Spaeder!
ECR images skip updates when only the context directory moves (#1591).
Destroy converges after drifted state — SNS.Subscription and DynamoDB.Table tolerate an already-deleted parent (#1576), and ECS.Service deletes past a draining service (#1580). Hetzner servers and their deploy keys recover after an interrupted create (#1662).
HTTP state-store errors carry no payloads (#1522) — a failed write reports a failure kind and status, never the request or response body. Thanks Dan van der Merwe!
CLI fixes — the published alchemy dev resolves its sidecar through package exports (#1678), colors follow the terminal’s detected profile instead of forcing truecolor (#1679), and the exec bundle keeps its .js extension (#1625).
Smaller dependency closure — jszip → fflate (#1608), fast-glob → tinyglobby (#1609), and Foldkit ^0.160.0 for effect rc.115 (#1618).
Core docs read as one narrative (#1652) — each concept has one owning page; /infrastructure-as-effects redirects to What is Alchemy.

Where to go next

2.0.0-beta.77 - Profiles, CLI & Workers Tracing

Tue, 08 Sep 2026 09:00:00 GMT

beta.77 redesigns the CLI. alchemy login becomes alchemy profile, a dashboard for every connected account whose every action is also a non-interactive subcommand; profiles are stored as a folder per profile with a file per provider instead of a central profiles.json; and alchemy dev gets a plan/output widget you can flip with ←/→. Outside the CLI, Cloudflare.Telemetry() sends Effect spans to Workers Observability with no OTLP setup, Workflows take cron schedules, and AWS gains provisioned ElastiCache.

Here is the new CLI on a fresh machine, start to finish:

alchemy profile → alchemy dev → alchemy deploy → alchemy drift → alchemy destroy. The same walkthrough, frame by frame, is below.

Breaking changes

alchemy deploy defaults to live_$USER (#1421) — plan, destroy, logs, and drift follow; alchemy dev keeps dev_$USER. Pass --stage dev_sam to keep deploying to an old target. The stage env var is now ALCHEMY_STAGE, not STAGE (#1433).

Commands moved (#1234, #1235). The old names print a migration hint instead of running:

Old	New
`alchemy login`	`alchemy profile`
`alchemy login --configure`	`alchemy profile edit`
`alchemy profile clear`	`alchemy profile delete`
`alchemy tail`	`alchemy logs --follow`
`alchemy sync`	`alchemy drift --repair`
`alchemy destroy --dry-run`	`alchemy plan --destroy`
`alchemy aws` / `cloudflare`	`alchemy provider aws` / `cloudflare`

The AWS local auth method is removed (#1480) — alchemy dev wires the local emulator itself.
distilled operations are verbNoun (#1517) — railway.serviceCreate is now railway.createService. Only affects code that calls a distilled client directly.

1. Connect an account

alchemy login is now alchemy profile (#1234, #1235, #1547). On a fresh machine it opens on an empty default profile:

e lists every provider. Space queues a change on the focused row — here Cloudflare goes to add — and Enter runs the queue:

Each provider asks only what it needs. Cloudflare offers OAuth or a token:

OAuth opens the browser; you approve the grant there:

Back on the dashboard the provider is a row with its live details:

Profiles are tabs, ←/→ switches between them, and every profile holds one connection per provider — a work profile with a Cloudflare token next to a default with OAuth + AWS SSO:

Every key on the dashboard is also a subcommand, and the subcommands never prompt:

alchemy profile create work
alchemy profile edit --profile work --add cloudflare     # runs the OAuth flow
alchemy profile refresh --provider cloudflare
alchemy profile rename work staging
alchemy profile delete staging --yes

For agents and CI, token-shaped methods are configured entirely from flags. --set takes a literal, an environment variable, or stdin, so secrets never touch shell history:

alchemy profile edit --add cloudflare --method stored \
  --set apiToken=env:CLOUDFLARE_API_TOKEN \
  --set accountId=0123456789abcdef0123456789abcdef

op read op://vault/neon/key | alchemy profile edit --add neon --method stored --set apiKey=-

Under the hood, the central profiles.json and the separate credentials/ tree are gone. A profile is a directory and each provider is one file holding its method, config, and credentials together. Existing installs migrate on first run, with the old layout backed up to ~/.alchemy/.profiles-v0-<timestamp>/ (#1429):

~/.alchemy/profiles/
├─ default/
│  ├─ cloudflare.json   # method: oauth, accountId, tokens, scopes
│  └─ aws.json          # method: sso, ssoProfile
└─ work/
   └─ cloudflare.json   # method: stored, apiToken, accountId

Only profile commands log in. deploy, plan, and dev never open a wizard — a missing credential fails with the exact alchemy profile edit --add … to run. Explicit provider environment variables (CLOUDFLARE_API_TOKEN, AWS_ACCESS_KEY_ID, …) take precedence over the profile, per provider, and the CLI logs which ones it used (#1520).

Docs: profile · Profiles · CI.

2. `alchemy dev`

The stack in the video is a Worker bound to a KV namespace and an R2 bucket:

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const visits = yield* Cloudflare.KV.ReadWriteNamespace(Visits);
    const uploads = yield* Cloudflare.R2.ReadWriteBucket(Uploads);
    return { fetch: /* … */ };
  }).pipe(
    Effect.provide([
      Cloudflare.KV.ReadWriteNamespaceBinding,
      Cloudflare.R2.ReadWriteBucketBinding,
    ]),
  ),
) {}

alchemy dev emulates all three locally. Logs scroll above; the widget at the bottom shows the stack’s output:

←/→ flips the widget to the last applied plan — the same component deploy, drift, and destroy render (#1458, #1492). ↑/↓ scrolls it, p hides it:

Save a file and only the affected resource restarts. Reloads follow the import graph from your entrypoint — sibling infra/ and src/ trees included — and only fire when a file’s contents actually change (#1461, #1477):

3. `alchemy deploy`

deploy shows the plan first. Bindings appear under the resource they attach to, and the prompt defaults to go:

Provider logs stream while it runs; the plan ticks over as each resource lands and the stack’s outputs print at the end:

$ curl -s https://demo-api-live-samgoodwin-sthgco4pjlba35wc.testing-2b2.workers.dev
{"message":"Hello from Alchemy","visits":1}

4. `alchemy drift`

Someone renames the KV namespace in the Cloudflare dashboard. alchemy drift re-reads the cloud and diffs it against what was deployed — the changed attribute renders inline, and Repair puts it back:

alchemy drift --repair does the same without the prompt.

5. `alchemy destroy`

Destructive prompts default to Cancel:

Without a TTY

In CI, a pipe, or a coding agent, the same commands print plain append-only lines instead of the TUI — or force it with ALCHEMY_PLAIN=1 / --no-input (#1423, #1426). Same deploy as above, plain:

Exit codes are 0 done / 1 failed or declined / 130 cancelled, and every run writes a debug log under ~/.alchemy/logs — the first thing to attach to a bug report.

Docs: CLI · dev · deploy · drift.

`Cloudflare.Telemetry()`

Effect spans from a Worker now land in Workers Observability (#1444). Provide the Layer on the Worker and your Effect.withSpan frames show up in the Cloudflare dashboard, nested under the platform’s own spans:

export default Cloudflare.Worker(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    return {
      fetch: Effect.gen(function* () {
        const user = yield* kv.get("user:1").pipe(Effect.withSpan("load.user"));
        return yield* respond(user);
      }).pipe(Effect.withSpan("handle")),
    };
  }).pipe(Effect.provide(Cloudflare.Telemetry())),
);

http.server GET
└─ handle
   ├─ load.user
   │  └─ kv_get
   └─ respond

Cloudflare owns sampling and export, so there is no OTLP endpoint and nothing to flush. It composes with Axiom.Telemetry for the same waterfall in both. The Worker’s compatibility date must be 2026-07-28 or later.

Docs: Native Workers tracing.

Workflows: cron schedules

Cloudflare Workflows take wrangler-compatible schedules, so a cron expression creates instances natively — no Cron Trigger Worker calling workflow.create() (#1491):

export default class Hourly extends Cloudflare.Workflow<Hourly>()(
  "Hourly",
  { schedules: ["0 * * * *"] },
  Effect.gen(function* () {
    return Effect.fn(function* () {
      const event = yield* Cloudflare.Workflows.WorkflowEvent;
      return event.schedule?.cron;
    });
  }),
) {}

Provisioned ElastiCache

AWS.ElastiCache adds SubnetGroup, ReplicationGroup (Valkey and Redis OSS) and CacheCluster (Memcached) alongside the serverless cache, with Connect* bindings that publish the endpoint to a Lambda and attach it to the cache’s VPC (#1422). Thanks Henning Pokriefke!

const cache = yield* AWS.ElastiCache.ReplicationGroup("Cache", {
  engine: "valkey",
  nodeType: "cache.t4g.micro",
  subnetGroupName: subnetGroup.subnetGroupName,
  securityGroupIds: [sg.groupId],
  replicasPerNodeGroup: 1,
  automaticFailoverEnabled: true,
});

// inside the Lambda: endpoint env + VPC attachment
const conn = yield* AWS.ElastiCache.ConnectReplicationGroup(cache, {
  subnetIds: vpc.privateSubnetIds,
  securityGroupIds: [sg.groupId],
});

Railway: private services, pre-deploy, local contexts

Three additions to Railway.Service, all from Dallen Pyrah — thanks! (#1439, #1438, #1440)

const worker = yield* Railway.Service("Worker", {
  project,
  context: "./worker",                    // build from a local directory
  preDeploy: { command: "bun migrate" },  // runs between build and start
  publicDomain: false,                    // {name}.railway.internal only
});

Also in this release

Fly health checks (#1463) — services[].checks on Fly.Machine and Fly.Service. Thanks Adam Svystun! Fly Machines requests also stop hitting /v1/v1/… (#1543).
Durable Objects: webSocketError and caller context (#1497, #1498) — blockConcurrencyWhile / storage.transaction run with the calling fiber’s context. Thanks Alex! state.abort(reason, { retryAlarm: false }) stops an interrupted alarm from retrying (#1374).
Cloudflare.Worker.ref typechecks (#1434). Thanks pollux!
Asset uploads run three buckets at a time (#1445), matching wrangler; workerd bumped to 20260901.1 (#1442). Thanks Rahul Mishra!
Workflow steps with retries but no timeout no longer crash (#1416). Thanks Lord Coughmann!
Ctrl+C twice force-quits a slow shutdown (#1427).
_headers / _redirects no longer crash local dev (#1418). Thanks Michael!
Worker Loader get() returns a usable stub (#1488) and RpcWorker keeps its logical ID (#1487).
nuke shows progress again (#1532), and provider cloudflare bootstrap honors --profile (#1538).
PR preview packages live as long as the PR (#1511). Thanks Michael K!
Docs rewritten as a narrative (#1470, #1472) — Getting started, What is Alchemy, and the Workers hub read top to bottom.

Where to go next

2.0.0-beta.75 - Railway, Fly, Hetzner & Websites

Tue, 25 Aug 2026 09:00:00 GMT

beta.75 ships Railway, Fly.io, and Hetzner — each with an Effect-native Service platform. The same website call now deploys to all three plus Cloudflare and AWS: Vite, Astro, Next.js, Nuxt, SvelteKit, Waku, Octane, Foldkit, and StaticSite, with one props vocabulary. alchemy dev runs your AWS Lambda, S3, DynamoDB, SQS, ECS, EC2, and website stack on your machine — no account, no credentials, hot reload. SQL migrations have one format, Workers can sit behind Access and receive inbound email, and removal policies persist.

This post covers beta.72 through beta.75.

Breaking changes

effect >=4.0.0-rc.112 is the new minimum peer (#1245, #1318) — effect has moved from beta to release candidates.
@alchemy.run/cloudflare-frameworks is now @alchemy.run/frontend-frameworks (#1140, #1154) — the framework integrations serve every cloud now. Update your devDependency.
Website props are one vocabulary (#1353, #1351, #1158) — AWS’s server: bag is gone, Cloudflare’s mirrored framework fields move into astro: / waku: / assets.notFoundHandling, StaticSite.environment is build.env. Lambda’s url is functionUrl; Website.Server’s port is dev: { port }. See below.
SQL migrations have one prop and one format (#1226). migrationsDir/migrationsTable are replaced by a single migrations prop, and history lives in __alchemy_migrations. Databases previously migrated with drizzle-kit, Prisma, or wrangler are converted automatically on the next deploy — see below.
Worker.workerId is now the immutable Worker ID (#1228) — the hex script tag Access destinations key on, not a duplicate of workerName. Old state heals itself on the next deploy.
Destroying a non-empty R2 bucket now fails instead of silently deleting every object (#1253) — opt back in with forceDestroy: true. And a removed RemovalPolicy.retain() now actually takes effect — see below.
DynamoDB secondary indexes take typed keys (#1216) — partitionKey/sortKey segments instead of the raw wire KeySchema list. Existing state upgrades without a replacement.

alchemy depends on effect@rc

effect 4.0 has moved from beta to release candidates, and alchemy now depends on effect’s rc dist-tag (#1245, #1318). The minimum peer is >=4.0.0-rc.112; install effect and the platform packages from the rc tag:

bun add https://pkg.alchemy.run/alchemy/bea0366 effect@rc @effect/platform-bun@rc @effect/platform-node@rc

Websites on five clouds

The Website family now deploys to Cloudflare, AWS, Hetzner, Railway, and Fly (#1140, #1353, #1351). Your astro.config.* loads natively. Stage-varying values go in the astro: bag. Change the namespace to change the cloud:

const site = yield* Cloudflare.Website.Astro("Blog", {
  rootDir: "./apps/blog",
  env: { API_BASE: api.url },
  astro: { site: `https://${stage}.example.com`, output: "server" },
  domain: "blog.example.com",
});

const site = yield* Cloudflare.Website.Astro("Blog", {
const site = yield* Fly.Website.Astro("Blog", {
  rootDir: "./apps/blog",
  env: { API_BASE: api.url },
  astro: { site: `https://${stage}.example.com`, output: "server" },
  domain: "blog.example.com",
});

AWS.Website.Astro and Railway.Website.Astro take the same props. Hetzner adds the DNS zone when you set domain:

const site = yield* Hetzner.Website.Astro("Blog", {
  rootDir: "./apps/blog",
  env: { API_BASE: api.url },
  astro: { site: `https://${stage}.example.com`, output: "server" },
  domain: "blog.example.com",
  zone,
});

alchemy dev is the framework’s own server on every cloud — native HMR, no cloud resources. A Vite SPA is the same shape, assets-only on AWS (no Lambda):

const site = yield* AWS.Website.Vite("Web", {
  domain: "app.example.com",
});

Next.js is the same call. Cloudflare and AWS run OpenNext; Fly, Hetzner, and Railway run next build and a Node server:

const site = yield* Fly.Website.Nextjs("Site", {
  rootDir: "./apps/web",
  env: { DATABASE_URL: db.connectionUri },
  domain: "app.example.com",
});

AWS’s old server: bag is now flat props:

const site = yield* AWS.Website.Astro("Blog", {
  server: {
    memorySize: 1024,
    environment: { API_URL: api.url },
  },
  memorySize: 1024,
  env: { API_URL: api.url },
  astro: { site: `https://${stage}.example.com` },
  domain: "blog.example.com",
});

Vite, Foldkit, Astro, Nextjs, Nuxt, SvelteKit, Waku, Octane, and StaticSite on all five. Cloudflare.Website.Vocs also lands on Fly, Hetzner, and Railway. React Router, SolidStart, and TanStack Start stay on Cloudflare (Website.Vite) and AWS (dedicated composites). Each cloud has a matching example (examples/{cloudflare,aws,fly,hetzner,railway}-website-{framework}).

Docs: Cloudflare · AWS · Fly · Hetzner · Railway.

Railway

A new Railway provider (#1295): Project, Service, Function, Postgres, MySQL, Mongo, Redis, Bucket, Volume, Variable, CustomDomain, TcpProxy, and PrivateNetwork. Auth is RAILWAY_API_TOKEN or alchemy login.

A Project is the parent. Railway.Service is the Function/Worker analog: an Effect program in a container. Alchemy bundles main, builds a Docker image, and pushes it to a registry Railway can pull (GHCR or Docker Hub — Railway has no private registry of its own):

const Site = Railway.Project("Site");

const Db = Railway.Postgres("Db", { project: Site });

export default class Api extends Railway.Service<Api>()(
  "Api",
  {
    project: Site,
    main: import.meta.url,
    registry: "ghcr.io/acme",
    build: { install: ["pg"] },
  },
  Effect.gen(function* () {
    const conn = yield* Railway.ConnectPostgres(Db);
    const db = yield* Drizzle.Postgres(conn.connectionString);
    return {
      fetch: Effect.gen(function* () {
        const rows = yield* db.select().from(users);
        return HttpServerResponse.json({ rows });
      }),
    };
  }).pipe(Effect.provide(Railway.ConnectPostgresHttp)),
) {}

api.url is https://{name}.up.railway.app. Redis and S3-style Buckets bind the same way:

const Cache = Railway.Redis("Cache", { project: Site });
const Data = Railway.Bucket("Data", { project: Site });

export default class Api extends Railway.Service<Api>()(
  "Api",
  { project: Site, main: import.meta.url, registry: "ghcr.io/acme" },
  Effect.gen(function* () {
    const cache = yield* Railway.ReadWriteRedis(Cache);
    const putObject = yield* Railway.PutObject(Data);
    return {
      fetch: Effect.gen(function* () {
        yield* putObject({ Key: "hello.txt", Body: "hello" });
        yield* cache.set("last-write", "hello.txt");
        return HttpServerResponse.text("ok");
      }),
    };
  }).pipe(Effect.provide([Railway.ReadWriteRedisHttp, Railway.PutObjectHttp])),
) {}

Pass image for a public tag (hashicorp/http-echo) or repo for GitHub; healthcheck / cronSchedule match Railway IaC.

Railway.Function is the canvas runtime: a single TypeScript file on Bun. No Docker. No registry. Cap is 96KB. Distinct from Service({ main, registry }):

export default class Ping extends Railway.Function<Ping>()(
  "Ping",
  { project: Site, main: import.meta.url },
  Effect.gen(function* () {
    return { fetch: Effect.succeed(HttpServerResponse.text("ok")) };
  }),
) {}

Docs: Railway · Tutorial.

Hetzner

A new Hetzner Cloud provider (#1258): Server, SshKey, Volume, VolumeAttachment, Network, Firewall, PlacementGroup, PrimaryIp, FloatingIp, FloatingIpAssignment, Certificate, LoadBalancer, Image, and DNS Zone + RecordSet. Auth is a single HCLOUD_TOKEN (or alchemy login).

export const Key = Hetzner.SshKey("laptop", {
  publicKey: "ssh-ed25519 AAAA… you@laptop",
});

export const Box = Hetzner.Server("box", {
  serverType: "cpx12",
  image: "ubuntu-24.04",
  location: "nbg1",
  sshKeys: [Key],
});

Hetzner.Service is the Function/Worker analog for a server you own. Write an Effect program with a fetch handler; deploying bundles it, ships it to the server, and runs it under systemd with a readiness gate:

export const Data = Hetzner.Volume("data", {
  size: 40,
  format: "ext4",
  location: "nbg1",
  server: Box,
});

export default class Api extends Hetzner.Service<Api>()(
  "api",
  { server: Box, main: import.meta.url, port: 3000 },
  Effect.gen(function* () {
    const disk = yield* Hetzner.MountVolume(Data, { path: "/var/lib/api" });
    return {
      fetch: Effect.gen(function* () {
        const fs = yield* FileSystem.FileSystem;
        const body = yield* fs.readFileString(`${disk.path}/hello.txt`);
        return yield* HttpServerResponse.text(body);
      }),
    };
  }).pipe(Effect.provide(Hetzner.MountVolumeLive)),
) {}

Bindings follow the same capability model as AWS and Cloudflare: MountVolume formats, attaches, and mounts a Volume into the service, Hetzner.Ssh(Box) is a typed exec/scp client for a Server, and the DNS zone splits into least-privilege ReadDns / WriteDns / ReadWriteDns clients. Networking is a private Network, Firewall rules, and a LoadBalancer with managed TLS certificates:

export const Lb = Hetzner.LoadBalancer("lb", {
  location: "nbg1",
  loadBalancerType: "lb11",
  targets: [{ type: "server", server: Box, usePrivateIp: true }],
  services: [
    {
      protocol: "https",
      listenPort: 443,
      destinationPort: 3000,
      certificates: [Managed],
      http: { redirectHttp: true },
    },
  ],
});

Hetzner gets its own docs tab (#1260): a setup guide, a four-part tutorial (server → service → volume → network + load balancer), and guides for servers, services, volumes, networking, and DNS.

Docs: Hetzner · Tutorial.

Fly.io

A new Fly.io provider (#1261): App, Machine, Service, Sprite, Volume + VolumeSnapshot, IpAssignment, Certificate, Secret, SecretKey, and managed data — Postgres, Upstash Redis, and Tigris object storage. Auth is a single FLY_API_TOKEN.

Fly.Service is the Function/Worker analog: an always-on Effect program in a Fly Machine. Alchemy bundles main, builds a Docker image, pushes it, and Fly’s Anycast proxy load-balances across count replicas:

const Site = Fly.App("Site");

const Db = Fly.Postgres("Db", {
  region: "iad",
  migrations: schema, // Drizzle.Schema, a directory, or { dir, table }
});

export default class Api extends Fly.Service<Api>()(
  "Api",
  { app: Site, main: import.meta.url, region: "iad", count: 3, port: 3000 },
  Effect.gen(function* () {
    const conn = yield* Fly.ConnectPostgres(Db);
    const db = yield* Drizzle.Postgres(conn.connectionString);
    return {
      fetch: Effect.gen(function* () {
        const rows = yield* db.select().from(users);
        return HttpServerResponse.json({ rows });
      }),
    };
  }).pipe(Effect.provide(Fly.ConnectPostgresHttp)),
) {}

Upstash Redis and Tigris object storage bind the same way — ReadRedis / WriteRedis / ReadWriteRedis on a Fly.Redis, and S3-style PutObject/GetObject on a Fly.Bucket:

const Cache = Fly.Redis("Cache"); // Upstash Redis
const Data = Fly.Bucket("Data"); // Tigris object storage

export default class Api extends Fly.Service<Api>()(
  "Api",
  { app: Site, main: import.meta.url, port: 3000 },
  Effect.gen(function* () {
    const cache = yield* Fly.ReadWriteRedis(Cache);
    const putObject = yield* Fly.PutObject(Data);
    return {
      fetch: Effect.gen(function* () {
        yield* putObject({ Key: "hello.txt", Body: "hello" });
        yield* cache.set("last-write", "hello.txt");
        return HttpServerResponse.text("ok");
      }),
    };
  }).pipe(Effect.provide([Fly.ReadWriteRedisHttp, Fly.PutObjectHttp])),
) {}

The rest of the surface follows the same capability model: GetSecret/WriteSecret on app secrets, Encrypt/Decrypt/Sign/Verify on a SecretKey, and MountVolume for disks. Already have an image? Fly.Machine runs it as one VM per resource — yield another to add capacity.

Fly.Sprite deploys an Effect program onto a Fly Sprite — a persistent Linux computer built for AI-agent workloads. It wakes on demand, hibernates when idle, and keeps its filesystem between wakes. No parent App, no Docker image: alchemy bundles main and writes it straight onto the Sprite:

export default class Box extends Fly.Sprite<Box>()(
  "Box",
  { main: import.meta.url },
  Effect.gen(function* () {
    return { fetch: Effect.succeed(HttpServerResponse.text("hello")) };
  }),
) {}

Docs: Fly.io · Tutorial.

AWS local dev

alchemy dev now runs your AWS stack on your machine (#1154). No account, no credentials:

bun alchemy dev

Same program as production. A Function that writes to a bucket and a queue:

export default class Api extends AWS.Lambda.Function<Api>()(
  "Api",
  { main: import.meta.url, functionUrl: true },
  Effect.gen(function* () {
    const files = yield* AWS.S3.Bucket("Files");
    const jobs = yield* AWS.SQS.Queue("Jobs");

    const putObject = yield* AWS.S3.PutObject(files);
    const sendMessage = yield* AWS.SQS.SendMessage(jobs);

    return {
      fetch: Effect.gen(function* () {
        yield* putObject({ Key: "hello.txt", Body: "hello" });
        yield* sendMessage({ MessageBody: "process hello.txt" });
        return yield* HttpServerResponse.text("ok");
      }).pipe(Effect.orDie),
    };
  }).pipe(
    Effect.provide([AWS.S3.PutObjectHttp, AWS.SQS.SendMessageHttp]),
  ),
) {}

hits local endpoints:

Api.functionUrl  http://b71ff5c0….lambda-url.us-east-1.localhost:4566/
Jobs.queueUrl    http://localhost:4566/000000000000/jobs-dev-x7k2
Files.bucketName files-dev-x7k2

Save the file and the Function serves the new code in ~100–500ms. putObject lands in the local bucket; queue consumers fire; websites run their own dev servers.

Opt a resource onto the real cloud with Alchemy.remote():

const secret = yield* AWS.SecretsManager.Secret("ProdSecret", { ... })
  .pipe(Alchemy.remote());

A remote resource is live end to end: its binding clients route to the real cloud too, not just its lifecycle (#1406). Switching local ↔ live plans a replacement, so dev state never silently becomes cloud state.

Docs: AWS local development.

Local ECS and MicroVMs

alchemy dev runs ECS tasks and Lambda MicroVMs the same way (#1185, #1335) — same program, two runtimes:

export default class Web extends AWS.ECS.Task<Web>()(
  "Web",
  { main: import.meta.url, port: 8080 },
  Effect.gen(function* () {
    return {
      fetch: Effect.succeed(HttpServerResponse.text("hello")),
    };
  }),
) {}

export default class Box extends AWS.Lambda.MicrovmImage<Box>()(
  "Box",
  { main: import.meta.url },
  Effect.gen(function* () {
    return {
      fetch: Effect.succeed(HttpServerResponse.text("hello")),
    };
  }),
) {}

Save a file and both reload. EC2 instances that host an Effect program do too.

Docs: AWS local development.

One migration format for SQL databases

Alchemy’s migration bookkeeping was an invented table shape incompatible with what drizzle-kit, Prisma, and wrangler actually maintain. There is now exactly one format, owned by Alchemy (#1226): __alchemy_migrations, with one prop on every SQL database resource (D1, Neon, PlanetScale):

const db = yield* Cloudflare.D1.Database("app-db", {
  migrations: "./migrations", // or { dir, table }
});

Drizzle.Schema plugs into the same prop. It diffs your TypeScript schema against the checked-in snapshot and generates SQL migrations on drift, and passing the resource itself orders generation before application in the same deploy:

const schema = yield* Drizzle.Schema("AppSchema", {
  schema: "./src/schema.ts",
  dialect: "sqlite",
});

const db = yield* Cloudflare.D1.Database("app-db", {
  migrations: schema,
});

A database previously migrated with drizzle-kit, Prisma, or wrangler is adopted on first deploy by a one-way conversion: the old tool’s applied history is copied into Alchemy’s table once, validated against your local migration files, and the old table is left frozen — never written, never dropped. Nothing replays.

History validation is now strict — a recorded migration with no matching local file fails the deploy instead of passing silently. If you squashed and deleted old migration files, restore them before upgrading.

Docs: SQL.

Protect Workers with Access

Support for Workers protected by Access (#1228): declare policies inline on the Worker and alchemy manages the dedicated Access application for you —

export default class Api extends Cloudflare.Worker<Api>()("Api", {
  main: import.meta.url,
  access: {
    policies: [
      { decision: "allow", include: [{ emailDomain: "example.com" }] },
    ],
  },
}, /* ... */) {}

— or share one Cloudflare.Access.Application across several Workers (access: App), or protect every current and future Worker in the account with the AllWorkers destination. Enrollment goes through the binding contract, so removing the prop (or the Worker) un-enrolls it on the next reconcile.

At runtime, Cloudflare.Access.Context reads the authenticated identity, and dev: { access: { identity } } stubs a logged-in user under alchemy dev so you can test the gated paths locally:

fetch: Effect.gen(function* () {
  const access = yield* Cloudflare.Access.Context;
  const identity = yield* access.getIdentity(); // email, groups, idp…
  return yield* HttpServerResponse.json({ email: identity?.email });
}),

Docs: Protect a Worker with Access.

Inbound email to Workers

Workers can now receive email (#401). Cloudflare.email({ zone }).subscribe(handler) registers the email handler and provisions the zone’s email routing rules for you:

export default Cloudflare.Worker(
  "Inbox",
  { main: import.meta.url },
  Effect.gen(function* () {
    yield* Cloudflare.email({ zone: "example.com" }).subscribe((message) =>
      message.forward("ops@example.com"),
    );
    return {};
  }).pipe(Effect.provide(Cloudflare.EmailEventSourceLive)),
);

Docs: Email Workers.

Removal policies persist

RemovalPolicy.retain() added to an already-deployed resource never reached state — the policy is a decoration, not a prop, so the noop apply path skipped it, and a later rename or removal orphan-deleted the resource anyway. beta.75 persists the policy on the noop path (#1253) and prints a note whenever a deploy flips one.

Two behavior changes come with it, both protective. Destroying a non-empty R2 bucket now fails with BucketNotEmpty instead of silently emptying it first — the old behavior deleted 60k objects in the incident that motivated the fix. Opt disposable buckets back in explicitly:

const cache = yield* Cloudflare.R2.Bucket("Cache", { forceDestroy: true });

And because the policy now actually persists, a retain() you removed from the code takes effect: the next removal deletes the resource for real. If anything depends on a retain that’s no longer declared, put it back before deploying.

Docs: Resource lifecycle.

Lambda Docker Functions

AWS.Lambda.Function deploys a container image (#1077). Build from a Dockerfile into a managed ECR repo, or point image.uri at an existing tag or digest. Zip XOR image at the type level — mixing main with image is a compile error. Thanks Simon Westerlund!

const api = yield* AWS.Lambda.Function("ContainerApi", {
  image: { context: "./lambda", dockerfile: "Dockerfile" },
  architecture: "arm64",
  functionUrl: true,
});

Also in this release

Cloudflare.Website.Vocs (#1278) — first-class Vocs docs sites, also on Fly, Hetzner, and Railway.
Isolated installs bundle (#1324) — generated entries are shims over real alchemy/Runtime/Bootstrap/* modules, so bun --linker=isolated and pnpm no longer leave Effect programs crashing at boot with Cannot find module.
Axiom dataset edge deployments (#1361) — edgeDeployment on Axiom.Dataset; OTLP endpoints derive from Axiom’s regional URL. Thanks Aman Varshney!
Cognito email OTP, CustomEmailSender, and KMS (#1323) — on UserPool.
PlanetScale Metal SKUs (#1319) — on PostgresClusterSize.
r2.dev managed domain (#1329) — enable it on Cloudflare.R2.Bucket.
nuke --local clears the emulator (#1287) — alchemy unsafe nuke --local enumerates and deletes through each provider’s local implementation (the floci-emulated account, the Cloudflare local runtime), so wiping local state is one command with no cloud credentials in reach.
Hetzner init scripts compose with the bootstrap (#1289) — Hetzner.Server.userData merges into a multipart cloud-init document alongside alchemy’s bootstrap instead of replacing it, and changing it plans a replacement (cloud-init only runs on first boot).
Prisma: object storage, locked Postgres state, and deploy triggers (#1061) — Prisma.Bucket + BucketAccessKey resources with ReadBucket/WriteBucket/ReadWriteBucket bindings, a State/PostgresState backend with per-stack advisory locks, and Deployment.triggers to force a redeploy when an opaque key/value (e.g. a rotated secret) changes. Thanks Will Madden!
Structured DNS record data (#1257) — Cloudflare DNS records accept typed component objects for SVCB, HTTPS, SRV, CAA, and friends via the same content prop, with the shape discriminated by type. Thanks Arya Saatvik! Adoption also disambiguates records sharing (name, type) by content/priority instead of clobbering the first match (#1264).
Worker versions carry static assets (#1266) — a preview version can ship its own assets without touching the parent deployment. Thanks Rahul Mishra, who also migrated the workspace to pnpm (#1214), bumped effect to rc.110 then rc.111 (#1245, #1318), made process cleanup explicit and scoped (#1175), and improved platform runtime detection (#1197)!
Cloudflare Containers reach host services in dev (#1344, #1335, #1366) — loopback env URLs rewrite to the docker host, container images hot-reload on context/Dockerfile/prop changes, and Linux dev containers reach loopback host databases through a unix-socket tunnel instead of the (often firewalled) bridge IP. A failed docker build now fails the dev deploy with docker’s real error — and a buildx hint when --load is the problem — instead of looping on “Container exited while waiting for port” (#1377).
Docker.Container fixes (#1398) — ports: [{ external: 0 }] reports the actually-assigned host port, extraHosts forwards as --add-host, and reconciliation only disconnects networks alchemy itself attached instead of tearing off Docker’s default bridge.
Nested Worker env plans converge (#1273) — a Worker bound to an already-yielded Worker no longer plans update forever on identical deploys. Thanks Odysseas Papadimas!
alchemy dev survives a broken save (#1259) — a mid-edit save whose module evaluation throws now logs and waits for the next change instead of killing the watch session.
Env-bound strings deploy bare (#1254) — a queue name no longer lands in its binding JSON-quoted, so the dashboard and hand-written env reads see the real value.
App Runner reaps auto-created log groups on delete (#1327).
SvelteKit 3 config shape (#1347) — @sveltejs/kit@3.0.0-next.21+.
Process env wins over dotenv defaults (#1355).
Dependency security bumps (#1255) — the vulnerable extract-zip and libvips advisories are out of the runtime’s dependency closure.
Worker.domain pins its zone (#1241) — zoneId/zone/zoneName on domain, and unpinned hostnames resolve by name instead of the first page of an account-wide zone list. Thanks Ben Snyder!
Cloudflare.Website.Foldkit (#1120) and per-workflow step limits (limits: { steps }, #816) — thanks Filip Falcon!
Pipelines streams bind to Workers (#1176) — a stream in env becomes a real pipelines binding instead of falling through to JSON. Thanks spinx!
DynamoDB multi-attribute GSI keys (#1216) — GSI partition and sort keys composed of up to 4 attributes each, with order-preserving diffs.
RDS DBParameterGroup.parameters (#1205) — engine settings reconciled against live user-modified values. Thanks skusez!
Lambda packaging fixes — installed packages keep their file modes and symlinks (#855, thanks Joaquín Pérez!) and nested zipCode archives are byte-deterministic across builds (#1211).
Astro forwards prerenderEnvironment (#1242) — thanks Maxwell Brown!
The CLI honors STAGE (#1244) — thanks sethcarlton! And the version check never suggests a downgrade (#1116).
@effect/vitest moves to devDependencies (#1191) — installing alchemy no longer pulls a test toolchain (and its esbuild peer conflicts) into your resolution. Thanks Kristóf Siket!
A missing .make Layer names itself (#1055) — yielding a bare-tag resource without its implementation Layer dies with a MissingImplementationError explaining exactly what to provide, instead of a TypeError deep in a provider. Thanks apostoli!
Circular Worker layers typecheck (#1199) — Worker.make no longer leaks the other Worker’s tag into Layer.mergeAll requirements. Thanks Patrik Duksin!

Where to go next

2.0.0-beta.71 - Effect beta.105 & Better Auth

Wed, 12 Aug 2026 09:00:00 GMT

Alchemy now runs on effect 4.0.0-beta.105, with drizzle 1.0.0-rc.5-ab785fc bumped in lockstep to survive effect’s TaggedErrorClass → TaggedError rename. On top of that, @alchemy.run/better-auth gains an effectful API and a database Layer for every platform, Worker props can now be an Effect, and a batch of alchemy dev fixes makes configured ports, queue consumers, and pre-beta.66 state behave.

Breaking changes

effect >=4.0.0-beta.105 is the new minimum peer (#1132). effect renamed Schema.TaggedErrorClass to Schema.TaggedError, so earlier betas can no longer resolve. If you use Drizzle, upgrade drizzle-orm/drizzle-kit to 1.0.0-rc.5-ab785fc at the same time — see below.
Drizzle backends move out of the alchemy/Drizzle barrel (#1119). Import alchemy/Drizzle/Postgres, alchemy/Drizzle/MySQL, and alchemy/Drizzle/Cloudflare (Durable Object) directly; the barrel keeps Schema, providers(), D1, and the errors.
alchemy dev now serves assets first when assets.runWorkerFirst is omitted (#1121), matching the deployed default. A worker that intercepts asset-path requests in dev must opt in explicitly with assets: { runWorkerFirst: true } — such apps already behaved assets-first in production, so the old dev default was masking a dev/prod divergence.

effect beta.105 and the drizzle rc.5 lockstep

effect 4.0.0-beta.105 renamed Schema.TaggedErrorClass to Schema.TaggedError:

export class AuthError extends Schema.TaggedErrorClass<AuthError>()(
export class AuthError extends Schema.TaggedError<AuthError>()(
  "AuthError",
  { message: Schema.String },
) {}

drizzle-orm 1.0.0-rc.4 — which ships effect-native clients built on that API — broke against it, which pinned the entire dependency tree: you couldn’t take the effect upgrade without breaking drizzle, and vice versa. Drizzle’s 1.0.0-rc.5-ab785fc release ships TaggedError natively, so beta.71 upgrades both in lockstep (#1132, #1184):

"effect": ">=4.0.0-beta.102",
"drizzle-orm": "1.0.0-rc.4",
"drizzle-kit": "1.0.0-rc.4",
"effect": ">=4.0.0-beta.105",
"drizzle-orm": "1.0.0-rc.5-ab785fc",
"drizzle-kit": "1.0.0-rc.5-ab785fc",

When you upgrade, pin drizzle exactly — a ^1.0.0-rc.4 range can still hand you the rc.4 that breaks against effect beta.105.

Alongside the version bump, the optional Drizzle drivers now load lazily (#1119) — importing the Postgres or MySQL client no longer requires @effect/sql-mysql2/@effect/sql-pg to be installed unless you actually connect:

import * as Drizzle from "alchemy/Drizzle";
import * as Drizzle from "alchemy/Drizzle/Postgres";
const db = yield* Drizzle.Postgres(conn.connectionString, { relations });

Docs: SQL & Drizzle.

Better Auth: every database, effectful API

@alchemy.run/better-auth now supports every storage backend and wraps Better Auth’s async API in an effectful interface (#1157): yield* BetterAuth(options) gives you a fully-typed auth instance, and the database is a Layer you pick per platform. Plugin typing flows end-to-end — every auth.api.* endpoint is an Effect with a tagged BetterAuthApiError — and schema migrations run automatically at deploy as an alchemy Action, input-hash diffed and tree-shaken out of runtime bundles.

const auth = yield* BetterAuth({
  basePath: "/auth",
  emailAndPassword: { enabled: true },
  plugins: [anonymous()], // auth.api.signInAnonymous is now typed
});

// serve the Better Auth routes on Workers and Lambda unchanged
if (request.url.startsWith("/auth")) return yield* auth.fetch;

// or call endpoints directly — typed errors, set-cookie preserved
yield* auth.api.signInEmail({ body: { email, password } }).pipe(
  Effect.catchTag("BetterAuthApiError", (e) => ...), // e.statusCode, e.body.code
);

The database Layers cover every environment → target pair: CloudflareD1 (native binding + migrations over the D1 HTTP API, local simulator included), Neon (serverless driver over WebSocket — no Hyperdrive, no pg), AuroraDataApi (SQL over HTTPS with IAM — no VPC attachment), CloudflareHyperdrive, generic Postgres and MySQL TCP fallbacks (PlanetScale, RDS, any connection string), SQLite for local dev, Memory for tests, and Drizzle to bring your own db via better-auth’s official adapter.

Because the database is a Layer, your auth code never changes — you swap the provided Layer. On D1:

import { CloudflareD1 } from "@alchemy.run/better-auth/CloudflareD1";

export const AuthDb = Cloudflare.D1.Database("AuthDb");

export default class AuthWorker extends Cloudflare.Worker<AuthWorker>()(
  "AuthWorker",
  { main: import.meta.url },
  Effect.gen(function* () {
    const auth = yield* BetterAuth({ emailAndPassword: { enabled: true } });
    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        if (request.url.startsWith("/auth")) return yield* auth.fetch;
        return HttpServerResponse.text("ok");
      }),
    };
  }).pipe(Effect.provide(CloudflareD1(AuthDb))),
) {}

Moving to PlanetScale Postgres is only a Layer swap — the BetterAuth program is untouched:

import { CloudflareD1 } from "@alchemy.run/better-auth/CloudflareD1";
import { Postgres } from "@alchemy.run/better-auth/Postgres";

export const AuthDb = Cloudflare.D1.Database("AuthDb");
export const AuthDb = Planetscale.PostgresDatabase("AuthDb");
export const AuthRole = Planetscale.PostgresRole("AuthRole", { database: AuthDb });

const AuthDatabase = Layer.unwrap(
  Effect.map(AuthRole, (role) => Postgres(role.connectionUrl)),
);

export default class AuthWorker extends Cloudflare.Worker<AuthWorker>()(
  "AuthWorker",
  { main: import.meta.url },
  Effect.gen(function* () {
    const auth = yield* BetterAuth({ emailAndPassword: { enabled: true } });
    return {
      fetch: ...,
    };
  }).pipe(Effect.provide(CloudflareD1(AuthDb))),
  }).pipe(Effect.provide(AuthDatabase)),
) {}

The API reference also learned to document Layers as first-class pages (#1159) — each database Layer gets its own generated page declaring what it provides and its peer dependencies.

Docs: Better Auth.

`alchemy dev` fixes

A configured dev port could serve the wrong app (#1129): the proxy bound only 127.0.0.1, browsers prefer ::1, and any framework dev server hunting from its default port could squat the IPv6 half of localhost:

proxy listening on 127.0.0.1:3000
vite dev server binds [::1]:3000
http://localhost:3000 → the wrong app

The proxy now owns its port on both address families, and a dev restart no longer cascades every configured port in the stack up by one.

Alchemy.remote() bindings no longer go stale (#1139) — Cloudflare’s edge preview was pinning the remote-binding proxy to sessions pointing at destroyed resources, 400ing every proxied KV/R2/D1 call for up to 50 minutes.

Framework production builds run in disposable child processes with NODE_ENV=production pinned (#1139, #1178), so user config and plugins can chdir, mutate process.env, or crash without taking the engine with them.

And every local worker announces where it’s serving as it comes up:

[api-worker] ready at http://localhost:1337

State from older versions recovers automatically

Stacks that mixed alchemy dev and alchemy deploy on versions before beta.66 could end up with state the engine no longer knew how to handle — deploys and destroys failing forever with errors like:

BadRequest: There is a malformed parameter in the request

Cloudflare queue "jobs" already has a worker consumer for script
"worker-t2po...", but this resource is configured for "worker-qwh3..."

beta.71 recognizes these situations and repairs them on your next run: old dev-mode state is routed to the local simulator instead of the real Cloudflare API (#1130), resources deployed before beta.66 are properly replaced — not silently abandoned — when you run dev (#1110), and queue/consumer wiring left behind by old runs is reattached or cleaned up (#1133).

Also in this release

Cloudflare tooling moves into the monorepo (#1122) — the runtime and framework adapters are now @alchemy.run/cloudflare-runtime and @alchemy.run/cloudflare-frameworks, developed, tested, and released with alchemy itself. Thanks Rahul Mishra!
Queue consumers work on Website.Vite workers in dev (#1113) — consumer wiring survives the Vite child’s boot order, and send() to a queue with no running consumer resolves instead of hanging forever.
Local queue consumers honor batch settings (#1126) — batchSize/maxWaitTimeMs now map onto the local broker’s field names instead of being silently ignored.
Asset serving fixes (#1121) — the asset MIME table covers the full extension set (avif, webp, woff2, … previously application/octet-stream), and asset hashes include the extension so identical bodies under different extensions keep distinct content types. One-time effect: all assets re-upload on your next deploy.
Docker containers receive their environment values (#1118) — environment entries resolved empty inside the container, breaking e.g. PostgreSQL bootstrap.
InternetGateway detach rides out lingering ENIs (#1125) — Fargate and Lambda ENIs can hold public IPs for 5–20 minutes after their owner is deleted; the detach now waits them out instead of leaving an IGW+VPC residue on destroy.
Auto-generated names avoid reserved prefixes (#1186) — stacks named aws-* produced physical names that Resource Groups, S3 Tables, and S3 Vectors reject; colliding prefixes are now escaped, and non-colliding names are byte-for-byte unchanged.
Dates persist correctly in state (#1164) — a Date-typed prop used to serialize as {} in durable state stores, churning a phantom update on every subsequent plan.

Where to go next

2.0.0-beta.70 - Web Frameworks & Full Local Dev

Thu, 06 Aug 2026 09:00:00 GMT

beta.70 deploys Next.js, Astro, Nuxt, SvelteKit, Waku, and Octane to Cloudflare Workers — programmatic builds, no wrangler.json, no adapter config. And alchemy dev now emulates effectively the entire Cloudflare surface locally: browser rendering, image transforms, email, cron triggers, secrets, Stream, and tail consumers join KV, R2, D1, and Queues. The release also adds plan-time data sources, moves Kubernetes workloads out of EKS into a cluster-agnostic namespace, and migrates every SDK to distilled v1.

This post covers beta.67 through beta.70 — beta.67 was a small fix release that didn’t get its own notes, and beta.68/beta.69 are superseded by beta.70.

The Website family: six new frameworks

Cloudflare.Website grows from Vite and StaticSite to a full framework family: Nextjs (#923), Astro, Nuxt, SvelteKit, Waku (#1086), and Octane (#1093).

Every resource builds your project programmatically — no wrangler binary, no wrangler.json, no adapter packages to install — and deploys it as a Worker: server bundle plus static assets. Your framework’s own config file (astro.config.*, vite.config.ts, nuxt.config.ts, …) loads natively; Alchemy merges its Cloudflare config over it. Builds are memoized by content-hashing the input files, so an unchanged project skips the build and deploy entirely.

const site = yield* Cloudflare.Website.Nextjs("Site", {
  env: {
    GREETING: "Hello from Alchemy!",
    UPLOADS: bucket, // any binding, via getCloudflareContext().env
  },
  domain: "example.com",
});

Each resource returns a plain Worker, so the entire Worker vocabulary applies: env takes any binding (KV, R2, Durable Objects, secrets), plus domain, compatibility, and asset routing. Framework specifics are handled per resource:

Next.js builds through the OpenNext pipeline. With a KV incremental cache and a Durable Object queue, writable ISR fully works — time-based regeneration and on-demand revalidatePath:

const site = yield* Cloudflare.Website.Nextjs("Site", {
  env: {
    NEXT_INC_CACHE_KV: incCache,
    NEXT_TAG_CACHE_KV: tagCache,
    NEXT_CACHE_DO_QUEUE: Cloudflare.DurableObject("NEXT_CACHE_DO_QUEUE", {
      className: "DOQueueHandler", // ships in the OpenNext bundle
    }),
  },
});

Astro defaults to server output and auto-provisions a KV namespace for zero-config sessions, bound as SESSION:

const site = yield* Cloudflare.Website.Astro("Site", {
  env: { CACHE: kv, UPLOADS: bucket }, // via Astro.locals.runtime.env
});

Nuxt builds through nitro’s cloudflare_module preset and natively loads your nuxt.config.ts — the nuxt prop merges over it:

const site = yield* Cloudflare.Website.Nuxt("Site", {
  nuxt: { routeRules: { "/about": { prerender: true } } },
});

SvelteKit uses an in-memory Cloudflare adapter — no svelte.config.js changes, no @sveltejs/adapter-cloudflare:

const site = yield* Cloudflare.Website.SvelteKit("Site", {
  env: { API_KEY: Alchemy.secret("API_KEY") }, // via platform.env
});

Waku serves RSC SSR at request time and prerenders SSG pages at build time inside workerd. A custom entry can even host Durable Objects alongside waku’s fetch handler:

const app = yield* Cloudflare.Website.Waku("App", {
  main: "src/worker-entry.ts", // optional custom entry
  env: { COUNTER: Cloudflare.DurableObject("Counter") },
});

Octane deploys OctaneJS fullstack apps through Octane’s own Cloudflare adapter:

const site = yield* Cloudflare.Website.Octane("Site", {
  env: { CACHE: cache }, // via context.platform.env
});

All six run under alchemy dev on their framework’s own dev server — Turbopack HMR for Next.js (nextjs: { devMode: "hmr" }, or the default preview parity under workerd), Vite HMR for the rest — with real bindings resolved in-process.

Docs: Frontend frameworks.

`alchemy dev` covers the whole surface

beta.66 emulated KV, R2, D1, and Queues locally. beta.70 finishes the campaign (#1039) — miniflare parity and beyond:

Cron triggers fire in dev — crons schedule real timers, and the miniflare-compatible /cdn-cgi/handler/scheduled route triggers them manually. Previously scheduled() never ran under alchemy dev.
Browser Rendering — env.BROWSER drives a real local Chrome over CDP; @cloudflare/puppeteer works unchanged.
Images — env.IMAGES transforms run through sharp locally.
Email, both directions — send_email validates and persists sent mail as .eml files, and a POST to /cdn-cgi/handler/email drives your email() handler with accept, reject, and reply semantics.
Secrets Store — a Worker binding a secrets_store_secret now boots in dev, with the real (Redacted-sourced) value seeded into the simulator. secret_key CryptoKey bindings boot too, and gain a user-facing resource: Cloudflare.Workers.SecretKey.
Stream — Cloudflare.Stream.Stream("STREAM") is a new binding surface entirely (alchemy previously had none), working live and against a local video-store simulator in dev.
Tail consumers — the new tailConsumers prop uploads as tail_consumers metadata live, and a local producer’s trace events reach a local tail Worker in dev.
Workflows and Hyperdrive are now first-class dual providers, so switching between dev and deploy is an engine-orchestrated replacement instead of ad-hoc branching.

Alchemy.remote() is now the single way to opt a binding onto the real cloud during dev (#1065). Worker-only bindings gained pipe(), so the same aspect works on plain binding values in an async Worker’s env:

// Effect-native Worker
const browser = yield* Cloudflare.Browser("BROWSER").pipe(Alchemy.remote());

// async Worker env
env: { IMAGES: Cloudflare.Images.Images("IMAGES").pipe(Alchemy.remote()) }

And local and live compose into hybrid topologies. Pin a queue live and everything around it stays local — the local Worker produces real messages into the real queue, and its local consumer drains the same queue through a pull loop, with the usual batching, retry, and dead-letter semantics:

// the queue is real, even in dev
const Jobs = Cloudflare.Queues.Queue("Jobs").pipe(Alchemy.remote());

// the worker is local: it produces into the real queue, and its
// consumer drains the real queue through a pull loop
export default Cloudflare.Worker("Processor", { main: import.meta.url },
  Effect.gen(function* () {
    // subscribe and process messages from the real queue in the local worker
    yield* Cloudflare.Queues.consumeQueueMessages(jobs, (stream) =>
      Stream.runForEach(stream, (msg) => processJob(msg.body)),
    );
  }),
) {}

Your dev session sees the same traffic as staging — messages produced by deployed services or a teammate’s session land in your local handler, and your local edits process them instantly.

Docs: Local development.

Vite dev servers run in child processes

Under alchemy dev, every Vite dev server now runs in its own child process (#1076) because much of Vite’s plugin ecosystem resolves paths against process.cwd(). Config loaders, framework plugins, and tailwind all broke when the stack ran from a different directory than the site. Each server now gets its project root as its working directory, so all of that just works, and multiple sites in one stack no longer interfere with each other.

Each server’s output streams into the dev console prefixed with its worker name, so interleaved logs from several sites stay readable. The work also surfaced an upstream Vite bug in server.port handling, fixed in vitejs/vite#23158.

Rename resources with `renamedFrom()`

Changing a resource’s logical ID used to plan a replacement — a new resource created under the new ID, the old one (and its data) deleted. Alchemy.renamedFrom (#1108) declares the id(s) a resource was previously registered under, and the engine migrates the persisted state row instead:

const bucket = yield* Cloudflare.R2.Bucket("Bucket");
const bucket = yield* Cloudflare.R2.Bucket("Assets").pipe(
  Alchemy.renamedFrom("Bucket"),
);

The next deploy plans a single re-branding update — same instance ID, same physical name, nothing created or deleted in the cloud:

Plan: 1 to update
[Assets] update (renamed from Bucket)

A bare string resolves against the ambient namespace exactly like the id argument; { fqn: "..." } addresses a move between namespaces; listing several former ids covers rename chains. The migration is deliberately conservative — types must match, ambiguous claims and rename cycles fail the plan, and a leftover row from an interrupted move is dropped state-only, never touching the cloud. This is what lets the StaticSite fix above migrate <id>/Worker → <id> without replacing your Worker.

Docs: Renaming Resources.

Data sources: plan-time `execute`

Every Binding.Service gains execute(...) (#1037) — invoke a capability at plan/deploy time and get an Output, the Terraform data-source / Pulumi invoke shape. AWS.EC2.getAmi is the first:

const instance = yield* AWS.EC2.Instance("web", {
  imageId: AWS.EC2.getAmi({
    owners: ["amazon"],
    name: ["al2023-ami-2023.*"],
  }).ImageId.as<string>(),
  instanceType: "t3.micro",
  subnetId: subnet.subnetId,
});

The same contract still works as a runtime binding — yield* AWS.EC2.GetAmi(opts) inside a Function grants ec2:DescribeImages and looks images up at runtime. One capability, two execution times.

Cloudflare VPC services use the same shape (#821, thanks Filip Falcon!) — Cloudflare.VpcService.lookup({ name }) resolves a service managed outside the stack, and binding it (or a managed VpcService) to a Worker’s env yields a Fetcher that tunnels into your private network:

const worker = yield* Cloudflare.Worker("Worker", {
  main: "./src/worker.ts",
  env: {
    VPC: Cloudflare.VpcService.lookup({ name: "my-vpc-service" })
  },
});

Docs: Bindings — data sources.

Kubernetes goes cluster-agnostic

The Kubernetes workloads from beta.64 move out of AWS.EKS.* into a new alchemy/Kubernetes namespace (#986): Deployment, Job, Manifest, and HelmChart reference a cluster instead of being EKS resources. Pass an AWS.EKS.Cluster and auth (SigV4), the image registry (ECR), and workload identity (Pod Identity) resolve through its adapter — or point at anything kubectl can reach:

const local = Kubernetes.KubeConfig({ context: "kind-dev" });

yield* Kubernetes.Deployment("Api", {
  cluster: local,
  image: "ghcr.io/acme/api:v3",
});

Exec credential plugins (aws eks get-token, kubelogin, gke-gcloud-auth-plugin) are honored, so EKS today and AKS/GKE via kubeconfig immediately. Add Kubernetes.providers() to your stack; the old AWS.EKS.Deployment-style exports keep compiling for one release as deprecated aliases, and existing state migrates in place.

distilled v1

Every cloud API alchemy talks to goes through a distilled SDK — typed Effect clients with every error in the type-level union. Until now, each provider’s SDK came out of its own hand-rolled generator: one for Cloudflare, one for AWS, one for each OpenAPI-shaped API, each with its own quirks and its own bugs.

distilled v1 replaces all of that with one compiler (#823). Every provider’s native spec format — OpenAPI (shared by 13 providers), Cloudflare’s API docs, AWS’s official Smithy models, Google Discovery, Azure ARM, GraphQL introspection — is first converted into a standard Smithy model, and a single Smithy-to-SDK codegen compiles every model into its Effect client. Each provider package is just data: a spec converter config, a small trait/pagination/protocol vocabulary (Cloudflare’s is ~115 lines), and a thin runtime protocol seam (SigV4 for AWS, a generic bearer-REST protocol shared by 12 providers).

The result is 20 packages and ~45k operations — 429 AWS services, all of Azure and GCP, Cloudflare, Kubernetes, Stripe, PostHog, and the long tail — all built, patched, and regenerated through the same pipeline. Fixing a mistyped error or a wrong response schema is now one JSON Patch against a Smithy model, in the same dialect regardless of provider, and adding a whole new provider is a spec config rather than a new generator.

The migration was verified name-for-name against the v0 surfaces and by alchemy’s full live test tree — nearly 6,000 tests against real cloud APIs — with zero SDK regressions.

MySQL for effect-sql and Drizzle

SQL.MySQL and Drizzle.MySQL complete the SQL client matrix (#1063) — the missing siblings of the Postgres and D1 clients:

import * as SQL from "alchemy/SQL/MySQL";

const hd = yield* Cloudflare.Hyperdrive.Connect(Hyperdrive);
const sql = yield* SQL.MySQL({ url: hd.connectionString });
const users = yield* sql`SELECT * FROM users`;

On workerd the client automatically switches to MySQL’s text protocol (Hyperdrive’s proxy has no prepared statements) and eval-free row parsers; Lambda and containers keep prepared statements. Same lazy per-request pool lifecycle as Postgres. Docs: SQL.

WorkerEntrypoint bindings

Bind a specific WorkerEntrypoint class exported by another Worker — with optional ctx.props riding along (#1097):

const caller = yield* Cloudflare.Worker("Caller", {
  main: "./src/caller.ts",
  env: {
    API: Cloudflare.WorkerEntrypoint(target, "Api"),
    VENDOR: Cloudflare.WorkerEntrypoint(vendor, {
      entrypoint: "Vendor",
      props: { baseUrl: site.url }, // → the target's ctx.props
    }),
  },
});

alchemy dev delivers ctx.props to the local target today.

Pure annotations are opt-in only

The bundler annotates discarded-result calls as pure so minification can tree-shake them — that’s what keeps effect’s unused modules out of your Worker. It used to auto-extend that treatment to your own package when it declared sideEffects: false, which could delete top-level registrations like app.get("/", handler) under minification: the deploy succeeds, unbundled unit tests stay green, and every request 404s.

Auto-detection is removed entirely (#1021) — thanks Daniel Gangl! effect, @effect/*, and alchemy’s own packages stay annotated by default; any other package is only touched when you list it deliberately:

build: {
  pure: { packages: ["my-lib", "@my-scope/*"] },
  // or pure: false to disable annotation entirely
}

Also in this release

Access-managed OAuth applications (#1023) — oauthConfiguration on Access.Application, including dynamic client registration for MCP-style clients. Thanks Magoz!
Typed Access IdP configs (#1002) — IdentityProvider props are a discriminated union on type, so an azureAD IdP missing directoryId is a compile error; plus zone scope and SAML certificate sets. Adoption of IdPs with empty display names is fixed and getIdentityProvider joins as a data source (#1099).
SESv2 sending coverage (#976) — identity policies, contact lists, tenants, dedicated IPs, and account settings: 9 resources and 5 bindings. Thanks Arya Saatvik (who also repaired the AWS utility subpath exports in #1033)!
Declarative Lambda versions (#993) — AWS.Lambda.Version and Alias, retain-by-default for production-safe Durable Function deployments. Thanks again Arya Saatvik! The engine now re-resolves whole-resource references at apply so downstream resources see fresh upstream attributes (#1068, #1070).
alchemy state export (#1043) — every state record across stacks and stages as one JSON document, deterministically ordered so exports diff cleanly.
Drizzle on Durable Object SQLite (#1031) — Drizzle.DurableObject applies drizzle-kit migrations inside a DO, and .sql imports bundle as text modules.
Lambda build.install pins from lockfiles (#858) — the installed dependency graph is resolved against your lockfile (npm, pnpm, bun, yarn) via generated overrides, so deployed artifacts can’t drift. Thanks Joaquín Pérez!
Effect error responses reach the client (#1011) — a failed handler’s HttpServerResponse is preserved instead of being flattened to a bare 500. Thanks Patrik Duksin (who also fixed local D1 migrations in #1009)!
Engine reliability — an interrupted first deploy no longer bricks later plans with a SchemaError (#1005), and cyclic props and class instances no longer send the engine’s prop walkers into infinite recursion (#1094).
OCI Helm charts parse correctly (#1042) — thanks Andy Jefferson!
PlanetScale migrations split same-line breakpoint markers (#1062) — thanks BEEIRL!
Website & Vite fixes — the assets directory is hashed during plan diff so asset-only changes deploy (#1045), Vite’s base applies to the assets manifest (#1048), Website uses the proper domain object with redirects (#1088), dev child ports are allocated ephemerally (#1090), and relative rootDirs hash stably (#1079) — thanks Rahul Mishra, who also fixed relative DNS record matching in #1017!
Prisma provider aligned with the management API (#1012) — thanks Aman Varshney!
pg, mysql2, mongodb, and @vercel/nft are optional peer dependencies (#1069, #1071) — install only what you use.

Where to go next

2.0.0-beta.66 - Local Emulation & Gradual Deployments

Thu, 30 Jul 2026 20:00:00 GMT

beta.66 makes alchemy dev fully local by default: KV, R2, D1, and Queues are emulated on your machine, and Alchemy.remote() opts any resource back onto the real cloud. Workers gain versions, gradual deployments, and sticky sessions. The release also redesigns how Worker URLs and domains are modeled, and adds OpenTelemetry export, a Prisma provider, and a Bedrock LanguageModel binding.

Breaking change

Worker URL configuration is redesigned (#977). The url and subdomain props are replaced by workersDev, domain takes an object form, and the domains output is replaced by urls + domain. This applies to Cloudflare.Worker and Cloudflare.Website.*.

const worker = yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  url: false,
  subdomain: { previewsEnabled: true },
  domain: ["example.com", "www.example.com"],
  workersDev: { enabled: false, previewsEnabled: true },
  domain: {
    name: "example.com",
    aliases: ["www.example.com"],
  },
});

worker.domains; // string[]
worker.url;     // "https://example.com" — always urls[0]
worker.urls;    // every URL serving the Worker, most significant first
worker.domain;  // { name, aliases, redirects } | undefined

url: true (the default) becomes workersDev: true — omit it.
domain: "example.com" still works as a string.
domain: [] (explicit detach-all) becomes domain: null; an omitted domain leaves attachments unmanaged.
Persisted state migrates automatically on the first redeploy.

See Worker URLs redesigned below for the new model.

Local emulation in `alchemy dev`

Provider mode (local vs live) is now a first-class engine concept (#963). KV Namespaces, R2 Buckets, D1 Databases, and Queues are emulated locally during alchemy dev — they fabricate dev:-prefixed ids with no cloud calls, and Worker bindings lower onto local workerd simulators. D1 applies migrationsDir and importFiles against the local database.

Alchemy.remote() opts a resource (or a whole scope) back onto the real cloud during dev:

// emulated locally in dev
const db = yield* Cloudflare.D1.Database("DB", {});

// real queue, even in dev
const jobs = yield* Cloudflare.Queues.Queue("Jobs", {}).pipe(
  Alchemy.remote(),
);

Remote queues work in both directions: a local Worker can produce to a live queue, and a local queue() handler drains a live queue through an http_pull consumer.

The State Store now records whether each resource is local or live. Switching between the two plans a replacement: alchemy deploy right after alchemy dev replaces local instances with real cloud resources instead of updating over them. Node-side capability clients (e.g. in Actions) reach the same local simulators the Workers see, so a seed script writes to the same local KV your Worker reads.

Docs: Local development.

Worker versions & gradual deployments

The version prop maps Cloudflare’s versions & gradual deployments onto alchemy stages (#948).

Upload one stage’s code as a zero-traffic version of another stage’s Worker — the PR-preview workflow:

const parent = yield* Cloudflare.Worker.ref("Api", { stage: "staging" });

yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  version: { parent, message: `PR #${process.env.PR_NUMBER}` },
});

The version’s url is a stable aliased preview URL that re-points at each newly uploaded version. Add traffic to canary a share of the parent’s traffic, or roll out a Worker’s own deploy gradually:

version: { parent, traffic: 10 }  // canary: 10% of staging's traffic
version: { traffic: 25 }          // self-rollout: new version at 25%

version.affinity pins each user to one version for the duration of a rollout (#985), requested by Eric Clemmons:

version: {
  traffic: 10,
  // sticky by session cookie, falling back to sticky IP
  affinity: { cookie: "session_id", ip: true },
}

Docs: Gradual deployments.

Worker URLs redesigned

workersDev controls the workers.dev surface (and is actually reconciled — the old subdomain prop was silently ignored), and domain grows aliases and redirects (#977):

const worker = yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  workersDev: false,
  domain: {
    name: "example.com",
    aliases: ["www.example.com"],     // also serve the Worker
    redirects: ["old.example.com"],   // 301 → https://example.com
  },
});

Each redirect hostname gets managed DNS and an edge certificate, plus a zone redirect rule that 301s (path and query preserved) before Workers run — redirected requests never invoke the Worker.

urls lists every URL that serves the Worker, most significant first, and url is always urls[0]:

// workers.dev only (the default)
["https://api.my-team.workers.dev"]

// custom domain — outranks workers.dev
["https://example.com", "https://api.my-team.workers.dev"]

// domain with aliases, workersDev: false
["https://example.com", "https://www.example.com"]

// version worker (version.parent) — the stable aliased preview
// URL first, then this upload's per-version URL
[
  "https://pr-42-api.my-team.workers.dev",
  "https://a1b2c3d4-api.my-team.workers.dev",
]

// gradual rollout (version: { traffic }) — the uploaded version's
// preview URL trails
[
  "https://example.com",
  "https://api.my-team.workers.dev",
  "https://a1b2c3d4-api.my-team.workers.dev",
]

// alchemy dev — the dev server's actual surface
["http://localhost:5173", "http://192.168.1.23:5173"]

Redirect hostnames never appear in urls — they serve no content. That makes urls the CORS allow-list:

const site = yield* Cloudflare.Website.Vite("Site", { ... });

// allow the site — on every URL that serves it — to call the API
const api = yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  env: { ALLOWED_ORIGINS: site.urls },
});

In production that allow-list is the site’s custom domain, aliases, and workers.dev URL. Under alchemy dev it is the Vite dev server’s Local and Network URLs — localhost plus the LAN address (http://192.168…) — so a phone on your Wi-Fi can load the site and call the API.

Docs: Custom domains.

OpenTelemetry export

Deployed apps export traces, logs, and metrics over OTLP from every runtime — Worker, Durable Object, Workflow, Lambda, Containers, ECS Task (#860). Telemetry is a Layer, composed into the Function/Worker’s Effect.provide like any other binding:

Effect.provide(
  Layer.mergeAll(
    Cloudflare.R2.ReadWriteBucketBinding,
    Axiom.Telemetry({ token: Ingest, traces: Traces, logs: Logs }),
    Alchemy.Telemetry.layerOtlp({
      url: "https://api.honeycomb.io",
      headers: { "x-honeycomb-team": apiKey },
    }),
  ),
)

Axiom.Telemetry is sugar over the generic Alchemy.Telemetry.layerOtlp, which speaks to any OTLP backend. Exporters compose: merge several and every destination receives the telemetry with agreeing trace ids. Without a telemetry layer, Effect’s no-op tracer keeps instrumentation free.

Docs: Telemetry.

Prisma provider

alchemy/Prisma provisions Prisma Postgres and Prisma Compute (#416) — thanks Aman Varshney!

const project = yield* Prisma.Project("Project", { createDatabase: false });
const postgres = yield* Prisma.Postgres("Postgres", { project });
const connection = yield* Prisma.Connection("Connection", {
  database: postgres,
});

const app = yield* Prisma.Compute("App", {
  project,
  path: "./app",
  build: { command: "bun run build", outdir: ".output" },
  env: { DATABASE_URL: connection.databaseUrl },
});

Prisma.Compute is also an effectful runtime, like a Cloudflare Worker or a Lambda: pass main and an Effect body, and the app is bundled from your Stack file with the Connect binding wiring the database in:

export default Prisma.Compute(
  "Api",
  { project, main: import.meta.filename },
  Effect.gen(function* () {
    const db = yield* Prisma.Connect(connection);
    const sql = yield* SQL.Postgres({ url: db.databaseUrl });

    return {
      fetch: Effect.gen(function* () {
        const users = yield* sql`SELECT * FROM users`;
        return yield* HttpServerResponse.json(users);
      }),
    };
  }).pipe(Effect.provide(Prisma.ConnectBinding)),
);

Resources reconcile from observed API state, recover from interrupted deployments, and never persist Prisma credentials as plaintext.

Docs: Prisma.

Bedrock LanguageModel

AWS.Bedrock.LanguageModel turns any Bedrock model into an effect/unstable/ai LanguageModel Layer (#919), so generateText, streamText, toolkits, and Chat run against Bedrock unchanged:

const model = yield* AWS.Bedrock.LanguageModel([
  "us.anthropic.claude-sonnet-4-20250514-v1:0",
]);

return {
  fetch: Effect.gen(function* () {
    const response = yield* LanguageModel.generateText({ prompt });
    return yield* HttpServerResponse.json({ text: response.text });
  }).pipe(Effect.provide(model)),
};

The binding is the IAM boundary: which models the Function may call is fixed at deploy time. Model choice and inference parameters are per-call decisions via AWS.Bedrock.withModelParameters. The adapter speaks Bedrock’s Converse API directly.

Docs: Bedrock.

Also in this release

Assets-only Workers (#969, #970) — a Worker with only an assets directory deploys with no script at all, so static requests are free and never invoke a Worker. The class form works without an impl.
Headless OAuth login (#962) — alchemy login now works over SSH and in containers via a hosted relay page: paste the code when the browser can’t reach the CLI. Thanks BlankParticle (who also fixed prompt cancellation in #968)!
Lambda Layers (#971) — AWS.Lambda.LayerVersion plus a layers prop on Function. Thanks Arya Saatvik!
SES email receiving (#939) — receipt rule sets, rules, IP filters, and a SendBounce binding; guide at /aws/email/receiving. Thanks again Arya Saatvik!
Docker Swarm (#972) — Docker.Swarm, Docker.Context, and Docker.Service, including effectful services bundled and deployed from an Effect impl. Thanks Sergey Bekrin!
Container-backed Durable Objects on async Workers (#956) — host npm-packaged container DO classes like @cloudflare/sandbox’s Sandbox via DurableObject("Sandbox", { container }).
Worker.URL (#964) — bind a Worker’s own public URL onto itself; resolves to the local dev URL under alchemy dev.
Destroy aggregates failures (#973) — a failing delete no longer aborts the destroy. Every delete is attempted and one typed DestroyError reports what failed and what was blocked by it.
Dev Worker handoff is make-before-break (#863) — the previous workerd instance keeps serving until its replacement starts, closing the 503 window on slow restarts (e.g. container image prep).
Output env secrets upload encrypted (#943) — an Output<Redacted> in a Worker’s env now uploads as secret_text instead of readable text, and InferEnv types are preserved. Thanks Seth Carlton!
OAuth credentials refresh on expiry (#966) — a dev session that outlives the access token re-resolves credentials instead of failing until restart (the “dev breaks after machine sleep” hang).
Worker read fan-out cut (#932, #944, #975) — subdomain lookups are memoized, route discovery is scoped to known zones, and unmanaged custom domains converge to a noop plan — fixing 429 rate-limit errors on accounts with many zones.
Plain Workers default to nodejs_compat (#796) — the default previously reached only Effect-native Workers. The same PR resolves Config/Output env values in StaticSite builds.
ECS — service reconciliation waits for rollout, drain, and healthy ALB targets (#945, thanks samnan-kradle!), taskRoleManagedPolicyArns attach on the Service form (#936, thanks bweis!), and environmentFiles joins the shared task-definition surface (#904).
send_email stubs locally in dev (#865) — send() logs to the dev console instead of delivering mail; pipe the binding through Alchemy.remote() to send for real.
Destroy removes the persisted stack output (#965) — cross-stack refs to a destroyed stage now fail with the typed InvalidReferenceError instead of reading an empty husk.
PlanetScale metadata-only updates no longer replace roles (#957).
CloudFront updates merge observed config (#935) — ends IllegalUpdate failures on members the props don’t express.
CLI — the version-update warning prints before interactive prompts (#959), and rolldown’s native binding loads lazily so non-Cloudflare stacks deploy without it (#955).
Local dev fixes — a Worker consuming a queue with a dead-letter queue starts again (#1000), and Container env bindings no longer break Vite builds (#999).

Where to go next

2.0.0-beta.65 - SageMaker HyperPod

Mon, 27 Jul 2026 06:00:00 GMT

beta.65 brings SageMaker HyperPod to the AWS provider: persistent ML training fleets, Slurm or EKS orchestrated, with task governance and typed workloads. It also fixes two Worker bundling bugs that broke deployed apps, and makes destroy and nuke converge in one pass.

Breaking change

The alchemy/SQL barrel is removed (#951). It eagerly loaded every backend, so projects without the optional @effect/sql-pg peer crashed on import. Import each client from its own subpath instead:

import * as SQL from "alchemy/SQL";
import * as SQL from "alchemy/SQL/D1";
import * as SQL from "alchemy/SQL/Postgres";

SageMaker HyperPod

HyperPod is AWS’s persistent fleet for ML training and inference: accelerated instances with automatic health checks and faulty-node replacement, staying up between jobs. Where ECS and EKS run application containers, HyperPod runs distributed training (#924).

AWS.SageMaker.Cluster provisions the fleet. The default orchestrator is Slurm — an S3 lifecycle script, an execution role, and instance groups:

const cluster = yield* AWS.SageMaker.Cluster("TrainingCluster", {
  instanceGroups: {
    controller: {
      InstanceType: "ml.t3.medium",
      InstanceCount: 1,
      ExecutionRole: role.roleArn,
      LifeCycleConfig: {
        SourceS3Uri: script.sourceS3Uri,
        OnCreate: script.onCreate,
      },
    },
  },
});

Instance groups reconcile in place: change a count or add a group and the cluster updates; remove one and it is deleted from the cluster. Jobs are submitted with sbatch over SSM — every node is an SSM target.

Pass orchestrator: { Eks } and the fleet’s nodes join an EKS cluster you provide. From there, workloads are ordinary Kubernetes objects — and AWS.EKS.Job and Deployment opt onto HyperPod nodes with the hyperpod prop. The instance-group keys carry through the cluster’s attributes as types, so a typo’d group name is a compile error:

const train = yield* AWS.EKS.Job(
  "Train",
  {
    cluster: eks,
    main: import.meta.url,
    hyperpod: { instanceGroup: hyperpod.instanceGroups.workers },
  },
  Effect.gen(function* () {
    return {
      run: Effect.gen(function* () {
        // training logic; bindings land IAM on pod identity
      }),
    };
  }),
);

Task governance arbitrates the fleet between teams: ClusterSchedulerConfig sets priority classes and ComputeQuota reserves per-team capacity (Kueue under the hood). A workload submits through governance by passing the quota resource:

hyperpod: {
  instanceGroup: hyperpod.instanceGroups.workers,
  quota,                     // → hyperpod-ns-research + queue label
  priorityClass: "training",
},

Docs: HyperPod. The full working stack (both orchestrators, governance, every workload tier) is examples/aws-hyperpod.

Worker bundling fixes

Two bundling bugs could break a deployed Worker even though the deploy succeeded. Both are fixed.

Hono/Express-style route registrations were stripped from the bundle (#952). purePlugin annotated top-level calls like app.get("/", handler) as pure, and under minification that annotation is a deletion instruction — so every request 404’d. Statement-position calls are now only annotated in packages that explicitly declare sideEffects: false, and never in entry modules.

Cross-chunk evaluation order is now correct (#940). Rolldown could split top-level initializers (e.g. Drizzle pgTable schemas) into a chunk that ran before its dependencies, failing Cloudflare startup validation with Cannot access 'a' before initialization. strictExecutionOrder is now on by default, preserving ESM semantics across chunk boundaries.

The same PR opens up per-Worker control of chunking: build forwards rolldown output options and preserveEntrySignatures:

Cloudflare.Worker("Api", {
  main,
  build: {
    output: {
      codeSplitting: {
        groups: [{ name: "auth", test: "packages/(schema|auth)/" }],
      },
    },
  },
});

Destroy and nuke converge in one pass

Destroying a stack with a VPC-attached Lambda used to strand subnets and security groups on DependencyViolation, forcing repeated destroy runs (#937). The cause: Lambda’s Hyperplane ENIs linger in the VPC for many minutes after the function is deleted, and AWS’s own reaper can take 20+ minutes to clear them. Subnet and security-group deletes now identify detached Lambda ENIs and delete them directly, so one destroy removes everything.

alchemy unsafe nuke gets the same treatment (#950):

--independent retries each delete on its own capped backoff instead of a shared barrier, so one hanging delete only ever stalls itself.
Providers declare which resource types their cloud-side teardown consumes (a HyperPod cluster deletes its ENIs by assuming its IAM role inside its VPC), and nuke deletes in topologically-ordered waves so a role is never deleted out from under an in-flight cluster teardown.

Also in this release

_redirects and _headers now reach Cloudflare (#928) — the files were read and hashed but never sent, so redirect and header rules were silently dropped. They now apply in deploys, no-op redeploys, and alchemy dev.
Workflows under alchemy dev: pausing a workflow no longer reports errored (#934), and workflow classes export correctly in vite dev (#933).
Docker.Container supports labels and stopTimeout (#931) — enabling Traefik-managed routing in a remote Docker context. Thanks Gerbuuun!
alchemy/Test/Vitest is restored (#947) — the internal move to alchemy-test accidentally removed the public vitest harness that shipped through beta.63.
Branded primitives stay opaque in Outputs (#941) — a string & Brand<"UserId"> Action output is now Output<UserId> instead of exploding into an ObjectExpr over every string method.
SQL fragment helpers compose on wrapped clients (#951) — sql`INSERT INTO users ${sql.insert(row)}` and nested sql.and/sql.or now replay against the resolved client, with new live test suites covering the full SqlClient surface on D1 and Postgres.
The alchemy-test plain reporter prints a [done/total] progress counter per test and a failed-test list at the end of the run.

Where to go next

A Test Runner for Agents

Wed, 22 Jul 2026 07:00:00 GMT

Alchemy’s test suite is not a normal test suite. It’s 4,000+ live tests that deploy real resources to real clouds and tear them down again. Some finish in milliseconds. Some take minutes — provisioning an EKS cluster, waiting for an eventually consistent API to converge, pushing a message through a queue and polling until it comes out the other side.

That shape broke every runner we tried. So we built our own: alchemy-test (#848), a vitest-compatible runner built for our scale: the entire suite runs in a single bun process, plain output is designed for the agent reading it, and an interactive TUI gives humans a live view of a run with thousands of tests in flight.

Why not vitest

Vitest parallelizes across workers, and every worker builds its own module graph — threads don’t share modules any more than forks do. Everything alchemy depends on includes distilled, our generated AWS/Cloudflare SDK, which spans hundreds of service modules. Paying that import cost once is fine. Paying it per worker, hundreds of times per run, is not.

There’s no way out of that trade-off inside vitest. It can run everything in one worker (singleFork with isolate: false) — but by vitest’s own docs that “will force tests to run one after another”, and source code processed by vite “will still be reevaluated for each test” even then. Parallel files mean many workers; one worker means a sequential suite. The quadrant we needed — many files in flight, one module graph — doesn’t exist.

For us it was worse than that. Our toolchain runs on bun, and bun’s worker_threads segfaults under vitest’s tinypool at worker spawn — so we were pinned to pool: "forks", full child_process forks, the most expensive flavor of an already expensive design. And no, “just run tests on node” doesn’t fix it: the per-worker import cost is the same, and node can’t execute distilled’s TypeScript natively, so a transform layer comes back.

The module cost also made iteration slow in a way that hurt agents most. To load distilled’s TypeScript source in vitest we needed a rolldown plugin; the alternative was compiling distilled’s .ts to .js before every run. Either way there was a build step between “agent edits code” and “agent sees the test result”. Agents iterate on failing tests in tight loops — every second of compile tax is paid dozens of times per task.

Why not bun test

bun test solves both problems: it’s bun-native, so .ts loads directly with no plugin and no compile step. But it runs test files one at a time, an assumption that only works when tests are fast.

Alchemy tests are slow on purpose — they wait for real clouds. Run them sequentially and a directory that should take two minutes takes an hour. We needed dozens of files in flight at once, in one process, on bun.

One process, everything concurrent

alchemy-test imports every test file up front (imports are cheap when they happen once) and then runs files and tests concurrently on the Effect runtime — fibers, not forks. A --concurrency flag bounds how many files run at once, and tests that mutate global state can take a whole-process lock with { exclusive: true }.

The CLI is vitest-compatible — positional paths, -t filters, timeouts, retries — so the migration was a codemod.

bun run test test/Cloudflare/Workers -t "cron"

Output an agent can act on

Performance forced our hand, but once we owned the runner we could fix something that had bothered us just as long: the output.

Vitest’s default reporter prints stdout noisily: interleaved across parallel tests, indented and reflowed on top of your raw output. When a test fails, the error is somewhere in the scroll. We watched agents run a suite, tail the output to save context, and lose the one error they needed — even when prompted not to. A custom reporter can quiet some of this, but it works by intercepting console and guessing which test a log belongs to — best-effort attribution you’re consuming, not controlling.

Our tests are Effects, which means we control the runtime they execute in. Each test runs under a buffering Logger and Console, so every log line is captured and attributed to its test by construction — nothing interleaves, nothing prints as it happens. The console gets exactly one line per test:

✓ test/Cloudflare/Workers/Subdomain.test.ts > enable and disable the workers.dev subdomain (3.2s)
✓ test/Cloudflare/Workers/Rpc.test.ts > detects valid envelope (1ms)
✗ test/Cloudflare/Workers/Route.test.ts > replaces the route when the zone changes (12.4s)
  AssertionError: expected "alchemy-test-2.us/api/*" to be "alchemy-test-2.us/v2/*"
      at test/Cloudflare/Workers/Route.test.ts:87:22
  --- captured output ---
  Plan: 1 to replace
  [route] deleting
  [route] created
  --- end output ---
✓ test/Cloudflare/Workers/Workflow.test.ts > runs a workflow to completion (51.9s)

A failing test prints its error and its captured output inline, immediately, while the run continues. Passing tests stay silent — their output would be noise.

If nothing finishes for ten seconds, the runner prints what’s still running, so a hang is diagnosable from the console instead of a mystery:

⧗ [16:38:12] no tests finished in the last 10s — 2 still running:
    test/Cloudflare/Workers/Workflow.test.ts > runs a workflow to completion (48.1s)
    test/Cloudflare/Workers/CronEventSource.test.ts > cron handler fires (32.7s)

And the run ends by telling the agent exactly how to go deeper: the summary, the failures repeated in one place, and a per-run log file — with its size, so the agent knows whether to read it or search it:

Tests: 1 failed | 171 passed | 1 skipped (31 files, 89.3s)

Full log: .alchemy/log/test/2026-07-16T23-42-38-pid92186.log (1055 lines, 118 KB)

The log file has everything the console suppressed: every test’s captured output, passes included, written color-free as the run progresses. Each run gets its own timestamped file, so concurrent runs in different terminals never trample each other. The console is the summary; the log is the record. The agent reads the one line it needs and greps the file when it needs more.

Humans get a TUI

For interactive use, --tui opens a k9s-style live view: a collapsible file/test tree, type-to-filter, and retry/kill on running tests:

 alchemy-test  ✓ 159  ✗ 0  ◐ 7  · 5  │ 53.4s
 ▸ ✓ test/Cloudflare/Workers/AccountSetting.test.ts  3/3 passed
 ▾ ◐ test/Cloudflare/Workers/DurableObjectNamespace.test.ts  2 running · 11/13 passed
     ✓ getByName round-trips state (1.9s)
     ◐ websocket hibernation survives eviction (12.3s…)
 ▸ ◐ test/Cloudflare/Workers/HttpApi.test.ts  5/5 passed  — afterAll running (18.6s)…
 ▸ · test/Cloudflare/Workers/WaitUntil.test.ts  0/2 passed  — waiting for a worker slot…
 ▸ ✓ test/Cloudflare/Workers/Worker.test.ts  17/17 passed

Pressing enter on a running test live-tails its captured output — useful when a deploy is three minutes into beforeAll and you want to know what it’s doing.

The hotkeys are vim-flavored: j/k and ctrl-d/ctrl-u to move, / for live type-to-filter, p/f/n/s to toggle passing, failing, pending, and skipped tests in and out of view. r retries the selected test or file, R retries everything that failed, x kills a running test, and y copies a failure’s error and captured output to the clipboard — handy for pasting straight into an agent chat.

Owning the runner

The whole thing was easy to build — a test harness, a scheduler, and two reporters over an event stream, in a codebase that already runs everything on Effect. That’s the part worth underlining: it was cheap to make because we only target Effect, and owning it means the feedback loop is ours to tune. When we notice agents misreading output, we change the output. No plugin API in between.

Where to go next

alchemy-test on GitHub
The PR
Looping the Generation of IaC and SDKs — the agent fleet this runner feeds

2.0.0-beta.64 - Full AWS Coverage

Wed, 22 Jul 2026 06:00:00 GMT

beta.64 is the AWS release. Alchemy now covers 206 AWS services, with every resource and binding live-tested against the real cloud. It also adds first-class containers on ECS and EKS, Durable Lambda Functions, and Helm charts on EKS.

“100%” AWS coverage

One PR (#797) took the AWS provider from a handful of services to all of them, using the same resource factory that built out the Cloudflare provider. Fleets of agents cataloged all 428 generated SDK modules, then implemented and live-tested them in waves: serverless first, then ECS/Fargate, EKS, EC2, and the long tail. Everything left over is documented as out of scope (deprecated APIs, data-only endpoints, billing objects). The result:

206 AWS services with 683 resources and 2,842 bindings (plus event sources and sinks), from DynamoDB and S3 all the way out to MediaLive, IoT SiteWise, Bedrock, and SageMaker.
2,692 live tests green by default against real AWS. 375 more are gated behind env vars because they are slow to provision, expensive, or need special account entitlements.
Zero-orphan guarantee: each round wiped the test account clean, ran the full suite, then audited the account for leftover resources. The loop ran until two consecutive rounds left nothing behind. A passing test that leaks a cloud resource is a provider bug, and the loop caught dozens of them.

Bindings are 1:1 with IAM actions. Each binding your code uses becomes a least-privilege policy statement on exactly the resources it touches, whether the code runs on Lambda, ECS, or EKS:

const api = yield* AWS.ECS.Service(
  "Api",
  { cluster, main: import.meta.url, port: 3000, desiredCount: 2 },
  Effect.gen(function* () {
    // init: each binding grants one IAM action on one ARN
    const getItem = yield* AWS.DynamoDB.GetItem(table);
    const send = yield* AWS.SQS.SendMessage(queue);

    return {
      fetch: Effect.gen(function* () {
        const item = yield* getItem({ Key: { pk: { S: "user#1" } } });
        yield* send({ MessageBody: JSON.stringify(item.Item) });
        return yield* HttpServerResponse.json({ ok: true });
      }),
    };
  }).pipe(
    Effect.provide([AWS.DynamoDB.GetItemHttp, AWS.SQS.SendMessageHttp]),
  ),
);

You never write an IAM policy, and every error is typed — the compiler tells you what can fail and you handle it like any other Effect error. See Bindings for how it works.

All of it is documented in the API reference, with usage examples on every resource and binding.

ECS: Tasks and Services

ECS gets the full platform treatment (#867): Task for run-to-completion work and Service for long-running servers. Both are authored the same three ways as Workers and Lambda: an external image, an inline effect, or a tagged class.

Every container platform takes one image source, flat on props:

{ main }                                   // bundle this Effect program
{ main, image }                            // bundle FROM your base image
{ context, dockerfile? }                   // build your own Dockerfile
{ dockerfile: Dockerfile.inline`...` }     // inline Dockerfile content
{ image }                                  // registry ref, mirrored into ECR

The simplest Service runs a registry image behind a provisioned Application Load Balancer:

const cluster = yield* AWS.ECS.Cluster("AppCluster", {});

const nginx = yield* AWS.ECS.Service("Edge", {
  cluster,
  image: "public.ecr.aws/nginx/nginx:1.27",
  port: 80,
  desiredCount: 2,
  loadBalancer: true,
});

return { url: nginx.url }; // http://<alb-dns-name>

A Service can also run an Effect program. The impl returns { fetch }, and bindings grant IAM to the task role:

const api = yield* AWS.ECS.Service(
  "Api",
  { cluster, main: import.meta.url, port: 3000, desiredCount: 2 },
  Effect.gen(function* () {
    const putItem = yield* AWS.DynamoDB.PutItem(table);
    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        const order = (yield* request.json) as { orderId: string };
        yield* putItem({ Item: { pk: { S: order.orderId } } });
        return yield* HttpServerResponse.json({ ok: true });
      }),
    };
  }).pipe(Effect.provide(AWS.DynamoDB.PutItemHttp)),
);

A one-shot Task is the run-to-completion counterpart: the impl returns { run }, and the container exits when the effect completes. Here it composes main with Dockerfile.inline — the inline content builds the environment, and the bundled program is layered on top:

import { Dockerfile } from "alchemy/Docker";

const thumbnailer = yield* AWS.ECS.Task(
  "Thumbnailer",
  {
    main: import.meta.url,
    dockerfile: Dockerfile.inline`
      FROM oven/bun:1
      RUN apt-get update && apt-get install -y ffmpeg
    `,
    cpu: 1024,
    memory: 2048,
  },
  Effect.gen(function* () {
    const getObject = yield* AWS.S3.GetObject(bucket);
    return {
      run: Effect.gen(function* () {
        // pull the video from S3, shell out to ffmpeg, then exit
      }),
    };
  }).pipe(Effect.provide(AWS.S3.GetObjectHttp)),
);

Tasks are launched from other compute with the RunTask binding, which grants ecs:RunTask and iam:PassRole automatically — here a Lambda function launches a task per request:

const api = yield* AWS.Lambda.Function(
  "Api",
  { main: import.meta.url, url: true },
  Effect.gen(function* () {
    const runTask = yield* AWS.ECS.RunTask(cluster, thumbnailer);

    return {
      fetch: Effect.gen(function* () {
        const response = yield* runTask({
          launchType: "FARGATE",
          networkConfiguration: {
            awsvpcConfiguration: { subnets: [subnetId] },
          },
        });
        return yield* HttpServerResponse.json({
          taskArn: response.tasks?.[0]?.taskArn,
        });
      }),
    };
  }),
);

Or run a task on a schedule with AWS.ECS.every, which provisions the EventBridge rule and invoke role:

yield* AWS.ECS.every("NightlyJob", "cron(0 3 * * ? *)", {
  cluster,
  task: nightlyTask,
  subnets: [privateSubnet.subnetId],
});

Services go well past loadBalancer: true: multiple services can share one load balancer, and props cover custom domains, auto-scaling on CPU or request count, Fargate Spot capacity, EFS volumes, secrets, and health checks. Docs: ECS.

EKS: Deployments, Jobs, Manifests, and Helm

Kubernetes workloads live in the same TypeScript program as the cluster itself — no YAML, no kubectl. compute: "auto" stands up an EKS Auto Mode cluster where AWS manages the nodes:

const network = yield* AWS.EC2.Network("Network", {
  cidrBlock: "10.42.0.0/16",
  availabilityZones: 2,
  nat: "single",
});

const cluster = yield* AWS.EKS.Cluster("Cluster", {
  compute: "auto",
  resourcesVpcConfig: { subnetIds: network.privateSubnetIds },
});

const api = yield* AWS.EKS.Deployment(
  "Api",
  { cluster, main: import.meta.url, port: 3000, replicas: 2, serviceType: "LoadBalancer" },
  Effect.gen(function* () {
    const putItem = yield* AWS.DynamoDB.PutItem(table); // → pod-identity IAM
    return { fetch: Effect.gen(function* () { /* ... */ }) };
  }).pipe(Effect.provide(AWS.DynamoDB.PutItemHttp)),
);

Deployment synthesizes a Kubernetes Deployment, Service, and ServiceAccount, with bindings landing as pod-identity IAM.

Job is the run-to-completion counterpart — same image sources, and the impl returns { run }:

const seed = yield* AWS.EKS.Job(
  "SeedData",
  { cluster, main: import.meta.url },
  Effect.gen(function* () {
    const putItem = yield* AWS.DynamoDB.PutItem(table);
    return {
      run: Effect.gen(function* () {
        // runs to completion, then the pod exits
      }),
    };
  }).pipe(Effect.provide(AWS.DynamoDB.PutItemHttp)),
);

Add schedule and a Job becomes a Kubernetes CronJob — here in the external form, running a pre-built image:

const nightly = yield* AWS.EKS.Job("NightlyBackfill", {
  cluster,
  image: "ghcr.io/acme/backfill:v3",
  schedule: "0 3 * * *",
});

Manifest applies any raw Kubernetes object via server-side apply, CRDs included — the manifest is a literal object, exactly what you’d write in YAML. No kubeconfig required:

const sts = yield* AWS.EKS.Manifest("Cache", {
  cluster,
  manifest: {
    apiVersion: "apps/v1",
    kind: "StatefulSet",
    metadata: { name: "cache", namespace: "apps" },
    spec: { replicas: 3 /* ... */ },
  },
});

HelmChart installs Helm charts (#891). It renders the chart locally with helm template and applies the objects to the cluster, so Alchemy owns the lifecycle: drift is corrected on every deploy, dropped objects are pruned, and destroy deletes everything:

const ingress = yield* AWS.EKS.HelmChart("IngressNginx", {
  cluster,
  chart: "ingress-nginx",
  repo: "https://kubernetes.github.io/ingress-nginx",
  version: "4.11.2",
  namespace: "ingress-nginx",
  createNamespace: true,
  values: { controller: { replicaCount: 2 } },
});

Docs: EKS.

Durable Lambda Functions

AWS.Lambda.DurableFunction writes long-running orchestrations as plain code, built on AWS Lambda’s durable execution model (#797). It is a Lambda Function, with the same props and bindings, but its body is checkpointed. Durable.step records each result so it isn’t re-run on replay. Durable.sleep suspends the execution entirely; Lambda re-invokes the function to resume it. And Durable.waitForCallback pauses on an external signal for up to a year:

export class OrderFlow extends AWS.Lambda.DurableFunction<OrderFlow>()(
  "OrderFlow",
) {}

export default OrderFlow.make(
  { main: import.meta.url, executionTimeout: "1 hour" },
  Effect.gen(function* () {
    // init: resolve typed binding clients (IAM lands on this role)
    const putItem = yield* AWS.DynamoDB.PutItem(table);

    return Effect.fn(function* (input: { orderId: string }) {
      const reserved = yield* AWS.Lambda.Durable.step(
        "reserve",
        putItem({ Item: { pk: { S: input.orderId } } }).pipe(Effect.orDie),
        { retry: { limit: 3, delay: "5 seconds" } },
      );
      yield* AWS.Lambda.Durable.sleep("cooldown", "10 minutes");
      return { orderId: input.orderId, reserved };
    });
  }).pipe(Effect.provide(AWS.DynamoDB.PutItemHttp)),
);

Replay requires the body to be deterministic, and the type system enforces it: the run body has no access to cloud credentials, so the only way to do I/O is through a binding client resolved in init and called inside a Durable.step.

yield* OrderFlow returns a typed handle to start, inspect, and stop executions, and to complete callbacks from the outside:

const orders = yield* OrderFlow;
const ref = yield* orders.start({
  name: "order-123", // idempotent start
  params: { orderId: "123" },
});
const execution = yield* orders.get(ref.executionArn!);
// execution.Status: "RUNNING" | "SUCCEEDED" | "FAILED" | ...

The vocabulary mirrors Cloudflare Workflows, so orchestration code reads the same on both clouds. Reference: DurableFunction.

Effect SQL and Drizzle for D1

Drizzle now works end to end on Cloudflare D1 (#887), mirroring the Neon and PlanetScale integrations. At deploy time, Drizzle.Schema diffs your schema module and writes pending migration SQL, and passing schema.out as the database’s migrationsDir makes the database apply it — generate first, apply second, in one deploy:

src/db.ts

export const Database = Effect.gen(function* () {
  const schema = yield* Drizzle.Schema("app-schema", {
    schema: "./src/schema.ts",
    out: "./migrations",
    dialect: "sqlite",
  });

  return yield* Cloudflare.D1.Database("app-db", {
    migrationsDir: schema.out,
  });
});

At runtime, a Worker binds the database with Cloudflare.D1.QueryDatabase and hands the client to Drizzle.D1. Every query is an Effect with SqlError in the typed error channel:

src/api.ts

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.url },
  Effect.gen(function* () {
    const database = yield* Database;
    const d1 = yield* Cloudflare.D1.QueryDatabase(database);
    const db = yield* Drizzle.D1(d1, { relations });

    return {
      fetch: Effect.gen(function* () {
        const users = yield* db.query.Users.findMany({
          with: { posts: true },
        });
        return yield* HttpServerResponse.json({ users });
      }),
    };
  }).pipe(Effect.provide(Cloudflare.D1.QueryDatabaseBinding)),
) {}

The low-level effect-sql clients also get one home: the new alchemy/SQL/* subpaths, with a raw tagged-template client for each Drizzle integration. It binds inside a Worker the same way:

import * as SQL from "alchemy/SQL/D1";

Effect.gen(function* () {
  const d1 = yield* Cloudflare.D1.QueryDatabase(database);
  const sql = yield* SQL.D1(d1);

  return {
    fetch: Effect.gen(function* () {
      const rows = yield* sql`SELECT id, name FROM users`;
      return yield* HttpServerResponse.json({ rows });
    }),
  };
}).pipe(Effect.provide(Cloudflare.D1.QueryDatabaseBinding));

All clients share the same lifecycle: nothing connects at plan or deploy time, the client is built lazily on the first query, and it’s torn down when the request settles. The website’s new SQL hub collects effect-sql, Drizzle, and migrations in one place (#903).

Also in this release

Python Workers (#861) — point main at a .py file and Cloudflare.Worker deploys a Python Worker, with dependencies vendored from pyproject.toml via uv. Docs: Python Workers.
Workers AI binding (#850) — Cloudflare.Workers.AI runs models on Cloudflare’s GPU fleet from a Worker.
Durable Objects pin to a region (#851) with locationHint, and DO classes transfer between workers declaratively (#803).
GitHub Enterprise + deployment environments (#845) — alchemy login accepts an enterprise host (GHES and data residency), and the new GitHub.Environment resource manages deployment environments.
Effect-native test runner (#848) — the whole alchemy test suite now runs in a single bun process on alchemy-test, with output designed for agents. Full story: A Test Runner Built for Agents. The live suite converged to green: 4,458 passed (#916).
RDS safety: MasterUserPassword is fingerprint-guarded so it’s no longer re-sent on every reconcile (#876), and skipFinalSnapshot: false takes a final snapshot on deliberate teardown (#877).
AWS_REGION overrides the SSO profile’s stored region (#895).
Engine reliability — destroy aggregates GC failures and refuses to silently orphan zombie rows (#899, #862), --force refreshes stale bound attributes (#900), binding diffs are stable across runs (#898), unresolved Outputs are never persisted into state (#835), and truncated physical names stay unique (#868).
Actions get local bindings and Output accessors (#807), and alchemy login works without an alchemy.run.ts (#842).
Migrating from v1 now adopts existing resources instead of destroying and recreating them (#819) — see Migrating from v1.
Cloudflare fixes: queue-consumer wiring surviving mid-start reconciles (#917), asset-upload retries (#914), wasm in alchemy dev (#881), and Effect-valued env bindings converging in plans (#890).
The website now lives at alchemy.run (#806), builds 8x faster on Astro 7 (#873), and the Layers, Bindings, and Runtime concept pages are rewritten.

Where to go next

AWS — the provider hub: setup, tutorial, and guides
ECS and EKS
Choosing a runtime
SQL
Bindings
CHANGELOG
Compare v2.0.0-beta.63 → v2.0.0-beta.64

2.0.0-beta.63 - Durable Object Transfers & Action Bindings

Fri, 17 Jul 2026 06:00:00 GMT

beta.63 moves Durable Object classes between Workers with their data intact, lets Actions bind resources and read Outputs with your CLI credentials, and makes alchemy login work from any folder. The website now lives at alchemy.run.

Move a Durable Object to another Worker

A Durable Object class can now move between Workers with its data intact — same instances, same storage — via Cloudflare’s transferred_classes migration (#803).

Moves are always declared. A class that disappears from one Worker and appears on another is ambiguous between “transfer the data” and “delete it, start fresh”, so Alchemy never guesses. The class states where it came from:

export class Counter extends Cloudflare.DurableObject<
  Counter,
  {
    increment: () => Effect.Effect<number, never, RuntimeContext>;
    get: () => Effect.Effect<number, never, RuntimeContext>;
  }
>()("Counter") {}
>()("Counter", { transferredFrom: "WorkerA" }) {}

Whichever Worker hosts Counter next transfers the namespace from WorkerA. transferredFrom accepts a Worker logical id, a physical script name (for cross-stack moves), the Worker class itself, or a thunk for import cycles.

The declaration is a host history: after a second move you write transferredFrom: ["WorkerA", "WorkerB"], and the namespace transfers from whichever listed host currently holds it — so a stage that lagged behind or skipped a release still converges. Once a transfer completes, the declaration is inert and safe to keep in code forever.

If you move a host without declaring it, the deploy fails before any upload with the typed DurableObjectTransferRequired error, naming the exact declaration to add. Durable Object data is never silently destroyed or forked.

Docs: Bind to another Worker’s Durable Object.

Bind resources inside Actions

Actions run arbitrary Effects during deploy — seed a database, ping Slack, invalidate a cache. They can now bind resources the same way a Worker does, and read resource Outputs (#807):

const Seed = Alchemy.Action(
  "Seed",
  Effect.gen(function* () {
    const db = yield* Cloudflare.D1.QueryDatabase(database);
    const databaseId = yield* database.databaseId;

    return Effect.fn(function* () {
      yield* db.exec("CREATE TABLE IF NOT EXISTS users (id TEXT, name TEXT)");
      return { databaseId: yield* databaseId };
    });
  }).pipe(Effect.provide(Cloudflare.D1.QueryDatabaseLocal)),
);

The new *Local layers make this work. They’re a third binding variant alongside *Binding (native Worker binding) and *Http (scoped API token): a *Local layer authenticates with your current CLI credentials and returns the same typed client, so an Action running on your machine or in CI talks to the same data plane your Worker would. Every Cloudflare capability with an HTTP data plane has one — D1, KV, R2, Queues, DNS, Vectorize, Tunnel, AI Search, Browser Rendering, and more.

Reading yield* database.databaseId inside an Action also records a dependency edge, so the Action waits for the database to exist before it runs.

`alchemy login` works anywhere

alchemy login no longer requires an alchemy.run.ts (#842). With no entrypoint in sight, it offers every built-in auth provider and configures the ones you pick, so you can set up or refresh credentials from any folder:

$ cd /some/empty/dir && alchemy login
No alchemy.run.ts found — using Alchemy's built-in providers.
◆  Select providers to log in with
│  ◻ AWS
│  ◻ Axiom
│  ◻ Cloudflare
│  ◼ GitHub (configured)
│  ◻ Neon
│  ◻ Planetscale

Already-configured providers are pre-selected and labeled. In CI the prompt is skipped and all built-ins are configured non-interactively. With an alchemy.run.ts present, behavior is unchanged.

Docs: alchemy login.

The website moved to alchemy.run

The v2 site now serves from the apex domain, and v2.alchemy.run 301s to it at the edge (#806). The redirect is itself deployed by Alchemy — a Cloudflare.Ruleset on the adopted zone:

yield* Cloudflare.Ruleset.Ruleset("V2Redirect", {
  zone,
  phase: "http_request_dynamic_redirect",
  rules: [{
    expression: 'http.host eq "v2.alchemy.run"',
    action: "redirect",
    actionParameters: {
      fromValue: {
        targetUrl: { expression: 'concat("https://alchemy.run", http.request.uri.path)' },
        preserveQueryString: true,
        statusCode: 301,
      },
    },
  }],
});

A new test runner

This release also lands alchemy-test, the Effect-native test runner that executes our 4,000+ live-cloud test suite in a single bun process (#848). It got its own post: A Test Runner for Agents and Humans.

Also in this release

Durable Object metadata packs into a single script tag (#824) — one tag per DO binding blew Cloudflare’s 10-tag-per-Worker limit at 7+ DOs; all mappings now fit in one tag.
Vite-based Workers hash sibling workspace packages (#822) — editing only a sibling package used to skip the deploy and serve stale code.
Alchemy’s Vite plugin no longer double-registers (#833) — apps that also build standalone keep the plugin in their vite.config.ts; Alchemy signals its own injection via ALCHEMY_CLOUDFLARE_VITE_INJECTED. Thanks Alex!
MySQL replicas reconcile in place (#825) — changing replicas on a PlanetScale MySQL database resizes the keyspace instead of replacing the database.
Unresolved Outputs never persist in state (#835) — an interrupted create could snapshot live Output proxies into state and poison later reads.
Auto-bound Config resolves in request handlers (#829) — re-yielding a Config inside a handler decoded the secret marker JSON instead of the value.
proxyChain values pass Effect.isEffect (#827) — chained Drizzle clients now work with predicate-dispatched operators like Effect.catchTag. Thanks Julian Archila!

Where to go next

2.0.0-beta.62 - Build-Once Workers & GitHub Action

Tue, 14 Jul 2026 06:00:00 GMT

beta.62 makes Workers build their layer stack once per isolate instead of on every request. It also adds an official GitHub Action, PlanetScale OAuth login, a custom Worker entry for Vite websites, and a batch of alchemy dev fixes.

Layers build once per isolate

The Worker bridge used to rebuild your entire layer stack on every request. Every Layer.effect, config decode, and client constructor re-ran per event. Now layers build once, on the first event. Every later event reuses them (#774):

Effect.gen(function* () {
  // init: runs once per isolate. beta.61 ran this on every request.
  const client = yield* HttpClient.HttpClient;
  const response = yield* client.get("https://example.com/config.json");
  const config = yield* response.json;

  return {
    fetch: Effect.gen(function* () {
      // handler: runs per event, reusing the cached config
      return yield* HttpServerResponse.json(config);
    }),
  };
})

Init cost is paid once at cold start. After that, every request goes straight to the handler. Durable Objects get the same win: one layer build shared across activations.

Sharing one build across events needs cross-request async. One event awaits a layer build that another event started. workerd normally forbids this: a promise created in one request context can’t be resolved from another. So alchemy enables the handle_cross_request_promise_resolution compatibility flag automatically for Workers with a compatibility date before 2024-10-14. Later dates enable it by default. Each awaiting event also pins the in-flight build with ctx.waitUntil, so workerd doesn’t drop the continuation when the original request ends. Opting out with no_handle_cross_request_promise_resolution is a deploy-time error.

There is one migration. Anything disposable moves out of init and into the handler. The handler’s per-event Scope runs its finalizers after the response:

// ❌ init: workerd has no isolate teardown, so this finalizer never runs
const pool = yield* acquirePool();

// ✅ handler: acquired per event, released when the event settles
fetch: Effect.gen(function* () {
  const conn = yield* acquireConn();
  // ...
}),

You can still declare the resource in init and use it at runtime. An Effect is only a description, so declaring one in init acquires nothing:

import * as PgClient from "@effect/sql-pg/PgClient";

Effect.gen(function* () {
  // init: declare the client. Nothing connects yet.
  const client = PgClient.make({ url });

  return {
    fetch: Effect.gen(function* () {
      // handler: connects on this event's Scope
      const sql = yield* client;
      const rows = yield* sql`select * from users`;
      return yield* HttpServerResponse.json(rows);
    }),
  };
})

The pool is acquired on the event’s Scope and released when the event settles.

proxyChain removes the extra yield*. It wraps the deferred client in a chainable handle. Yielding a query resolves the client on the current event’s Scope, then replays the chain against it:

import { proxyChain } from "alchemy/Util/proxy-chain";

Effect.gen(function* () {
  // init: a chainable handle over the deferred client
  const sql = proxyChain(PgClient.make({ url }));

  return {
    fetch: Effect.gen(function* () {
      const rows = yield* sql`select * from users`;
      return yield* HttpServerResponse.json(rows);
    }),
  };
})

Drizzle.postgres is this pattern plus Effect.cached to memoize the acquisition per event. The first query opens the pool, every later query in the same event reuses it, and the pool closes when the event settles:

Effect.gen(function* () {
  // init: declares the handle. No connection is made.
  const db = yield* Drizzle.postgres(hyperdrive.connectionString);

  return {
    fetch: Effect.gen(function* () {
      // first query builds the pool, memoized on this event's Scope
      const rows = yield* db.select().from(users);
      return yield* HttpServerResponse.json(rows);
    }),
  };
})

See Postgres.ts for the full implementation. It is also why Drizzle.postgres now works inside Durable Object methods.

Lambda gets a real shutdown from the same change. The generated entry registers an internal extension, so the instance receives SIGTERM and a ~500 ms window to run init-level finalizers.

Docs: Instance scope vs request scope.

Deploy from GitHub Actions

One step resolves the Alchemy lifecycle from the GitHub event. Opening a PR deploys a staging-{pr} stage, closing it destroys the stage, and pushing to main deploys prod (#699). Thanks Harry Solovay!

- uses: alchemy-run/alchemy@main

A new GitHub.GitHubEnv config exposes the Actions metadata to your stack. It resolves to undefined outside CI, so the same stack runs unchanged locally:

import * as GitHub from "alchemy/GitHub";

const github = yield* GitHub.GitHubEnv;

if (github?.pr) {
  yield* GitHub.Comment("preview-comment", {
    owner: github.owner,
    repository: github.repository,
    issueNumber: github.pr,
    body: `Preview for ${github.sha}`,
  });
}

Docs: CI.

alchemy login now offers browser-based OAuth for PlanetScale, the same flow as Cloudflare (#467):

alchemy login
# authorize in the browser → token stored, refreshed proactively

Env vars and service tokens keep working. Both providers now land on shared /auth/success and /auth/error pages (#780).

Custom Worker entry for Vite websites

Cloudflare.Website.Vite accepts a main prop that forwards a custom Worker entry to the Vite plugin, in dev and deploy (#779). Thanks Daniel Gangl!

// worker/index.ts: export more than the framework's fetch handler
import handler from "virtual:react-router/unstable_rsc/server";
export { MyDurableObject } from "./my-durable-object";
export default handler;

yield* Cloudflare.Website.Vite("Site", {
  rootDir: "./site",
  main: "./site/worker/index.ts",
});

React Router / RSC setups need this. The framework plugin owns the entry, so the old rollupOptions.input workaround doesn’t apply.

`alchemy dev` reliability

Hot reload no longer kills service bindings (#812) — reloading a worker used to delete its replacement’s registration, so RPC calls failed with Worker not found after every backend change. Thanks utopy!
Container environment variables work in dev (#785).
Dev container images persist across restarts (#727).
Remote images and external Dockerfiles work in LocalContainerProvider (#790).
The provider RPC session is cached and reused (#789).
Dev-URL detection favors localhost/IP URLs (#787).

Also in this release

plan no longer claims ownership of adopted resources (#794) — a read-only dry run could silently adopt an unowned cloud resource, and a later unrelated deploy would orphan-delete it. Thanks Daniel Gangl!
State-store credentials are bound to the account (#760) — after alchemy login --configure switched accounts, state reads/writes silently kept going to the old account’s store.
Provider handlers receive the resource fqn (#783) — the fully-qualified name joins id in every lifecycle handler, so custom providers can stamp collision-free ownership metadata. Thanks Daniel Gangl!
Cron handlers keep their requirements (#791) — services required by a Workers.cron handler surface on the Worker’s init effect again. Thanks Jack Bisceglia!
Vite build output is read after the build resolves (#795) — fixes a bundling race in Website deploys.
Container healthcheck durations are unit-suffixed (#778) — Docker rejects bare numbers. Thanks Matthew Aylward!
alchemy state clear respects ALCHEMY_PROFILE (ba705).
TypeScript 7 (stable) toolchain (#804).
New guides: Worker Loader, Rate limiting, and Workers Cache (#805), plus a TanStack + Atom RPC + Drizzle example (#634).

Where to go next

2.0.0-beta.61 - Workers Cache, Routes & Sync

Wed, 08 Jul 2026 06:00:00 GMT

beta.61 adds Workers Cache with an Effect-native ExecutionContext, Wrangler-style zone routes, alchemy sync for repairing out-of-band drift, a much fuller Workflows API (retries, rollback, events), resource type aliases that heal the beta.59 renames, and a long list of reliability fixes.

Workers Cache

Workers Cache — Cloudflare’s regionally tiered cache in front of Worker entrypoints — lands as both a binding and a prop (#752). Effect-native Workers enable it with Cloudflare.cache(), which also returns the typed purge client:

Effect.gen(function* () {
  // init: enables Workers Cache on this Worker at deploy time
  const { purge } = yield* Cloudflare.cache({ crossVersionCache: true });

  return {
    fetch: Effect.gen(function* () {
      const request = yield* HttpServerRequest;
      if (request.url.startsWith("/invalidate")) {
        yield* purge({ tags: ["products"] }); // typed CachePurgeError
        return HttpServerResponse.text("purged");
      }
      return HttpServerResponse.text("hello", {
        headers: {
          "Cache-Control": "public, max-age=300, stale-while-revalidate=3600",
          "Cache-Tag": "products",
        },
      });
    }),
  };
})

Async Workers use the prop:

const worker = yield* Cloudflare.Worker("Api", {
  main: "./src/api.ts",
  cache: { enabled: true, crossVersionCache: true },
});

Effect-native `ExecutionContext`

WorkerExecutionContext used to hand you the raw cf.ExecutionContext. It’s now an Effect wrapper — and like DurableObjectState, it can be yielded from the Worker’s init closure (or any Layer); its methods resolve the live per-event context:

Effect.gen(function* () {
  const exec = yield* Cloudflare.WorkerExecutionContext; // init

  return {
    fetch: Effect.gen(function* () {
      // respond now, finish work in the background
      yield* exec.waitUntil(journal.record(entry).pipe(Effect.delay("5 seconds")));
      return HttpServerResponse.text("ok");
    }),
  };
})

Migrating is mechanical — ctx.waitUntil(promise) becomes yield* exec.waitUntil(effect).

Zone Routes on Workers

Cloudflare.Worker accepts Wrangler-style zone routes via a new routes prop (#438). Thanks utopy!

yield* Cloudflare.Worker("Api", {
  main: import.meta.filename,
  routes: [
    { pattern: "api.example.com/*", zoneName: "example.com" },
    { pattern: "example.com/api/*", zoneId: "<YOUR_ZONE_ID>" },
  ],
});

Each entry takes zoneName / zoneId (the Wrangler equivalents) or a zone reference — and when the zone is omitted, it’s inferred from the pattern hostname. Routes are reconciled on deploy and cleaned up on destroy.

`alchemy sync`

Cloud state drifts: someone edits a resource in the dashboard, a bucket gets deleted, tags get mangled. alchemy sync converges it back to the last-deployed state — without re-running your stack program (#766):

alchemy sync ./alchemy.run.ts --stage prod            # detect + repair
alchemy sync ./alchemy.run.ts --stage prod --dry-run  # detect only

Per resource it runs observe → compare → converge: read observes the live cloud state, a deep-compare against the persisted attributes decides unchanged vs drifted, and drift is repaired by reconcile with the persisted props as the desired state. A resource deleted out-of-band is recreated under the same instance id, so deterministic physical names regenerate identically. Resources sync concurrently, and failures are aggregated after every resource has been attempted.

Workflows: retries, rollback, and events

The Effect-native Workflow wrapper now covers the full Workers API surface, 1:1 with the native binding (#611). Thanks Gerben Mulder!

create takes the native options object — the breaking change above — which also unlocks id and retention:

const instance = yield* workflow.create({ orderId: "abc" });
const instance = yield* workflow.create({
  id: "order-abc",
  params: { orderId: "abc" },
  retention: { successRetention: "1 day", errorRetention: "7 days" },
});

task gains retries, timeout, and rollback, and WorkflowStepContext exposes the current attempt:

const result = yield* Cloudflare.Workflows.task(
  "call-api",
  Effect.gen(function* () {
    const context = yield* Cloudflare.Workflows.WorkflowStepContext;
    return { attempt: context.attempt };
  }),
  {
    retries: { limit: 3, delay: "5 seconds", backoff: "linear" },
    rollback: ({ output }) => (output ? cleanup(output.id) : Effect.void),
  },
);

waitForEvent parks the instance until a matching sendEvent:

// inside the workflow
const approval = yield* Cloudflare.Workflows.waitForEvent<{ approved: boolean }>(
  "approval",
  { type: "approval", timeout: "1 day" },
);

// from outside
yield* instance.sendEvent({ type: "approval", payload: { approved: true } });

createBatch, restart, rollback status, and extended event metadata round out the surface. Docs: Workflows.

Resource type aliases

Renaming a resource’s type string used to strand state persisted under the old name — provider lookup died on the legacy type. Resources now declare their former names (#765):

export const Queue = Resource<Queue>("Cloudflare.Queues.Queue", {
  aliases: ["Cloudflare.Queue"],
});

Plan, apply, destroy, logs, and tail all resolve providers through aliases, and a noop deploy migrates state rows to the canonical name. All 74 resources renamed in the beta.59 namespace alignment are annotated with their pre-rename alias — so state written by beta.58 or earlier now deploys, destroys, and replaces cleanly instead of erroring on the legacy type.

AI Gateway BYOK: `AI.ProviderKey`

A bring-your-own-key provider on an AI Gateway needs two coordinated resources — a Secrets Store Secret with an exact {gatewayId}_{providerSlug}_{alias} name, and a GatewayProvider that references it. Cloudflare.AI.ProviderKey owns that contract as one resource (#586). Thanks Alex!

const { secret, gatewayProvider } = yield* Cloudflare.AI.ProviderKey("OpenAiKey", {
  store,
  gatewayId: gateway.gatewayId,
  providerSlug: "openai",
  value: yield* Config.redacted("OPENAI_API_KEY"),
});

Docs: AI Gateway.

Lambda async invocation config

Lambda’s asynchronous invocation settings — retries, event age, success/failure destinations — land as an eventInvokeConfig prop on Function and Alias (#627). Thanks José Netto!

const fn = yield* AWS.Lambda.Function("AsyncFn", {
  main: "./src/handler.ts",
  eventInvokeConfig: {
    maximumRetryAttempts: 0,
    maximumEventAgeInSeconds: 60,
    destinationConfig: {
      OnFailure: { Destination: queue.queueArn },
    },
  },
});

R2 Bucket `cors`

The cors prop that Cloudflare.R2.Bucket had in v1 is restored (#771) — public buckets serving browser range-reads (e.g. PMTiles) declare CORS in the stack again instead of out-of-band:

const bucket = yield* Cloudflare.R2.Bucket("Tiles", {
  domains: [{ name: "tiles.example.com" }],
  cors: [
    {
      allowedMethods: ["GET", "HEAD"],
      allowedOrigins: ["https://map.example.com"],
      allowedHeaders: ["range"],
      exposeHeaders: ["etag", "content-range"],
      maxAgeSeconds: 3600,
    },
  ],
});

Rules use the flat S3-style shape and reconcile like lifecycleRules — observed vs desired, so out-of-band drift and adoption converge correctly.

Also in this release

Worker metadata-only changes now deploy (#747) — compatibility flags/date, observability, placement, limits, and binding changes are folded into the update diff via a metadata hash; previously they planned as noops and silently never shipped. The first deploy after upgrading plans a one-time update per Worker to backfill the hash. Thanks Alex!
Wedged stacks recover (#767, #770) — a deploy interrupted mid-create used to persist a state row whose Output-valued props can’t round-trip, crashing every subsequent plan/deploy/destroy. Every provider’s read/diff is audited so the engine re-drives the create and reconcile converges on the half-created resource.
Script uploads retry every binding-target-not-found error (#753) — KV, R2, D1, Queues, DO classes, Hyperdrive, Vectorize, and more, covering Cloudflare’s deploy-time propagation lag.
Resource.ref values bind natively in Worker env (#756) — a ref passed as an env binding used to degrade to a plain JSON env var and break at runtime; refs now classify exactly like locally-declared resources.
Multiple queue consumers on one Worker (#466) — event dispatch runs every listener for an event type instead of letting the first queue subscription swallow the rest. Thanks Leonardo E. Dominguez!
State-store errors are actionable (#737) — 30 days of production traces triaged; empty StateStoreError: messages, opaque decode errors, and JSON-parse crashes now surface real messages (an unauthorized store tells you to run alchemy login).
The test suite passes on Windows (#735) — including two real product fixes: Drizzle.Schema passed OS-native paths to drizzle-kit (backslashes are glob escapes), and Bundle.PurePlugin could be hijacked by a stray package.json above node_modules.
Drizzle query chains are real Effects (#750) — db.select()... chains now expose the full Effect protocol, so they compose with Effect.all and friends instead of spinning the run loop.
PlanetScale inherited roles compare by membership (#761) — API-returned ordering no longer forces a PostgresRole replacement. Thanks Gerben Mulder!
globalOutbound: null is preserved in WorkerLoader (#746) — the documented “block all outbound network access” signal no longer silently coerces to default access. Thanks Alex!
Binding-hosted DO classes join the precreate stub (#764) — fixes Worker did not expose Durable Object namespace on fresh deploys of worker↔container cycles. Thanks Daniel Gangl!
alchemy dev no longer prints bun’s benign tsconfig fd warning (#768).

Where to go next

2.0.0-beta.60 - Docker, MicroVMs & RSC

Mon, 06 Jul 2026 22:00:00 GMT

beta.60 is a big one: a new Docker provider, AWS Lambda MicroVMs, Workers for Platforms, React Server Components on the Vite pipeline, class-based Workflows on async Workers, Cloudflare Containers that start fast and stay up, and a ground-up overhaul of the docs. No breaking changes this release.

Docker provider

alchemy/Docker brings Image, RemoteImage, Container, Volume, and Network as Stack resources (#649). They drive the docker CLI’s active context — Docker Desktop, a remote/SSH context, a CI daemon — and live in the same Stack as your cloud resources. Thanks Austin!

const image = yield* Docker.RemoteImage("postgres-image", {
  name: "postgres",
  tag: "18-alpine",
});
const network = yield* Docker.Network("app-network");
const data = yield* Docker.Volume("postgres-data");

const postgres = yield* Docker.Container("postgres", {
  image,
  environment: { POSTGRES_PASSWORD: password }, // Redacted-safe
  ports: [{ external: 15432, internal: 5432 }],
  volumes: [{ hostPath: data.name, containerPath: "/var/lib/postgresql/data" }],
  networks: [{ name: network.name, aliases: ["postgres"] }],
  start: true,
});

Secrets are passed via process env (never on the CLI), pulled tags are pinned so re-deploys are no-ops, and containers created outside alchemy follow the standard adoption rules. See the new Docker hub and the local services guide.

AWS Lambda MicroVMs

AWS.Lambda.MicrovmImage is a new Platform for snapshot-booted microVMs (#712). Author the in-VM server in TypeScript — alchemy bundles it, generates the Dockerfile, and builds the snapshot server-side — or bring your own Dockerfile or a prebuilt artifact:

export class Sandbox extends AWS.Lambda.MicrovmImage<
  Sandbox,
  { hello: (message: string) => Effect.Effect<string> }
>()("Sandbox") {}

export default Sandbox.make(
  { main: import.meta.filename, buildRole },
  Effect.gen(function* () {
    return {
      hello: (message) => Effect.succeed(`hello, ${message}!`),
      fetch: Effect.gen(function* () { /* raw HTTP route */ }),
    };
  }),
);

Every instance operation — RunMicrovm, GetMicrovm, suspend/resume/terminate, auth tokens, image builds — is a Binding.Service with least-privilege IAM scoping, and connectMicrovm gives you typed RPC into the running VM:

const sandbox = yield* AWS.Lambda.connectMicrovm(Sandbox, { endpoint, authToken });
const reply = yield* sandbox.hello("world");

It works cross-cloud too: binding a MicroVM operation from a Cloudflare.Worker mints an IAM user + assume-role Role so the Worker can drive AWS MicroVMs at runtime.

We also benchmarked MicroVMs against Cloudflare Containers — 700 isolated cold boots. MicroVMs boot in 2–4.5s regardless of what’s inside; full results in Benchmarking Cloudflare Containers vs AWS MicroVMs. Docs: MicroVMs.

Workers for Platforms

Deploy user Workers into a dispatch namespace and route to them dynamically (#715). A Worker deploys into a namespace with the new namespace prop — no duplicate resource type:

const ns = yield* Cloudflare.WorkersForPlatforms.DispatchNamespace("Customers", {});

const userWorker = yield* Cloudflare.Worker("CustomerA", {
  namespace: ns.name,
  script: `export default { fetch() { return new Response("hi") } }`,
});

The platform Worker binds the namespace Effect-natively, or via env for async Workers:

// Effect-native — yield the binding, get a typed client
const dispatch = yield* Cloudflare.WorkersForPlatforms.Get(namespace);
const userWorker = yield* dispatch.get("customer-a");

// async — DispatchNamespace is a valid env binding
const platform = Cloudflare.Worker("Platform", {
  main: "./handler.ts",
  env: { DISPATCH: namespace },
});
// handler.ts: env.DISPATCH.get("customer-a").fetch(request)

Docs: Workers for Platforms.

React Server Components on Vite

Cloudflare.Vite now supports builds that emit more than one server environment — most notably RSC (#685). viteEnvironments selects which environment produces the deployed Worker entry and which additional server environments are bundled alongside it:

const app = yield* Cloudflare.Vite("ReactRouterRSC", {
  compatibility: { flags: ["nodejs_compat"] },
  viteEnvironments: { entry: "rsc", children: ["ssr"] },
});

A single-environment SSR build needs no configuration — the default is { entry: "ssr", children: [] } — and the client environment always deploys as static assets. The same PR replaces the dev-server restart fingerprint with an exact structural signature, so config changes are never silently missed. Docs: Frontends on Cloudflare.

Workflows on async Workers

Class-based Cloudflare Workflows now bind to async (non-Effect) Workers via env, mirroring class-based Durable Objects (#707):

export const AsyncWorker = Cloudflare.Worker("Async", {
  main: "./src/worker.ts",
  env: {
    MY_WORKFLOW: Cloudflare.Workflow<{ value: string }>("MyWorkflow", {
      className: "MyWorkflow",
    }),
  },
});
export type Env = Cloudflare.InferEnv<typeof AsyncWorker>;
// env.MY_WORKFLOW is the native Workflow<{ value: string }>

Your WorkflowEntrypoint class stays plain cloudflare:workers code; alchemy provisions the workflow and emits the binding. Cross-script references work with scriptName, same as async DOs. Docs: Workflows.

Containers start fast and stay up

Cloudflare Containers deployed with alchemy behaved much worse than the same image deployed with wrangler — at 100 concurrent cold starts, ~2/100 succeeded. Two root causes, both fixed (#708):

Wrangler-parity defaults — maxInstances defaulted to 1, serializing every Durable Object through one container slot. Now maxInstances: 20, scale-from-zero, and instanceType: "lite" when no custom limits are set, matching wrangler.
Readiness polling — probes had no per-probe timeout, so a not-yet-listening port could hang for minutes. The loop now mirrors @cloudflare/containers exactly.

Result: 100/100 cold starts, on par with wrangler. And a container that stops or crashes is now transparently restarted on the next request, while a crash-looping container fails fast instead of burning the readiness budget (#711). Docs: Containers.

Effectful compute on ECS and EC2

The ServerHost + { fetch } pattern now works end to end on AWS.ECS.Task (#713): the container entry bundles a Bun HTTP server, ships every chunk into the image, and builds for the architecture the task declares — verified by a smoke test that deploys a real Fargate service behind an ALB.

The hosted AWS.EC2.Instance serves HTTP the same way, with a reboot-safe systemd unit that self-heals transient boot failures (#714). And there’s a new AWS.EC2.KeyPair resource — the generated private key is captured once as a Redacted secret:

const keyPair = yield* AWS.EC2.KeyPair("DeployKey", { keyType: "ed25519" });
// keyPair.keyName    -> AWS.EC2.Instance({ keyName })
// keyPair.privateKey -> Redacted<string>

The docs got a ground-up overhaul

The website is restructured into per-provider hubs behind a horizontal tab bar — Core · CLI · Cloudflare · AWS · PlanetScale · Neon · More ▾ — with ~100 new or reworked pages (#721):

Core — Infrastructure as Code, Infrastructure as Effects, APIs, Environments, State Store, Project structure, Testing.
CLI — every command documented, including the first-ever docs for alchemy unsafe nuke and adopting resources.
Cloudflare / AWS hubs — setup, five-part tutorials, block pages and guides grouped by role (Compute, Frontend, APIs, Data, Messaging, AI, …).
Every page written against source, tests, and fixtures; every moved URL 301s.

Start at the docs and pick your provider.

Also in this release

--yes is fully non-interactive (#728) — alchemy deploy --yes now auto-accepts the Cloudflare state store upgrade and deploy prompts instead of hanging on a non-TTY, so CI needs no workarounds.
Partial state-store deploys are detected and recovered (#700) — the store health check now verifies a real store is serving, not just that a pre-create stub exists.
Command.Build memo includes command + env (#738) — two StaticSite builds differing only in env (per-stage EXPO_PUBLIC_*, API ids) no longer reuse each other’s output.
Retained resources report as retained (#739) — destroy no longer lists RemovalPolicy: "retain" resources as deleted. Thanks bjorntechTobbe!
The CLI works on Windows (#696) — the stack entry loads via a file:// URL. Thanks d3lay!
Durable Object classes created outside alchemy adopt cleanly (#495) — class migrations fall back to matching the observed binding, so adopting a wrangler/dashboard Worker reuses its DO classes instead of failing to re-create them.
Access Application survives state loss (#742) — read falls back to a domain scan and gates takeover behind --adopt, instead of blindly creating a duplicate app with a fresh aud. Thanks Andy Jefferson!
Pooled connection origins — Neon Project/Branch (#718) and PlanetScale PostgresRole (#717) expose pooledOrigin, and PlanetScale branch replica intent persists so replicas: 0 converges (#719). Thanks Alex!
AWS env-auth fixes — Region is provided to STS during login (#709) and the Region/AWSEnvironment layer cycle in the account-id lookup is broken (#710).

Where to go next

Looping the Generation of IaC and SDKs

Thu, 02 Jul 2026 16:00:00 GMT

Alchemy is a new Infrastructure-as-Code framework built from the ground up in TypeScript and Effect. Everything is typed code, from a resource’s inputs and outputs down to the SDK calls and errors inside its lifecycle logic.

Built from the ground up also means starting from zero coverage. Alchemy can’t reuse the providers of existing IaC ecosystems like Terraform or Pulumi, and we’re a team of three, so hand-writing lifecycle code for thousands of cloud resources isn’t an option. We generate it with AI, using the loop in the diagram above.

Fleets of AI agents write the resources and their live tests, then run them against a real Cloudflare account. Every API behavior the SDK’s types don’t capture becomes a patch to the SDK, which regenerates and the tests rerun. One run of this loop grew Alchemy’s Cloudflare provider from 22 resources to 230 between June 11 and June 17, producing 288 test files with roughly 700 tests and 720 SDK patches. Most of it landed in a single PR (#601) that added 101,178 lines across 542 files and was open for 22 hours. The PR description, in its entirety:

Using Fable to generate all missing cloudflare resources

Deterministic codegen has been producing SDKs and IaC providers from API specs for years, and AI makes it even cheaper. The problem is that code generated from a spec is only as truthful as the spec, and real APIs drift from their specs. They return undocumented error codes, misuse HTTP statuses, and null out fields the schema says are required. That’s why the interesting number isn’t the 230 resources. It’s the 720 patches, each one a place where a live test caught the API doing something its spec doesn’t admit to.

A software development flywheel

Alchemy’s resources are built on distilled, our Effect-native SDK generated from Cloudflare’s official TypeScript SDK. It covers 114 services and 2,092 operations, and each operation can carry a patch, a small JSON file that corrects the spec where reality disagrees with it.

The run operated on one rule: agents never handle an unknown error in their own code. An unmatched error is never caught in the resource. It becomes an SDK patch and a regeneration. Untyped failure handling is where AI-generated code usually goes wrong, matching message substrings or guessing status codes. The rule takes that option away because the code doesn’t typecheck until the SDK knows about the error. It also makes the work compound. Every red test either fixes a resource or improves the SDK for the next one.

One turn of the flywheel

Infrastructure-as-code is mostly disciplined error handling. Deletes tolerate already-gone. Creates absorb losing a race. Reads ride out eventual consistency. In Alchemy that discipline is typed:

// idempotent delete: reading back an already-gone widget is success
turnstile.getWidget({ accountId, sitekey }).pipe(
  Effect.catchTag("WidgetNotFound", () => Effect.succeed(undefined)),
);

// R2's endpoint lags a fresh bucket create, so retry the not-found until it settles
r2.listBucketDomainCustoms({ accountId, bucketName }).pipe(
  Effect.retry({
    while: (e) => e._tag === "NoSuchBucket",
    schedule: Schedule.exponential("100 millis").pipe(
      Schedule.both(Schedule.recurs(5)),
    ),
  }),
);

The agents write this code first, then run it against the real API. A Turnstile test deletes a widget and reads it back to prove it’s gone. The read fails with code 10404, which the spec doesn’t declare. The catchTag doesn’t typecheck because WidgetNotFound isn’t in the error union yet, and the only permitted fix is a patch in distilled:

submodules/distilled/packages/cloudflare/patches/turnstile/getWidget.json

{
  "errors": {
    "WidgetNotFound": [{ "code": 10404 }, { "code": 10407 }],
    "Forbidden": [{ "status": 403 }]
  }
}

Regenerate the service (bun scripts/generate.ts --service turnstile) and the union names what the API actually does:

export type GetWidgetError = DefaultErrors | WidgetNotFound | Forbidden;

The catchTag compiles and the test goes green. The loop continues through reconcile, read, diff, delete, and list until the whole resource passes against the live API. The resource is the product and the truthful SDK is the byproduct. The patch lives in the SDK, not Alchemy, so anyone who uses distilled’s Turnstile module from now on gets WidgetNotFound as a typed, catchable error.

What 1,087 patches look like

By beta.56 the corpus stood at 1,087 patched operations, covering 52% of the SDK across 94 of 114 services:

	count
patches declaring typed errors	1,070
patches fixing a response schema	173
patches fixing a request schema	26
distinct error tags introduced	425
matchers on Cloudflare error `code`	1,367
matchers on HTTP `status`	994
matchers needing `message.includes`	377
matchers needing a regex	0

Most tags are the vocabulary lifecycle code needs, like Forbidden, WorkerNotFound, and NoSuchBucket. The rest catalog how APIs drift from their docs. Snippets returns 400 instead of 404 for a missing snippet, so the matcher reads the message. Queues consumers support http_pull but the spec’s enum doesn’t include it. Account settings come back null where the schema says they can’t. None of this is discoverable by reading documentation.

The factory

Around twelve agents ran concurrently, each owning one distilled service. Only the owner of turnstile writes to patches/turnstile/, so agents never race the generator. Every test follows one shape: deploy, verify out-of-band by querying the API directly through distilled, mutate, verify again, destroy, and prove the destroy by watching the resource disappear. A test never trusts the deploy’s own report of success. It confirms every step against what the API actually returns.

Two choices kept the loop fast. distilled is a git submodule inside alchemy’s bun workspace, so an agent patches the SDK and the resource that consumes it in one working tree, and a wave lands as two PRs, one to alchemy and one to distilled. And vitest resolves distilled from its TypeScript source, so a regenerated service is visible to the very next test run. The loop’s cycle time is the test’s runtime.

What’s next

We’re scaling this loop to every cloud provider, with two goals: 100% IaC coverage in Alchemy, and refined SDKs whose types align with each API’s real behavior rather than just its spec. AWS is next, then Railway, GCP, and Azure. The Cloudflare run was the proof, and it shipped in 2.0.0-beta.56.

Alchemy | Blog

2.0.0-beta.85 - Effect 4.1, Domain Replay & DynamoDB State

Effect 4.1

Alchemy Domain

Deploys roll out every change to a model

How it scales

Alchemy upgrades your deployed model

Serve a Domain model over HTTP, MCP or the CLI

Stories run real adapters and show what went wrong

Update your stories

GCP

Cloud Run services and containers, redesigned

One container

Add a sidecar

Run your own program

Run your own program in a sidecar

Call private Cloud Run services

Connect AWS and GCP without keys

Migrations on Cloud SQL, AlloyDB and Spanner

Sign in with gcloud

Custom domains with any DNS provider

Cloudflare State Store v8

Choose the Worker name

Pin the account and serve it on your domain

Upgrade from v7

AWS state now uses DynamoDB and plans 270× faster

Alchemist: the Alchemy CLI as a programmatic API

@alchemy.run/test: a test runner for Effect

Lambda aliases, streaming and partial batch failures

95 bug fixes

One conformance suite for every workflow engine

Drift only reports real changes

Deploys never take over a resource they don’t own

Cloudflare

Local dev

Also in this release

Where to go next

Hillclimbing distilled

How we kept score

The sane fixes

Small imports with big bills

One /*@__PURE__*/ does not cover its arguments

A tree-shaking bug in rolldown

Stranger, but defensible

One em dash doubles a module’s memory

The same schema, thousands of times

Faster calls

Faster, smaller AWS signing

Where that left us

Experiments, and our own schema library

Why Effect Schema had to go

Our problem is smaller

Same API, plain objects

Protocols run unchanged

Strict mode, and still faster than the official SDKs

Meta tree shaking

Operations as data

Tree shaking at run time

No eval, ever

Importing a whole provider

Breaking changes

Try meta tree shaking in Alchemy

2.0.0-beta.84 - Monorepo, Domain & Faster Distilled

One package per provider

OAuth can now create Account API Tokens

Every binding works from every cloud

Domain-driven design with @alchemy.run/domain

Smaller, faster distilled SDKs

Faster than the official SDKs

Plan and apply scale linearly

Foldkit SSR and prerendering

Lambda Web Functions

Effect workflows on every engine

Vite dev that matches @cloudflare/vite-plugin

Faster Cloudflare runtime

RDS migrations everywhere

GCP state store

Fly remote builds

Also in this release

Where to go next

One `/@PURE/` does not cover its arguments

No `eval`, ever

Domain-driven design with `@alchemy.run/domain`

Vite dev that matches `@cloudflare/vite-plugin`

Presigned R2 URLs in `alchemy dev`

Rewriting `pkg.alchemy.run`

`alchemy dev` runs lighter