#Support both v5 and v6 environment variables with cloudflare adapter

8 messages · Page 1 of 1 (latest)

toxic frigate
#

Since locals.runtime.env is removed in Astro v6 for the cloudflare adapter, how are you guys (integration authors) support both v5 and v6 in your integrations? Do you have a helper that checks if it exist first and fallback to import { env } from "cloudflare:workers" if not? Can you share it with me? 😸

iron frigateBOT
#

Hi @toxic frigate. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

I’m not seeing anything in the provided docs that explicitly mentions locals.runtime.env being removed in Astro v6, nor any official “compat helper” pattern for supporting both v5 and v6 in a single integration. The Cloudflare guide only documents the current (v5) behavior:

  • Accessing the Cloudflare runtime via Astro.locals.runtime / context.locals.runtime.
  • Reading environment variables and secrets from Astro.locals.runtime.env. [Cloudflare runtime]

It also notes that Cloudflare environment variables and secrets are compatible with the astro:env API, but does not show a version-conditional pattern or a fallback to import { env } from "cloudflare:workers". [Cloudflare runtime; astro:env ref]

Because the sources don’t cover Astro v6 Cloudflare changes or any cross‑version helper, I can’t reliably provide the kind of shared snippet you’re asking for without guessing.

Given what is documented, the forward‑compatible direction that Astro recommends in general is:

  • Prefer astro:env for environment variables where possible (type‑safe, adapter‑aware). [Type‑safe env; astro:env ref]
  • Use the Cloudflare runtime (Astro.locals.runtime.env) when you specifically need Cloudflare bindings / secrets as defined in wrangler.*. [Cloudflare runtime]
#

But the docs don’t show a concrete pattern for “if v5 then locals.runtime.env, else cloudflare:workers import”.

So, to your specific question:

  • There is no documented helper in these sources that checks for locals.runtime.env and falls back to import { env } from "cloudflare:workers".
  • The knowledge sources do not contain enough information to describe how other integration authors are handling v5+v6 compatibility or to share an official snippet for that.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@toxic frigate Kapa.ai is still learning and improving, please let me know how I did by reacting below.

toxic frigate
iron frigateBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

The provided knowledge sources don’t include the PR you linked or any Astro v6–specific Cloudflare changes, so I can’t see the new recommended pattern or any official compatibility helper. They only document the current v5 behavior:

There is no mention in these docs of:

  • locals.runtime.env being removed in v6, or
  • a documented helper that checks for locals.runtime.env and falls back to import { env } from "cloudflare:workers".

Because of that, I can’t reliably show you how other integration authors are handling v5+v6 compatibility or share an official helper snippet without guessing.

Given only what’s documented here, the safest, forward‑looking approach for integrations is:

  • Prefer astro:env for environment variables where possible (adapter‑aware, type‑safe). [Environment variables API]
  • Use the Cloudflare runtime (Astro.locals.runtime) only when you specifically need Cloudflare bindings (queues, DOs, etc.). [Cloudflare runtime]

But any concrete “support both v5 and v6” helper based on cloudflare:workers is not described in the available sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: