Cloudflare Developers•2y ago

Is it possible to access env variables outside "fetch handler"

Hey everyone. I'm trying to set up few libraries that rely on on environment secrets, but it seems as if these secrets are only available on env object inside fetch handler? I am using https://hono.dev as a routing library and believe the only way to set up something like supabase client at the moment is via middleware

app.use('*', async (ctx, next) => {
  const supabase = createClient(ctx.env.SUPABASE_URL, ctx.env.SUPABASE_SERVICE_ROLE_KEY, {
    auth: { autoRefreshToken: false, persistSession: false }
  })
  ctx.set('supabase', supabase)
  await next()
})

app.use('*', async (ctx, next) => {
  const supabase = createClient(ctx.env.SUPABASE_URL, ctx.env.SUPABASE_SERVICE_ROLE_KEY, {
    auth: { autoRefreshToken: false, persistSession: false }
  })
  ctx.set('supabase', supabase)
  await next()
})

Is it correct to assume that this is the only way or am I missing something obvious here that allows me to get env variables in global scope as well? Thank you

2 Replies

Hello, I’m Allie!•2y ago

Yes, that is the current best practice for handling Environment Variables

jdanyow•17mo ago

resurrecting this thread- it looks like there's an exception to this for "__STATIC_CONTENT_MANIFEST"- I posted about this here: https://community.cloudflare.com/t/es-module-syntax-workers-bindings-available-as-module-import/543843 I wonder if there's any chance this might change?

Cloudflare Community

ES Module syntax workers: bindings available as module import

I recently switched a large cloudflare workers application from the Service Worker syntax to the ES Module syntax. Most of the work involved was related to bindings no longer being available at startup, instead they’re passed in via the lifecycle hooks (fetch, scheduled, etc), which meant I needed to pass env around each function call that requi...

Gaming

Programming

Is it possible to access env variables outside "fetch handler"