Alchemy | Blog

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 alchemy@latest 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.

	`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 alchemy@latest 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@v1

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.

Benchmarking Cloudflare Containers vs AWS MicroVMs

Wed, 01 Jul 2026 00:00:00 GMT

We benchmarked cold starts for AWS Lambda MicroVMs and Cloudflare Containers: boot a fresh instance, wait until it answers a real request, record the time, tear it down, repeat. 700 boots across 16 variants.

The result, if latency is what matters to you: use AWS MicroVMs for your sandboxes even if everything else you run is on Cloudflare. In this benchmark, booting a MicroVM from a Cloudflare Worker — cross-cloud, over the public AWS API — was faster and far more predictable than Cloudflare’s own containers on Cloudflare’s own platform. And with Alchemy’s bindings, wiring a MicroVM into a Worker or Durable Object is a few lines of code — we’ll show it below.

We ran opencode as one of the workloads because it’s a popular coding agent that runs as a local process, weighs about 100 MB, and has real startup latency — exactly the kind of thing you’d host in a per-user sandbox. A boot counts as ready when the server answers its health check and creates a real session. Here’s how the distributions compare, opencode and hello world on both platforms:

And the same data as individual boots — this view is what the density curves smooth over, the container outliers at 20, 40, nearly 60 seconds:

	p50	p95	max
Cloudflare Container — opencode (via Worker)	10.5s	15.6s	58.6s
AWS MicroVM — opencode (via Lambda)	3.4s	4.1s	4.5s
AWS MicroVM — opencode (via Worker)	3.6s	4.0s	4.2s
Cloudflare Container — hello world (via Worker)	1.7s	23.9s	47.3s
AWS MicroVM — hello world (via Lambda)	2.7s	3.2s	3.7s
AWS MicroVM — hello world (via Worker)	3.1s	3.8s	5.4s

What’s remarkable in that table is AWS’s consistency. Look at the two workloads on MicroVMs: hello world is 2.7 seconds at the median, opencode is 3.4. A 100 MB coding agent with real startup work costs 0.7 seconds more than a 15-line server — because on AWS, everything goes through the same path. When AWS builds a MicroVM image, it doesn’t just build the Dockerfile — it runs the entrypoint, waits for the application to initialize, and takes a Firecracker snapshot of the running memory and disk (launch post). Every RunMicrovm resumes from that snapshot, so the workload’s startup is paid once, at build time. The flip side is that a lighter image doesn’t boot faster — it goes through the same snapshot restore. Boot time on AWS is a property of the platform, not the workload: 2 to 4.5 seconds, whatever’s inside.

Cloudflare is the opposite: boot time is a property of the workload, plus a tail you can’t control. For small, light containers that edge is real — the hello-world container is ready in 1.7 seconds at the median, ahead of anything on AWS. But a container cold start boots the image from scratch and runs the entrypoint, so every single container pays opencode’s full startup: the fastest opencode container in the run took 4.4 seconds and two-thirds took over 10. And the long tail has nothing to do with the workload — the hello-world container shows the same outliers in the scatter plot as the opencode one, with about one boot in ten over 10 seconds and the worst near 50. Yes, a Cloudflare container can be faster; it can also be 30–40 seconds slower, and you can’t predict which you’ll get.

For anything a person actually watches, AWS’s consistency is the better trade. You never want a user staring at a spinner for 10–60 seconds when they could wait 2–4.5, every time. A predictable 3 seconds is something you can design an experience around; an unpredictable 1-to-60 is not. Not one of the 49 successful opencode MicroVM boots exceeded 4.5 seconds.

The “via Worker” MicroVM rows are the proof of the claim at the top: those MicroVMs were booted from a Cloudflare Worker, and they beat Cloudflare’s own containers whenever the workload is heavy enough that startup matters. Crossing clouds costs nothing measurable — how that wiring works is covered below.

The entire opencode image is this:

FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN curl -fsSL https://opencode.ai/install | bash
WORKDIR /workspace
ENTRYPOINT ["opencode", "serve", "--hostname", "0.0.0.0", "--port", "8080"]

The snapshot behavior isn’t configured — it’s what building a MicroVM image means.

The same shape without the workload

Strip the workload away and the platforms keep the same characters. These are the hello-world variants — a 15-line Bun.serve on both platforms:

Cloudflare Containers are fast at the median — around 2 seconds — but the samples scatter out to 20, 40, nearly 50 seconds. AWS MicroVMs cluster between 2 and 4 seconds. The distribution view makes the trade explicit:

The container curves race ahead early and then go flat. Flat is the problem: 73–90% of boots are done by 3 seconds, and then the curve stalls — the remaining 10–27% of your users are waiting 10, 20, 40+ seconds. Every point in that flat stretch is a person staring at a spinner.

The MicroVM curves are the opposite shape: they start later but go straight up. A vertical line means every boot takes the same amount of time — the median user and the unluckiest user get nearly the same experience. That’s the property you can build a product on: you know what to promise, and the promise holds for the last user as well as the first.

	p50	p95	max
Cloudflare Container (plain Bun image)	1.7s	23.9s	47.3s
Cloudflare Container (Effect image)	2.3s	24.0s	46.7s
Cloudflare Container (public echo image)	2.6s	24.4s	26.1s
AWS MicroVM (plain Bun image)	2.7s	3.2s	3.7s
AWS MicroVM (Effect image, Bun)	2.9s	4.4s	4.8s
AWS MicroVM (Effect image, Node)	3.2s	3.7s	16.6s
AWS MicroVM (booted from a Cloudflare Worker)	2.7s	3.7s	4.1s

(The full 16-variant matrix — a Python image, the Node baselines, the remaining Worker-driven rows — lives in the full report.)

Which shape you want depends on what you’re building. If a slow boot retries invisibly in the background, take the faster median. If a person is watching — an agent sandbox spinning up, a preview environment, a REPL — the tail is the experience, and you can’t fix it with a spinner.

What we timed

One metric: time to usable service. Start the clock, ask the platform for a new instance, and stop the clock at the first successful application-level response. For the hello-world variants that’s an RPC round-trip into the running program; for opencode it’s the health check answering {"healthy":true} plus a POST /session returning a real session — a write through the application, proving the resumed process actually works, not merely that something is listening on the port. Whatever the platform does in between (pull the image, allocate, boot the kernel, start or restore the runtime, open the port) is inside the measurement, because it’s inside the user’s wait.

Every sample is a genuine cold start: each boot uses a fresh instance and the instance is terminated before the next round. One untimed warm-up boot runs first, so the one-time cost of distributing a freshly pushed image isn’t mixed into the numbers.

The images under test

The benchmark is an ordinary Alchemy app (benchmark/container). Each variant is an image resource, and the variants are chosen to isolate one question each.

The plain-Bun baseline answers “how fast can this platform possibly boot a JS server?” It’s a Dockerfile and a 15-line Bun.serve script:

FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN curl -fsSL https://bun.sh/install | bash
WORKDIR /app
COPY server.js .
ENTRYPOINT ["bun", "/app/server.js"]

The Effect image answers “what does Alchemy’s abstraction cost on top of that?” Instead of a Dockerfile and a server script, you write an Effect program and Alchemy bundles it into the image — the class is the infrastructure declaration and the typed client:

export class EffectfulBun extends AWS.Lambda.MicrovmImage<
  EffectfulBun,
  {
    hello: (message: string) => Effect.Effect<string>;
  }
>()("MicrovmEffectfulBun") {}

export default EffectfulBun.make(
  { main: import.meta.filename, runtime: "bun" },
  Effect.gen(function* () {
    return {
      fetch: Effect.succeed(HttpServerResponse.text("ok")),
      hello: (message) => Effect.succeed(`hello, ${message}!`),
    };
  }),
);

Deploying that builds a MicroVM image whose entrypoint is the bundled program. Anything that binds EffectfulBun gets hello as a typed method — the RPC plumbing, auth headers, and serialization are generated.

The gap between the two rows in the table is the entire cost of that abstraction: 0.2 seconds at the median (2.9s vs 2.7s), and it buys you typed RPC, bindings, and no Dockerfile. We ran the same pair on Node (the MicroVM base image ships with it) and the gap there is a rounding error.

The Cloudflare side mirrors this exactly — a plain oven/bun container, the same Effect program as a Cloudflare.Container, and a public echo image pulled from Docker Hub as a third reference point. Same story on that side too: the Effect image costs nothing measurable; the tail is a property of the platform, not the image.

Booting a MicroVM from a Cloudflare Worker

This is the part that makes “use AWS MicroVMs from Cloudflare” practical rather than theoretical. Here’s the entire Worker from the benchmark — the binding calls are the same ones a Lambda would make:

export default Cloudflare.Worker(
  "MicrovmBenchWorker",
  { main: import.meta.filename },
  Effect.gen(function* () {
    const run = yield* AWS.Lambda.RunMicrovm(EffectfulBun);
    const auth = yield* AWS.Lambda.CreateAuthToken(EffectfulBun);
    const terminate = yield* AWS.Lambda.TerminateMicrovm(EffectfulBun);

    return {
      fetch: Effect.gen(function* () {
        const vm = yield* run({});
        const { authToken } = yield* auth({
          microvmIdentifier: vm.microvmId,
          expirationInMinutes: 5,
          allowedPorts: [{ port: 8080 }],
        });
        const sandbox = yield* AWS.Lambda.connectMicrovm(EffectfulBun, {
          endpoint: vm.endpoint,
          authToken,
        });
        const greeting = yield* sandbox.hello("bench");
        yield* terminate({ microvmIdentifier: vm.microvmId });
        return HttpServerResponse.text(greeting);
      }),
    };
  }),
);

There’s no AWS account configuration in that file. The binding detects what it’s attached to. On a Lambda host, AWS.Lambda.RunMicrovm(EffectfulBun) adds lambda:RunMicrovm on that image’s ARN to the function’s execution role, and the runtime uses the assumed IAM Role credentials already available in the Lambda Function’s environment.

On a Worker host there is no execution role, so the binding builds the bridge itself. At deploy time it creates, once per Worker:

an IAM User whose only permission is sts:AssumeRole,
an AccessKey for that user, bound into the Worker as a secret,
an IAM Role that trusts only that user — and this is the role every MicroVM permission accumulates on.

At runtime the Worker uses the access key for exactly one operation: AssumeRole. Everything else — RunMicrovm, CreateAuthToken, TerminateMicrovm — is signed with the short-lived session credentials that come back. Those are cached and refreshed near expiry, shared across every binding on the Worker, so the STS call happens once per isolate rather than once per request.

Ideally the User wouldn’t exist at all — OIDC federation from the Worker straight into the Role would remove the long-lived key entirely, and that’s where we want to take this. But the shape is already the right one: the static credential can do nothing except mint short-lived ones, and the permissions live on a role scoped to the specific images the Worker binds.

The benchmark says the bridge is free: Worker → MicroVM lands within noise of Lambda → MicroVM on every variant. An AssumeRole amortized across boots doesn’t show up.

How the benchmark runs

A few methodology details matter more than usual here, because getting them wrong changed our conclusions the first time.

MicroVM boots run one at a time. The MicroVM control plane is rate-limited per account — RunMicrovm allows 5 TPS with a burst of 5. An early version of this benchmark launched 5 at once, sat exactly on that ceiling, and measured API throttling mixed into boot time — it looked like MicroVMs had a 1–2 second tail they don’t have. Each MicroVM sample is now a fully isolated launch → ready → terminate with nothing else in flight. Containers have no comparable per-boot limit, so they’re measured under concurrent load (10 rounds × 10 simultaneous boots).

This is also why we didn’t compare 100 simultaneous MicroVM launches: the 5 TPS is a soft limit, raised by request. It’s the standard AWS pattern of putting friction on access to a resource rather than a hard capacity ceiling — they’ll bump it when you ask, so it says nothing about how fast the platform boots VMs, only how fast a fresh account is allowed to ask.

The driver measures inside the host. Each host (the Lambda orchestrator, the Worker) exposes a /boot route that starts the clock, launches the instance, polls until a real request succeeds, and reports readyMs. The external driver only orchestrates; network latency to the driver never contaminates the measurement. On the container side the clock wraps the entire Durable Object call — instance allocation, container start, and the readiness probe — so nothing that happens before the probe can leak out of the measurement.

Resources are matched or tilted against the winner. The opencode container runs on Cloudflare’s standard-1 instance type (4 GiB) against the MicroVM’s 1 GiB, so the gap isn’t resource starvation — it’s the snapshot.

Everything is written down. Every boot lands as a row in a CSV, and the summary table and plots are generated from it. The app, the driver, and the data are in the repo — change a variant, run bun bench, and see for yourself.

Where this lands

Cloudflare Containers win the median for tiny images. AWS MicroVMs win everything else: the worst case by an order of magnitude, and the median too once the workload is heavy enough that startup matters. For anything where a person watches the boot — an agent sandbox, a preview environment, a REPL — the consistency is the feature. A user who always waits 3 seconds is happy; a user who sometimes waits 45 is gone.

One real advantage on Cloudflare’s side that latency numbers don’t capture: the Durable Object sits in front of all of the container’s network traffic. Your JavaScript can intercept every HTTP request the container makes — effectively a man-in-the-middle proxy you control. That enables patterns MicroVMs can’t do natively: keep API credentials in the Worker and inject them into outbound requests, so the agent running inside the container never sees a key it could leak. If your sandbox runs untrusted or agent-generated code against credentialed APIs, that interception layer is a serious reason to choose Cloudflare Containers despite the boot-time tail.

Both platforms sit behind the same abstraction: the same Effect program deploys as a Cloudflare Container or an AWS MicroVM, the same binding call works from a Lambda or a Worker, and the cross-cloud IAM wiring is generated from the code that uses it. Picking the latency shape you want is a couple of lines.

2.0.0-beta.59 - One Namespace, One Binding

Sat, 27 Jun 2026 22:00:00 GMT

beta.59 is the alignment release beta.58 set up. It is almost entirely renames: every Cloudflare service is now a real namespace, every binding across AWS and Cloudflare follows one {Verb}{Resource} convention, and the two-layer Binding.Policy split is gone — folded into a single runtime-guarded Layer (#690).

There’s almost no new behavior here. It’s a coordinated rename across ~900 symbols and ~1200 files so the API reads the same everywhere — you’ll find-and-replace your way through it.

Breaking changes — this release is mostly breaking renames. Migration for each is below.

Every Cloudflare service is namespaced — Cloudflare.KVNamespace → Cloudflare.KV.Namespace, Cloudflare.Worker → Cloudflare.Workers.Worker (common ones are re-exported at the root).
AiGateway / AiSearch / AiSecurity collapse into AI — Cloudflare.AiGateway → Cloudflare.AI.Gateway.
Bindings are now directly callable, namespaced, and least-privilege — R2Bucket.bind(b) → Cloudflare.R2.ReadBucket(b), DynamoDB.GetItem.bind(t) → AWS.DynamoDB.GetItem(t).
Binding.Policy is removed — the deploy-time wiring moves behind an if (!globalThis.__ALCHEMY_RUNTIME__) guard in a single Layer.
Impl layers are renamed — *Live → *Binding (Cloudflare native worker binding) or *Http (HTTP-client binding, all AWS + the Cloudflare HTTP impls).
Event sources are consume<Resource><Event>(resource, handler) — Queues.messages(q).subscribe(fn) → Queues.consumeQueueMessages(q, fn).
Worker-only bindings take a string id — Images({ name: "X" }) → Images("X"); their native layers drop *Live/*Layer (BrowserBindingLive → BrowserBinding).
Artifacts.Store → Artifacts.Namespace — and ReadWriteStore → ReadWriteNamespace (plus Read* / Write*).

Every Cloudflare service is a namespace

Cloudflare/index.ts used to be a flat export * of every symbol, so everything lived directly on Cloudflare.* with a redundant prefix baked into each name (Cloudflare.KVNamespace, Cloudflare.R2Bucket, Cloudflare.D1Database).

Resources move under their service

It now mirrors the AWS standard — one export * as <Service> per service, with the prefix stripped from the symbol:

const kv = yield* Cloudflare.KVNamespace("Sessions");
const bucket = yield* Cloudflare.R2Bucket("Assets");
const db = yield* Cloudflare.D1Database("App");
const kv = yield* Cloudflare.KV.Namespace("Sessions");
const bucket = yield* Cloudflare.R2.Bucket("Assets");
const db = yield* Cloudflare.D1.Database("App");

The same applies to Worker, which now lives under Cloudflare.Workers:

export default Cloudflare.Worker("Worker", { /* ... */ });
export default Cloudflare.Workers.Worker("Worker", { /* ... */ });

Common building blocks stay at the root

The common building blocks are re-exported at the root so the everyday path stays short — these all still resolve, no namespace required:

yield* Cloudflare.Worker("Worker", { /* ... */ });
yield* Cloudflare.Container("Sandbox", { /* ... */ });
yield* Cloudflare.DurableObject("Counter", { /* ... */ });
yield* Cloudflare.Workflow("Job", { /* ... */ });
yield* Cloudflare.RateLimit("Limiter", { /* ... */ });
Cloudflare.cron("0 * * * *", handler);

Everything else is reached through its namespace.

`DurableObjectNamespace` → `DurableObject`

The Durable Object base class loses its Namespace suffix — it’s a DurableObject now, full stop:

export class Counter extends Cloudflare.DurableObjectNamespace<Counter>()(
export class Counter extends Cloudflare.DurableObject<Counter>()(
  "Counter",
  /* ... */
) {}

Folder reshuffles and the new `WebSocket` type

A few folders were reshaped to fit: Container/ → Containers/, Queue → Queues, and workflow code moved into Workflows/. There’s also a new Cloudflare.WebSocket type for typing hibernatable WebSocket handlers.

`Ai*` becomes one `AI` namespace

The three separate AI services — AiGateway, AiSearch, and AiSecurity — were really one product surface split across three folders. They collapse into a single Cloudflare.AI namespace:

const gateway = yield* Cloudflare.AiGateway("Gateway");
const search  = yield* Cloudflare.AiSearch("Search");
const gateway = yield* Cloudflare.AI.Gateway("Gateway");
const search  = yield* Cloudflare.AI.Search("Search");

Symbols drop the redundant Ai prefix in the process — AiGatewayDataset → AI.Dataset, AiSearchInstance → AI.SearchInstance, AiSecuritySettings → AI.SecuritySettings.

One binding convention, everywhere

This is the heart of the release. AWS and Cloudflare bindings now read identically. A capability is the noun, prefixed by the verb (the access level it grants), and you call it directly — the .bind method is gone:

const get = yield* AWS.DynamoDB.GetItem.bind(table);
const bucket = yield* Cloudflare.R2Bucket.bind(Bucket);
const get = yield* AWS.DynamoDB.GetItem(table);
const bucket = yield* Cloudflare.R2.ReadWriteBucket(Bucket);

Where the underlying API distinguishes access levels, the capability is split into Read / Write / ReadWrite so you request least privilege — and the verb leads the name:

yield* Cloudflare.KV.ReadNamespace(Sessions);      // get / list
yield* Cloudflare.KV.WriteNamespace(Sessions);     // put / delete
yield* Cloudflare.KV.ReadWriteNamespace(Sessions); // both

`Binding` vs `Http`

Each capability ships two interchangeable implementation Layers, and the suffix tells you which transport it uses:

*Binding — a native Cloudflare Worker binding (env.BUCKET).
*Http — a scoped HTTP client that works anywhere, including inside a Container process that has no native binding.

// native Worker binding
.pipe(Effect.provide(Cloudflare.R2.ReadWriteBucketBinding))

// scoped HTTP token — same client, runs anywhere
.pipe(Effect.provide(Cloudflare.R2.ReadWriteBucketHttp))

The split lands on AWS too, where the only transport is HTTP: every AWS impl layer was renamed *Live → *Http (DynamoDB.GetItemHttp, SQS.SendMessageHttp, S3.GetObjectHttp), because an AWS runtime calls the distilled HTTP API authenticated by the Lambda’s IAM role. Binding is a Cloudflare native-worker concept — AWS never had one.

The two transports do the same thing in their respective worlds:

AWS *Http — emits a least-privilege IAM policy statement on the Lambda’s role, then calls the distilled HTTP API with it.
Cloudflare *Http — mints a scoped AccountApiToken with only the permission groups that access level needs, binds the token’s value into the environment as a secret, and calls Cloudflare’s REST API through distilled.

The client interface is identical regardless of which Layer you provide — a Worker reading a bucket over its native binding and a container reading the same bucket over a token are the same code.

More Cloudflare `*Http` bindings, one mechanism

A native Worker binding only exists inside a Worker. The moment you need the same capability somewhere with no native binding — a Container process, a Durable Object reaching a foreign resource, a script running outside the edge — you need the HTTP transport. beta.59 fills that gap out: R2, KV, and Queues already had *Http impls, and DNS joins them this release, all sharing one mechanism and the verb-first naming.

yield* Cloudflare.DNS.ReadDns(Zone);      // list / get records
yield* Cloudflare.DNS.WriteDns(Zone);     // create / update / delete
yield* Cloudflare.DNS.ReadWriteDns(Zone); // both

How it works: mint a scoped `AccountApiToken`

An *Http Layer can’t lean on env.MY_BINDING, so it provisions its own credential. At deploy time it mints an AccountApiToken scoped to only the permission groups that access level needs, and binds that token’s value into the host as a secret — all behind the __ALCHEMY_RUNTIME__ guard so it’s a deploy-time-only step:

const token = yield* AccountApiToken(`${self.LogicalId}Token`);

if (!globalThis.__ALCHEMY_RUNTIME__) {
  yield* token.bind`${resource.LogicalId}`({
    policies: [
      {
        effect: "allow",
        permissionGroups, // e.g. ["Workers KV Storage Read"] for ReadNamespace
        resources: { [`com.cloudflare.api.account.${accountId}`]: "*" },
      },
    ],
  });
}

The permission groups are what make this least-privilege: a ReadNamespace mints a read-only KV token, a WriteNamespace a write-only one. At runtime the client reads the token’s value and accountId from its secrets and calls Cloudflare’s REST API through distilled — no account-wide API key, no manual token plumbing, and a different scoped token per capability.

`Binding.Policy` is gone

Bindings used to be two pieces: a runtime Binding.Service plus a separate deploy-time Binding.Policy (with its own *PolicyLive layer) that registered the IAM / native binding. beta.59 collapses them into a single Binding.Service whose setup Effect does the deploy-time wiring inline, guarded so it only runs at plan time:

if (!globalThis.__ALCHEMY_RUNTIME__) {
  // deploy-time only: register IAM / native binding / env on the host
  yield* host.bind`${resource}`(/* … */);
}
// always: return the typed runtime client

At plan time the guard is open and bind records what the function needs. At runtime (__ALCHEMY_RUNTIME__ is set) the branch is skipped and the same call resolves to just the lightweight client, so the runtime bundle stays small. This is the exact pattern the capability bindings already used in beta.58 — now every binding, including event sources, follows it. Binding.Policy, Binding.ServiceClass, and the Policy / PolicyLike types are removed from the core.

Worker-only bindings take a string id

The Cloudflare bindings with no backing resource — Images, Browser, VersionMetadata, RateLimit — now take a string id first, like a resource logical id, instead of a { name } object:

const images = yield* Cloudflare.Images.Images({ name: "PIPELINE" });
const images = yield* Cloudflare.Images.Images("PIPELINE");

Their native layers drop the *Live / *Layer suffix to match the *Binding convention:

.pipe(Effect.provide(Cloudflare.Workers.BrowserBindingLive))
.pipe(Effect.provide(Cloudflare.Workers.BrowserBinding))

`Artifacts.Store` → `Artifacts.Namespace`

The Artifacts namespace is renamed Store → Namespace. Access stays explicit through ReadNamespace / WriteNamespace / ReadWriteNamespace:

const Repos = Cloudflare.Artifacts.Store("Repos");
const repos = yield* Cloudflare.Artifacts.ReadWriteStore(Repos);
const Repos = Cloudflare.Artifacts.Namespace("Repos");
const repos = yield* Cloudflare.Artifacts.ReadWriteNamespace(Repos);

Event sources: `consume<Resource><Event>`

Event sources are bindings too, so they got the same treatment. The old X(resource, props?).subscribe(handler) shape is replaced by a single verb-prefixed, resource-and-event-named callable that takes the handler as its last argument:

yield* Cloudflare.Queues.messages(inbound).subscribe((records) =>
  records.pipe(Stream.runForEach(Console.log)),
);
yield* Cloudflare.Queues.consumeQueueMessages(inbound, (records) =>
  records.pipe(Stream.runForEach(Console.log)),
);

Every event source now reads the same way — the name tells you both the resource and the element it yields:

Before	After
`SQS.messages(q).subscribe`	`SQS.consumeQueueMessages(q, fn)`
`S3.notifications(b).subscribe`	`S3.consumeBucketEvents(b, fn)`
`SNS.notifications(t).subscribe`	`SNS.consumeTopicNotifications(t, fn)`
`Kinesis.records(s).process`	`Kinesis.consumeStreamRecords(s, fn)`
`DynamoDB.stream(t).process`	`DynamoDB.consumeTableChanges(t, fn)`
`GitHub.events(r).subscribe`	`GitHub.consumeRepositoryEvents(r, fn)`

Dropping .subscribe also drops the handler’s runtime requirements at the source boundary, so explicit Body type arguments no longer break inference.

Also in this release

Two fixes shipped alongside the rename:

deleteFirst is honored on replace (#692) — a replacement defaults to create-first (stand up the new generation, then tear down the old), but some resources can’t coexist with their previous self (a fixed physical name, a singleton). deleteFirst is meant to flip that ordering, and the engine now actually does: it deletes the previous generation before creating the replacement instead of leaking an old chain into the next phase. Thanks John Royal.
Worker diff tolerates legacy custom-domain state (#694) — Alchemy ≤ beta.44 stored each Worker custom domain as a { id, hostname, zoneId } object; beta.45+ stores https://<hostname> strings and the diff path calls string methods on each entry. Older state now gets coerced back to strings so a Worker deploy no longer throws u.endsWith is not a function (#546). Thanks Nicolas Fléron.

Where to go next

2.0.0-beta.58 - Platform Ergonomics

Wed, 24 Jun 2026 22:00:00 GMT

beta.58 improves the ergonomics of Layers that contain Resources, so you can bundle infrastructure into a reusable service — like an agent tool — and provide it to a Worker, Container, or Durable Object.

A few changes get us there. First, a Platform tag (e.g. a Worker or Container) becomes pure identity: its props and its runtime implementation move out of the tag and into a Layer.

export class WorkerB extends Cloudflare.Worker<WorkerB>()(
  "WorkerB",
  { main: import.meta.filename }, // props on the tag
) {}
export class WorkerB extends Cloudflare.Worker<WorkerB>()("WorkerB") {}

export default WorkerB.make(
  { main: import.meta.filename }, // props on the Layer
  Effect.gen(function* () {
    /* ... */
  }),
);

Also, DurableObjectState can now be yielded at the top level, instead of having to be resolved inside the nested Effect.gen:

Effect.gen(function* () {
  const state = yield* Cloudflare.DurableObjectState;
  return Effect.gen(function* () {
    const state = yield* Cloudflare.DurableObjectState;
    let count = (yield* state.storage.get<number>("count")) ?? 0;
    /* ... */
  });
}),

Initialization is where resources, bindings, and dependencies are declared, so a Layer can contain infrastructure and be provided to any Worker, Durable Object, or Container without changing its shape.

One tag, many implementations

Because the tag is pure identity, one tag can have many implementations. .make(propsA, implA) and .make(propsB, implB) produce two Layers for the same tag — swap a real implementation for a stub in tests, or vary config per stage:

export const SandboxProd = Sandbox.make(
  { main: import.meta.filename, instanceType: "standard-1" },
  realImpl,
);

export const SandboxTest = Sandbox.make(
  { main: import.meta.filename, instanceType: "dev" },
  fakeImpl,
);

The inline form is unchanged — pass the implementation as a third argument and props stay inline:

export default Cloudflare.Worker(
  "Worker",
  { main: import.meta.filename }, // still inline here
  Effect.gen(function* () {
    /* ... */
  }),
);

A tool on Durable Object storage

Resolving DurableObjectState at init is what lets you capture the DO’s storage in a Layer and expose it as a service — the shape a Sql tool takes. Resolve state (and anything else, like an R2 bucket) at init, return the runtime methods:

class Archive extends Context.Service<Archive, {
  save: (key: string, body: string) =>
    Effect.Effect<void, never, Alchemy.RuntimeContext>; // <- RuntimeContext-colored
}>()("Archive") {}

const ArchiveLive = Layer.effect(
  Archive,
  Effect.gen(function* () {
    // Resolve both references at init.
    const state = yield* Cloudflare.DurableObjectState;
    const bucket = yield* Cloudflare.R2.ReadWriteBucket(Bucket);

    return Archive.of({
      // The body runs at runtime — both calls are RuntimeContext-colored.
      save: (key, body) =>
        Effect.gen(function* () {
          yield* bucket.put(key, body);
          yield* state.storage.put(`saved:${key}`, Date.now());
        }),
    });
  }),
);

Provide ArchiveLive on the DO’s init and yield* Archive from the inner Effect:

export class Doc extends Cloudflare.DurableObjectNamespace<Doc>()(
  "Doc",
  Effect.gen(function* () {
    const archive = yield* Archive; // resolved at init
    return Effect.gen(function* () {
      return {
        save: (key: string, body: string) => archive.save(key, body),
      };
    });
  }).pipe(Effect.provide(ArchiveLive)),
) {}

Neither DurableObjectState nor R2 leaks into Archive’s public type — consumers see only RuntimeContext, so the service stays cloud-agnostic.

A tool on a running Container

Containers used to be a three-step dance — bind, then start, then use. beta.58 collapses that: yield* the Container tag to get the running container instance (not the ContainerApplication resource), and provide Cloudflare.layerContainer(Class, options) to configure how it runs.

Effect.gen(function* () {
  const sandbox = yield* Cloudflare.Container.bind(Sandbox);
  const sandbox = yield* Sandbox;

  return Effect.gen(function* () {
    const container = yield* Cloudflare.start(sandbox, {
      enableInternet: true,
    });
    return {
      exec: (cmd: string) => container.exec(cmd),
      exec: (cmd: string) => sandbox.exec(cmd),
    };
  });
}),
}).pipe(
  Effect.provide(
    Cloudflare.layerContainer(Sandbox, { enableInternet: true }),
  ),
),

layerContainer binds, starts, and monitors the container, then satisfies the Sandbox tag with the running instance. Because it’s a plain Layer, any Effect or Layer can yield* Sandbox and get a running container — so a Bash tool is just a Layer that captures the container and shells out to it:

const Bash = Layer.effect(
  BashTool,
  Effect.gen(function* () {
    const sandbox = yield* Sandbox; // running instance
    return BashTool.of({
      run: (cmd: string) => sandbox.exec(cmd),
    });
  }),
);

The Bash Layer just requires Sandbox — layerContainer is provided once on the host’s outermost init Effect, where it satisfies both Bash and anything else that needs the container:

.pipe(
  Effect.provide(
    Layer.provideMerge(Bash, Cloudflare.layerContainer(Sandbox)),
  ),
)

External and remote Container images (built from a context / dockerfile, or pulled from a registry) have no runtime shape and no .make() — declare their props inline on the tag and register them with Cloudflare.layerContainer from the hosting Durable Object.

RPC works in Containers

Container RPC always existed on paper, but was never properly implemented or tested. As of beta.58 it actually works. A Container declares a typed runtime shape just like a Worker or Durable Object, and those methods are callable over RPC — the container exposes Effect-returning methods alongside its fetch handler:

export class MyContainer extends Cloudflare.Container<
  MyContainer,
  {
    ping: () => Effect.Effect<string>;
    readObject: (key: string) => Effect.Effect<string | null, never, RuntimeContext>;
  }
>()("MyContainer") {}

export default MyContainer.make(
  { main: import.meta.filename, dockerfile: "FROM oven/bun:latest" },
  Effect.gen(function* () {
    const bucket = yield* Cloudflare.R2.ReadWriteBucket(Storage);
    return {
      ping: () => Effect.succeed("pong"),
      readObject: (key) => bucket.get(key).pipe(/* ... */),
      fetch: Effect.gen(function* () {
        /* ... */
      }),
    };
  }).pipe(Effect.provide(Cloudflare.R2.ReadWriteBucketHttp)),
);

From the host, yield* MyContainer gives the running container and its methods round-trip through Cloudflare’s RPC machinery as typed Effects — no fetch plumbing, no manual serialization:

const container = yield* MyContainer;
const pong = yield* container.ping();           // RPC
const body = yield* container.readObject("key"); // RPC

Use container.getTcpPort(port) when you do need a raw fetch into a server running inside the container process.

`WorkerLoader`

DynamicWorkerLoader is renamed to WorkerLoader, and load(...) now returns an Effect, so you yield* it (#653):

const loader = yield* Cloudflare.DynamicWorkerLoader("Loader");
const worker = loader.load({ compatibilityDate, mainModule, modules });
const loader = yield* Cloudflare.WorkerLoader("Loader");
const worker = yield* loader.load({ compatibilityDate, mainModule, modules });

Bindings: least-privilege, native or HTTP

Bindings move to a namespaced convention: the single .bind on a resource is gone, replaced by a capability namespaced per access level.

const bucket = yield* Cloudflare.R2Bucket.bind(Bucket);
const bucket = yield* Cloudflare.R2.ReadBucket(Bucket);      // get / head / list
const bucket = yield* Cloudflare.R2.WriteBucket(Bucket);     // put / delete / multipart
const bucket = yield* Cloudflare.R2.ReadWriteBucket(Bucket); // both

Pick the least privilege you need, then provide an implementation Layer: the native Worker binding, or a scoped HTTP API token.

// native Worker binding (env.BUCKET)
.pipe(Effect.provide(Cloudflare.R2.ReadWriteBucketBinding))

// scoped HTTP API token — same client, runs anywhere (e.g. inside
// a Container process that has no native binding)
.pipe(Effect.provide(Cloudflare.R2.ReadWriteBucketHttp))

The client interface is identical regardless of which Layer you provide. A Worker can read a bucket over its native binding while a container process reads the same bucket over a token — same code, different Layer.

The *Http Layer is what makes the same client work where there’s no native binding — inside a Container process, for example. Providing it mints a scoped AccountApiToken and binds a policy with only the permission groups that access level needs:

const token = yield* AccountApiToken(`${self.LogicalId}Token`);
yield* token.bind`${bucket.LogicalId}`({
  policies: [
    {
      effect: "allow",
      permissionGroups: options.permissionGroups, // e.g. R2 read-only
      resources: { [`com.cloudflare.api.account.${accountId}`]: "*" },
    },
  ],
});

The token’s value is injected into the host’s secrets — secret_text on a Worker, a secret on a Container. At runtime the client reads it and calls R2’s REST API. No account-wide key, no manual token plumbing.

The Read / Write / ReadWrite split and *Binding / *Http implementations follow the same convention across KV, Queues, and the other capability resources. This namespaced convention is the direction for all bindings — the full migration across AWS, Cloudflare, and the other providers lands in beta.59.

`Command`: run shell commands as resources

The Build module is gone, replaced by a unified Command module that models shell commands as first-class resources sharing one executor (#673).

Command.Build (was Build.Command) runs a command that produces an output asset and tracks outdir in state. Inputs and outputs are content-hashed (opt-in via memo) so an unchanged project skips the rebuild:

const build = yield* Command.Build("vite-build", {
  command: "npm run build",
  cwd: "./frontend",
  outdir: "dist",
});
yield* Console.log(build.outdir); // path to dist, relative to process.cwd()

Command.Exec is new. It runs a command purely for its side effects — migrations, codegen, seeding — with no output contract: it succeeds as long as the command exits 0. memo re-runs it only when its inputs change:

yield* Command.Exec("migrate", {
  command: "npm run db:migrate",
  cwd: "./packages/api",
});

Command.Dev (was Build.DevServer) is a long-lived dev server scoped to the stack instance. It runs in the dev sidecar so it survives user-code HMR, and exposes the first http(s):// URL it prints as its url output. It’s a no-op during alchemy deploy:

const dev = yield* Command.Dev("Frontend", {
  command: "npm run dev",
});
yield* Console.log(dev.url); // e.g. "http://localhost:5173"

StaticSite (AWS + Cloudflare) and Cloudflare.Workers.Worker now build and dev-serve through Command. Resource type IDs were renamed, so existing state referencing Build.Command / Build.DevServer won’t match, and Command.Build’s output hash changed from { outdir, hash } to { outdir, hash: { input, output } }.

Where to go next

2.0.0-beta.57 - Containers in Dev & AI Search

Fri, 19 Jun 2026 20:00:00 GMT

Cloudflare Containers now run locally under alchemy dev — the same Container + Durable Object code that deploys to Cloudflare’s network docker-builds and runs on your machine, no code changes. beta.57 also adds Cloudflare AI Search (AutoRAG) as a one-call construct with a typed Worker binding, and a large AWS coverage wave.

Containers run locally in `alchemy dev`

A Container class is unchanged — declare its identity and props, provide the runtime implementation with .make():

src/SandboxContainer.ts

export class SandboxContainer extends Cloudflare.Container<
  SandboxContainer,
  {}
>()("SandboxContainer", {
  main: import.meta.filename,
  instanceType: "dev",
}) {}

export default SandboxContainer.make(
  Effect.gen(function* () {
    return SandboxContainer.of({
      fetch: Effect.succeed(
        HttpServerResponse.text("Hello from Sandbox container!"),
      ),
    });
  }),
);

A Durable Object binds it, starts it, and talks to it over a TCP port — again, nothing dev-specific:

src/SandboxDO.ts

export default class SandboxDO extends Cloudflare.DurableObjectNamespace<SandboxDO>()(
  "SandboxDO",
  Effect.gen(function* () {
    const sandbox = yield* Cloudflare.Container.bind(SandboxContainer);

    return Effect.gen(function* () {
      const container = yield* Cloudflare.start(sandbox, {
        enableInternet: true,
      });

      return {
        fetch: Effect.gen(function* () {
          const { fetch } = yield* container.getTcpPort(3000);
          const response = yield* fetch(
            HttpClientRequest.get("http://container/"),
          );
          return HttpServerResponse.text(yield* response.text);
        }),
      };
    });
  }),
) {}

As of beta.57, alchemy dev runs that container on your machine: the container program is bundled with rolldown, a Dockerfile is generated (FROM oven/bun:1 or node:22-slim depending on the container’s runtime, auto-installing any declared externals), and the local runtime docker-builds the image and wires it into the local Durable Object namespace.

bun alchemy dev
curl http://localhost:1338/sandbox
# Hello from Sandbox container!

Dev-created containers carry a dev:<uuid> application id, so a subsequent alchemy deploy knows to promote them to a real ContainerApplication (#636).

Cloudflare AI Search (AutoRAG)

Cloudflare.AiSearch stands up a full retrieval-augmented-generation pipeline over an R2 bucket — chunking, embedding, vector search, reranking, and generation, all managed by Cloudflare:

export const Docs = Cloudflare.R2Bucket("Docs", {});

export const Search = Cloudflare.AiSearch("Search", {
  source: Docs,
});

It’s a construct, not a single resource: for an R2 source it provisions a least-privilege AccountApiToken scoped to the AI Search Index Engine permission group, wraps it in the AiSearchToken service token the indexer requires, and creates the AiSearchInstance with everything wired together. Pass a URL as source instead and it indexes a website via the web crawler; prefix / include / exclude globs scope what gets indexed.

Cloudflare.AiSearchInstance.bind(search) gives a Worker a typed Effect client — chatCompletions for full RAG, search for retrieval-only:

export default class Api extends Cloudflare.Worker<Api>()(
  "Api",
  { main: import.meta.filename },
  Effect.gen(function* () {
    const aiSearch = yield* Search;
    const search = yield* Cloudflare.AiSearchInstance.bind(aiSearch);

    return {
      fetch: Effect.gen(function* () {
        const request = yield* HttpServerRequest;
        const url = new URL(request.url, "http://api");
        const query = url.searchParams.get("q") ?? "What is this about?";

        const answer = yield* search
          .chatCompletions({ messages: [{ role: "user", content: query }] })
          .pipe(Effect.orDie);

        return yield* HttpServerResponse.json({
          response: answer.choices[0]?.message.content,
          sources: answer.chunks.map((c) => c.item.key),
        });
      }),
    };
  }).pipe(Effect.provide(Cloudflare.AiSearchInstanceBindingLive)),
) {}

answer.chunks are the source chunks the answer drew from, so citations come for free. The binding also works in alchemy dev. The new AI Search tutorial walks through the whole pipeline, including dropping down to the underlying AiSearchInstance / AiSearchNamespace / AiSearchToken resources (#639).

An AWS coverage wave

Five new resources land in one PR (#631): CloudFront VpcOrigin, ELBv2 ListenerRule and TrustStore (mTLS), and Route53 HostedZone and HealthCheck — each with live tests.

Existing resources get much deeper. S3 Bucket alone gains encryption (SSE-KMS/DSSE), public access block, CORS, lifecycle rules, object ownership/ACL, access logging, website hosting, replication, intelligent tiering, object lock, and inline policy:

const site = yield* S3.Bucket("Site", {
  versioning: "Enabled",
  encryption: { sseAlgorithm: "aws:kms", bucketKeyEnabled: true },
  publicAccessBlock: { blockPublicAcls: true, blockPublicPolicy: true },
  lifecycleRules: [
    {
      ID: "expire-old",
      Status: "Enabled",
      Filter: { Prefix: "logs/" },
      Expiration: { Days: 30 },
    },
  ],
  website: { indexDocument: { suffix: "index.html" } },
});

CloudFront Distribution picks up origin groups, geo restriction, access logging, trusted key groups, origin shield, VPC origins, and gRPC; Route53 Record gains routing policies; and RDS, ECS, ELBv2, and SQS props all deepen — about 8,700 lines in total.

KMS keys, Lambda aliases, log-group config

Thanks José Netto for a run of AWS contributions: new AWS.KMS.Key and AWS.KMS.Alias resources (#641), a Lambda Alias resource (#625), reservedConcurrentExecutions on Lambda Function (#628), and LogGroup configuration — retention, KMS encryption, log class, and deletion protection (#630).

const key = yield* KMS.Key("AppKey", {
  description: "Application encryption key",
  enableKeyRotation: true,
});

yield* KMS.Alias("AppAlias", {
  aliasName: "alias/app",
  targetKeyId: key.keyId,
});

const logs = yield* LogGroup("ApiLogs", {
  retentionInDays: 30,
  kmsKeyId: key.keyArn,
});

Weighted alias routing shifts traffic between Lambda versions declaratively:

const alias = yield* Lambda.Alias("LiveAlias", {
  functionName: fn.functionName,
  functionVersion: "2",
  aliasName: "live",
  routingConfig: {
    AdditionalVersionWeights: { "3": 0.1 },
  },
});

Hardening the Cloudflare fleet

beta.56 grew the Cloudflare provider 10x in one release; beta.57 is the flywheel’s second turn — stabilizing that fleet against the real API. Live tests flagged rough edges in PageRule, Schema Validation, Images Variant, origin post-quantum encryption, Origin TLS client auth, and Pages Project, and each fix followed the same doctrine: patch the distilled SDK so the API’s actual behavior becomes a typed error tag, regenerate, and handle the tag — never a status-code check in alchemy code. The distilled submodule was repatched and regenerated six times during this release. Quota- and entitlement-bound live tests now skip cleanly instead of failing, and transient errors retry on their exact typed tag — e.g. Magic Network Monitoring retries MnnConfigMissing — so an entitled account runs the full suite unchanged.

Also in this release

diff.stables overrides provider.stables — a provider’s diff can now narrow stability per-update, fixing spurious replacements (#635).
Atomic local state writes — LocalState writes to a temp file and renames, so a crash mid-write can’t corrupt state.
alchemy dev no longer watches node_modules, cutting file-watcher churn on large projects (#646).
Queue consumers created in dev promote cleanly to a real deploy (#647).
Local service bindings preserve their entrypoints in dev. Thanks Jonathan Beckman (#643).
AI Search bindings work in local dev. Thanks Jonathan Beckman (#642).
alchemy cloudflare create-token can now mint user API tokens and interactively select permissions.
Build.Command handles both relative and absolute paths.
Artifacts.cached is allowed in the local RpcProvider (#648).
GitHub Repository docs — examples for templates, rename, archive, and secrets. Thanks Justin Bennett (#629).
AWS lifecycle hardening — Scheduler, SQS DLQ wiring, SNS Topic, CloudFront, DynamoDB, EC2, IAM, and Kinesis operations retry eventual consistency and throttling more robustly.
Cloudflare provider docs reorganized and categorized, with missing pages added.

Where to go next

2.0.0-beta.56 - 200+ Cloudflare Resources

Wed, 17 Jun 2026 20:00:00 GMT

The Cloudflare provider grows from 22 resources to 230 in this release. A single PR (#601) lands +101k lines across 542 files — 189 new live-test suites, every one run against a real Cloudflare account — bringing coverage to over a hundred Cloudflare services: Zero Trust (Access, Tunnels, Devices, Gateway, DLP), Magic Transit and Magic Network Monitoring, Load Balancing, DNS and DNS Firewall, SSL/TLS and certificates, Waiting Rooms, Logpush, Spectrum, Turnstile, API Shield, Bot Management, Page Shield, Workers for Platforms, Snippets, Zaraz, Registrar, Addressing, Alerting, and the rest of the long tail.

That means an entire Zero Trust deployment — tunnel, private network route, identity-gated application, WARP device profile — is now a single Effect (Zero Trust resources contributed by Andy Jefferson in #570):

// a private network reachable only through WARP + Access
const tunnel = yield* Cloudflare.Tunnel("Corp", {
  ingress: [
    { hostname: "dashboard.example.com", service: "http://localhost:3000" },
    { service: "http_status:404" },
  ],
});

yield* Cloudflare.TunnelRoute("PrivateNet", {
  tunnelId: tunnel.tunnelId,
  network: "10.4.0.0/16",
});

const allowCorp = yield* Cloudflare.AccessPolicy("AllowCorp", {
  name: "Allow corp users",
  decision: "allow",
  include: [{ emailDomain: { domain: "example.com" } }],
});

yield* Cloudflare.AccessApplication("Dashboard", {
  type: "self_hosted",
  domain: "dashboard.example.com",
  sessionDuration: "24h",
  policies: [allowCorp.policyId],
});

yield* Cloudflare.DeviceDefaultProfile("Default", {
  mode: "exclude",
  splitTunnelExclude: [{ address: "10.0.0.0/8", description: "RFC1918" }],
  excludeOfficeIps: true,
});

How: a test-driven SDK flywheel

The resources were implemented by fleets of AI agents working service by service against distilled, our generated Cloudflare SDK. Each agent implements a service’s resources, then live-tests them against the real API — and when a test hits an API behavior the types don’t capture, the fix goes into the SDK as a typed-error patch, not a catch-block in the consumer:

submodules/distilled/packages/cloudflare/patches/turnstile/getWidget.json

{
  "errors": {
    "WidgetNotFound": [{ "code": 10404 }, { "code": 10407 }],
    "Forbidden": [{ "status": 403 }]
  }
}

Run that loop across 288 live-test suites and the SDK’s patch set grows from 369 to 1,087 operations spanning 94 of 114 Cloudflare services — in one release cycle. Each patch records how the API actually behaves, as a type, for every future consumer of the SDK.

The full story — the loop, the patches, and the factory that ran them — is in Looping the Generation of IaC and SDKs.

Feature flags: `Cloudflare.FlagshipApp`

Cloudflare’s Flagship feature flags land as full resources with an Effect-native Worker binding (#602). Declare the app and its flags:

const app = yield* Cloudflare.FlagshipApp("Flags", {});

yield* Cloudflare.FlagshipFlag("NewCheckout", {
  appId: app.appId,
  key: "new-checkout",
  defaultVariation: "off",
  variations: { off: false, on: true },
});

FlagshipApp.bind(app) attaches the binding to the surrounding Worker and returns a runtime client for evaluating flags:

export const App = Cloudflare.FlagshipApp("Flags", {});

export default Cloudflare.Worker(
  "FlagsWorker",
  { main: import.meta.filename },
  Effect.gen(function* () {
    const flags = yield* Cloudflare.FlagshipApp.bind(App);
    return {
      fetch: Effect.gen(function* () {
        const enabled = yield* flags.getBooleanValue("new-checkout", false, {
          userId: "user-42",
        });
        return HttpServerResponse.text(enabled ? "on" : "off");
      }),
    };
  }).pipe(Effect.provide(Cloudflare.FlagshipBindingLive)),
);

Every method of the runtime Flagship binding is mirrored as an Effect. Async Workers can bind the app on env instead and use the raw binding.

`Provider.list` and `alchemy unsafe nuke`

Providers can now implement a list() lifecycle operation that enumerates every live resource of their type in the ambient account/zone (#620) — each item returned in the same Attributes shape read produces, so it’s directly deletable.

Built on top of it: alchemy unsafe nuke (#624) enumerates everything a profile’s providers can see and deletes it all. With 230 resource types now enumerable, a burned test account is a one-liner to clean:

alchemy unsafe nuke \
  --include "Cloudflare.*" \
  --filter 'resource.workerName === "alchemy-state-store"' \
  --dry-run

--include / --exclude take provider-ID globs; --filter takes JavaScript expressions evaluated with resource in scope — any resource for which an expression is truthy is spared. --dry-run previews, --yes skips the confirmation. The command is deliberately hidden from --help; it deletes real infrastructure.

GitHub repositories and webhook events

Justin Bennett contributed GitHub.Repository (#607) — full repository lifecycle with a converging reconciler that reads by stable numeric id, so renaming a repo out from under the stack doesn’t corrupt state:

const repo = yield* GitHub.Repository("internal-tools", {
  owner: "my-org",
  name: "internal-tools",
  visibility: "private",
  deleteBranchOnMerge: true,
});

On top of it, GitHub.events turns a repository into an event source for Cloudflare Workers (#619). Subscribing in a Worker’s init provisions a GitHub.Webhook pointed at the Worker’s URL; at runtime, deliveries are verified with a constant-time HMAC-SHA256 signature check and handed to your handler as fully-typed payloads:

const secret = yield* Config.redacted("GITHUB_WEBHOOK_SECRET");

// `event.name` is narrowed to "push" | "pull_request"
yield* GitHub.events({
  owner: "my-org",
  repository: "my-repo",
  events: ["push", "pull_request"],
  secret,
}).subscribe((event) =>
  Effect.log(`received ${event.name} (${event.id})`),
);

S3-backed state store: `AWS.state()`

AWS stacks get a first-class remote state backend, mirroring Cloudflare.state() (#585):

const Stack = Alchemy.Stack(
  "my-stack",
  { providers: AWS.providers(), state: AWS.state() },
  Effect.gen(function* () {
    // ...
  }),
);

State lives at s3://{bucket}/{prefix}{stack}/{stage}/{fqn}.json. By default the bucket is an auto-created account-regional bucket (alchemy-state-{accountId}-{region}-an); pass bucketName / prefix to use your own. Credential resolution and bucket creation are deferred to the first state operation, so nothing touches AWS at layer construction.

Also in this release

bundle: false on Cloudflare.Worker uploads a prebuilt main byte-for-byte — no rolldown, no minification — with glob-based rules selecting additional modules. The working path for OpenNext and other externally-bundled outputs. Thanks Alex (#592).
alchemy plan starts near-instant — 8.2s → 1.8s warm, via lazy-loading the TUI and vite plugin and deferring distilled schema construction (#618).
worker.url is stable across deploys when the first domain is unchanged, so downstream resources referencing it (e.g. webhook delivery URLs) stop phantom-updating (#616); same for worker.durableObjectNamespaces when the DO class set is unchanged (#617).
Lambda function URLs accept full config — url: { authType: "AWS_IAM", cors, invokeMode: "RESPONSE_STREAM" }; IAM-auth URLs drop the public permission statement. Thanks José Netto (#614).
alchemy dev stays alive when an apply fails, logging the full cause instead of silently exiting. Thanks Matthew Aylward (#582).
StaticSite forwards dev.env (including Redacted secrets) to the external dev-server command. Thanks Alex (#587).
Local assets binding no longer 500s in alchemy dev (#613).
Drizzle drift detection is cached per plan/apply cycle, so drizzle-kit’s interactive rename prompt appears once instead of hanging alchemy dev (#597).

Where to go next

2.0.0-beta.55 - AI Gateway Spend Caps

Thu, 11 Jun 2026 20:00:00 GMT

An AI Gateway sits in front of your model calls, which means it’s also where a runaway loop turns into a runaway bill. beta.55 puts the guardrail in your stack: Cloudflare.AiGatewaySpendingLimit sets a hard dollar cap on cumulative AI Gateway spend across every gateway in the account, declared and reconciled like any other resource.

`Cloudflare.AiGatewaySpendingLimit`

Amounts are in cents (Cloudflare’s native unit — minimum 1_00 = $1.00), accumulated over a daily, weekly, or monthly window with a fixed (reset on the boundary) or sliding (rolling window) strategy:

import * as Cloudflare from "alchemy/Cloudflare";

// Cloudflare requires one manual credit top-up before a spending limit
// can be set. `topUp` reconciles that requirement: the provider observes
// the billing state and only charges the account's default payment
// method if the account has never topped up.
const cap = yield* Cloudflare.AiGatewaySpendingLimit("ai-spend-cap", {
  amount: 250_00, // cents -> $250.00 (minimum 1_00 = $1.00)
  duration: "monthly",
  topUp: { amount: 10_00 }, // cents -> $10.00 (Cloudflare minimum)
});

The topUp prop deals with Cloudflare’s bootstrap requirement: an account can’t set a spending limit until it has loaded Unified Billing credits via at least one manual top-up (NO_MANUAL_TOPUP). The provider observes first_topup_success on the live billing API and only makes the one-time charge when the account has never topped up — once bootstrapped, the prop is inert and never charges again. If the payment needs interactive confirmation (3-D Secure), the resource fails with a typed AiGatewaySpendingLimitTopupRequired error and the top-up must be completed in the dashboard.

Auto recharge is on by default — when the credit balance drops below threshold, Cloudflare recharges by amount automatically:

const cap = yield* Cloudflare.AiGatewaySpendingLimit("ai-spend-cap", {
  amount: 250_00,
  duration: "monthly",
  topUp: { amount: 20_00, threshold: 10_00 }, // recharge $20 below $10
});

Set topUp: { amount: 10_00, autoRecharge: false } for a one-time bootstrap only.

One caveat: Cloudflare stores a single limit per account, so this resource is a per-account singleton — declare exactly one. Thanks Matthew Aylward (#569).

Fetcher utils on `alchemy/Cloudflare/Bridge`

The fetcher/socket interop helpers — fromCloudflareFetcher, toCloudflareFetcher, toHttpClient, fromCloudflareSocket — are now exported from the alchemy/Cloudflare/Bridge entrypoint, and fromCloudflareFetcher / fromCloudflareSocket accept the global Fetcher / Socket types directly (#581).

That combination matters inside a framework worker (TanStack Start, Astro, …), where your Effect backend arrives as a plain service binding on env. Two calls turn it into a fully typed Effect HttpClient — no casts:

import * as Cloudflare from "alchemy/Cloudflare/Bridge";

const client = Cloudflare.toHttpClient(
  Cloudflare.fromCloudflareFetcher(env.BACKEND),
);
const res = await client
  .get(`https://backend/?key=${encodeURIComponent(key)}`)
  .pipe(Effect.runPromise);
return HttpServerResponse.toWeb(
  HttpServerResponse.fromClientResponse(res),
);

The request rides the in-account service binding, not the public network. The cloudflare-website-tanstack-start example’s /api/hello route now serves the same object four ways side by side — the raw R2 binding, the service binding’s fetch, typed RPC (toRpcAsync), and this HttpClient form — each covered by an integration test.

Also in this release

Fixed a dangling process that kept alchemy deploy / alchemy destroy from exiting — local RpcProvider service layers (providerServices / providerServicesEffect) now only construct when AlchemyContext.dev is set, so one-shot CLI runs no longer spin up the local dev provider machinery (#580)

Alchemy | Blog

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

effect rc.115

An embeddable, pluggable Git server

Embedded by design

Performance

Where the hashing runs

Stripe

Worker Previews

GitHub: rulesets, protection, releases, and more

alchemy dev runs lighter

RDS, S3, and security group fixes

Also in this release

Where to go next

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

1. Connect an account

2. alchemy dev

3. alchemy deploy

4. alchemy drift

5. alchemy destroy

Without a TTY

Cloudflare.Telemetry()

Workflows: cron schedules

Provisioned ElastiCache

Railway: private services, pre-deploy, local contexts

Also in this release

Where to go next

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

alchemy depends on effect@rc

Websites on five clouds

Railway

Hetzner

Fly.io

AWS local dev

Local ECS and MicroVMs

One migration format for SQL databases

Protect Workers with Access

Inbound email to Workers

Removal policies persist

Lambda Docker Functions

Also in this release

Where to go next

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

effect beta.105 and the drizzle rc.5 lockstep

Better Auth: every database, effectful API

alchemy dev fixes

State from older versions recovers automatically

Also in this release

Where to go next

2.0.0-beta.70 - Web Frameworks & Full Local Dev

The Website family: six new frameworks

alchemy dev covers the whole surface

Vite dev servers run in child processes

Rename resources with renamedFrom()

Data sources: plan-time execute

Kubernetes goes cluster-agnostic

distilled v1

MySQL for effect-sql and Drizzle

WorkerEntrypoint bindings

Pure annotations are opt-in only

Also in this release

Where to go next

2.0.0-beta.66 - Local Emulation & Gradual Deployments

Local emulation in alchemy dev

Worker versions & gradual deployments

Worker URLs redesigned

OpenTelemetry export

Prisma provider

Bedrock LanguageModel

Also in this release

Where to go next

2.0.0-beta.65 - SageMaker HyperPod

SageMaker HyperPod

Worker bundling fixes

Destroy and nuke converge in one pass

Also in this release

Where to go next

A Test Runner for Agents

Why not vitest

Why not bun test

`alchemy dev` runs lighter

2. `alchemy dev`

3. `alchemy deploy`

4. `alchemy drift`

5. `alchemy destroy`

`Cloudflare.Telemetry()`

`alchemy dev` fixes

`alchemy dev` covers the whole surface

Rename resources with `renamedFrom()`

Data sources: plan-time `execute`

Local emulation in `alchemy dev`

`alchemy login` works anywhere

`alchemy dev` reliability

Effect-native `ExecutionContext`

`alchemy sync`

AI Gateway BYOK: `AI.ProviderKey`

R2 Bucket `cors`

`DurableObjectNamespace` → `DurableObject`