alchemy-run/alchemy

Alchemy is worth a look if you already work in TypeScript and Effect, or are willing to learn Effect, and want infrastructure declarations to sit in the same program as the code that talks to those resources. It is beta, so treat it as an experiment rather than a settled foundation.

The problem

Today the typical cloud app is split in two: YAML or a separate IaC tool declares the bucket, the function and its permissions, while the application code separately guesses at env vars, policy names and SDK clients. Getting a new resource into production means editing two files in two languages and redeploying both, and a permission mistake shows up at runtime instead of when you write the call. Alchemy collapses that: you declare Cloudflare.R2.Bucket("Uploads"), then ask the Worker for a read/write binding to that bucket inside the same Effect program, and deploy the combined result. The change in the workflow is that resource wiring, permission and typed client access become one line in the same file as the handler, so adding storage no longer means hand-editing a policy document somewhere else.

What's different

Alchemy's mechanism is bindings rather than generated glue code. Calling AWS.S3.GetObject(bucket) is documented as wiring the IAM policy, the environment variable and a typed SDK call in one operation, so the type checker and the deployment derive from the same declaration. Cloud API failures are modelled as tagged Effect errors, which means error handling is part of the type signature instead of an afterthought. The same program is meant to cover local development, plan/deploy, smoke tests and CI, so stages share one mental model rather than a different tool per environment.

The trade-off is Effect itself. The example is readable, but it is not plain async TypeScript: generators, Layers, Effect.gen and provided services are the idiom, and the README explicitly asks agents and newcomers to keep infrastructure and runtime code in one Effect program. If your team has not adopted Effect, the cost is learning both a new programming model and a new deployment model at once. The multi-cloud promise is also a breadth claim rather than a uniformity claim: AWS, Cloudflare, GCP, Fly, Hetzner, Kubernetes, Railway, Neon, PlanetScale and Stripe are listed, but each provider's resource surface will differ, so check that your specific services are covered before planning a migration.

Who should try it

A good fit is a small TypeScript team already using Effect, or seriously considering it, that deploys Cloudflare Workers or AWS Lambda plus a database and wants preview environments and typed bindings without maintaining YAML alongside code. The Cloudflare tutorial and the runnable examples are the natural starting points for judging whether the style suits you.

A poor fit is a team that needs plain, conventional infrastructure code with no Effect dependency, or one whose stack is dominated by services not represented in the provider list. It is also a poor fit for anyone who needs a stable API contract right now, since the README states v2 is in beta and breaking changes are expected. If you are unsure about Effect, read the what-is and getting-started pages first; an AI coding agent can bootstrap from the agent-ready docs index, but that does not remove the need to understand the model.

Requirements and limitations

You need Node or Bun with the Effect platform packages installed alongside alchemy; the install line calls for @effect/platform-bun and @effect/platform-node in addition to effect. Cloud credentials are supplied through environment variables such as CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN; the GitHub Action example also expects GITHUB_TOKEN and requires the alchemy CLI to be installed before the action runs. That last point is easy to miss: the action is documented as deploying prod from main, creating staging-{number} previews and destroying them on PR close, but it does not install the CLI for you.

The beta status is the ongoing limitation rather than a setup step. Expect breaking changes, budget time for upgrades, and pin versions in CI until v2 stabilises. Provider coverage should be verified per service, not assumed from the list of clouds.

HotRepo's take

HotRepo's only dated observation is 2026-10-28, when the project had 1,781 stars and gained 24 that day, appearing once on the daily board. That single snapshot cannot establish momentum or persistence, and the repository is young (created 2025-10-22), so popularity should not factor into the decision. The concrete thing to verify before adopting is whether the providers and resources you actually use are supported, starting from the provider docs.