Support cloudflare environment variables #272

pi0 · 2022-06-08T20:28:45Z

Reference docs: https://developers.cloudflare.com/workers/platform/environment-variables/

Normally, we allow extending runtime config using Node.js environment variables (process.env.FOO) while cloudflare exposes env as global constant variables (accessible as FOO or globalThis.FOO).

We can add support for globalThis but since without prefix can be dangerous, I propose to support ENV_* variables for globalThis support. (Setting ENV_FOO in Cloudflare is same as FOO=x node when using Node.js) but the downside is makes usage harder and needing more docs. We might only enable prefixless support for Cloudflare.

The text was updated successfully, but these errors were encountered:

marshallswain · 2022-06-28T03:05:52Z

I'm not sure if it will change anything for this issue, but the new module workers receive their environment variables differently. They are no longer bound to the global scope and are instead passed as the second argument to the fetch handler. I've been keeping notes on how to add support in this discussion. It might not change anything, but it's also noteworthy that any change here might be very short-lived as the new esm-based modules format is required in order to use any of the new features of Cloudflare Workers like D1 (SQL Database) and Durable Objects.

timhanlon · 2022-11-19T00:23:35Z

Since D1 hit public alpha, I've been trying to get something happening based on @marshallswain's discussion.

This WIP ESM preset is working, but as discussed, needs a way to access the environment to use service bindings, D1 etc: timhanlon@fabba1f

I'm keen to help push this forward, but unsure of an approach that would work for Nitro, given Cloudflare is one of many supported providers.

chrisspiegl · 2023-03-23T10:31:34Z

This looks really promising with the ESM worker. I wonder if this can also be ported over to the Cloudflare Pages version too?

These types of things are going to be a game changer to get for example vuefire-nuxt working (eventually and maybe 🙈).

I also ran into the situation with the process.env not rendering in the frontend but being needed by other plugins / etc.

I think a workaround with namespaced cloudflare env => process.env. mapping would be great.

I quickly tested it locally with a patched version of nitropack and it did exactly what it needed to do.

atinux · 2023-04-10T13:22:39Z

I like the idea of binding to process.env as well so it can stay consistent as in development.

But we need to find also a way to make it work for runtimeConfig

pi0 · 2023-04-10T17:10:20Z

With CF worker format, we have another limitation that ENV is only accessible within a request. For this we might introduce useRuntimeConfig?(event) (also subsequently event.context.env)

Hebilicious · 2023-06-16T13:11:48Z

With CF worker format, we have another limitation that ENV is only accessible within a request. For this we might introduce useRuntimeConfig?(event) (also subsequently event.context.env)

I'm hitting this issue now and it's really inconvenient ...
For now I'm working around this issue by modifying my runtime code to do this :

  let apiKey = useRuntimeConfig().openaiApiKey as string
  if (apiKey.length === 0) {
    apiKey = event.context.cloudflare.env.NUXT_OPENAI_API_KEY
  }

For the module syntax and pages, we could unblock this quite easily by doing something like this in the Nitro runtime cloudflare presets :

setRuntimeConfig(env)

setRuntimeConfig would proxy the variables like env.NUXT_MY_VARIABLE as runtimeConfig.myVariable (we could also proxy NITRO_* by convention, or everything ?)

This doesn't work with service workers syntax, but we should deprecate it anyways, pretty sure there's no need to maintain both syntaxes in Nitro

Then forwarding the request to Nitro where user code would work as expected with useRuntimeConfig.

Another things that is cloudflare specific that we could do is copy the user .env file into a .dev.vars as it's needed for wrangler to load the environment variables locally.

That way everything would work both in dev and while testing the build locally.
Then for deploy the variables needs to bet set manually in the dashboard or with wrangler secrets put (workers only, doesn't work with pages), so we could display a message to the user that they should do that.

I can open a PR with this change @pi0

kanelsnurren · 2023-07-22T15:11:46Z

@Hebilicious fix is needed (please merge his pr)

kanelsnurren · 2023-07-22T16:37:59Z

When will this be fixed, any ideas? @pi0

Hebilicious · 2023-07-22T20:13:28Z

When will this be fixed, any ideas? @pi0

There's a PR with a fix #1318

kanelsnurren · 2023-07-22T23:18:04Z

When will this be fixed, any ideas? @pi0

There's a PR with a fix #1318

Please merge it🙌

DidoMarchet · 2023-08-04T07:43:36Z

Hi, are there any updates concerning this issue?
Thanks and kind regards,
Davide

atinux · 2023-08-04T08:57:34Z

@DidoMarchet you can use process.env.MY_ENV directly inside your server routes and it should works

Hebilicious · 2023-08-07T10:37:51Z

With CF worker format, we have another limitation that ENV is only accessible within a request. For this we might introduce useRuntimeConfig?(event) (also subsequently event.context.env)

I'm hitting this issue now and it's really inconvenient ... For now I'm working around this issue by modifying my runtime code to do this :
  let apiKey = useRuntimeConfig().openaiApiKey as string
  if (apiKey.length === 0) {
    apiKey = event.context.cloudflare.env.NUXT_OPENAI_API_KEY
  }
For the module syntax and pages, we could unblock this quite easily by doing something like this in the Nitro runtime cloudflare presets :

setRuntimeConfig(env)

setRuntimeConfig would proxy the variables like env.NUXT_MY_VARIABLE as runtimeConfig.myVariable (we could also proxy NITRO_* by convention, or everything ?)

This doesn't work with service workers syntax, but we should deprecate it anyways, pretty sure there's no need to maintain both syntaxes in Nitro

Then forwarding the request to Nitro where user code would work as expected with useRuntimeConfig.

Another things that is cloudflare specific that we could do is copy the user .env file into a .dev.vars as it's needed for wrangler to load the environment variables locally.

That way everything would work both in dev and while testing the build locally. Then for deploy the variables needs to bet set manually in the dashboard or with wrangler secrets put (workers only, doesn't work with pages), so we could display a message to the user that they should do that.

I can open a PR with this change @pi0

Edit : After running further tests, it turns out that useRuntimeConfig(event) already works with cloudflare, cloudflare_module and cloudflare_pages thanks to unenv unjs/unenv#95 : useRuntimeConfig(event) will fallback to values in the global scope which will work consistently with nitro dev and nitro build. However this won't work without unenv, therefore I updated #1318 to reflect that. I will also make a separated PR to update the docs, and I believe this issue can be closed.

NITRO_OPENAI_API_KEY=abc #useRuntimeConfig(event).openaiApiKey will work with nuxt and nitro standalone
NUXT_OPENAI_API_KEY=abc #useRuntimeConfig(event).openaiApiKey will work with nuxt 
OPENAI_API_KEY=abc #useRuntimeConfig(event).openaiApiKey will not work

@lukamo1996 @DidoMarchet could you confirm that useRuntimeConfig(event) works for you ?

beaudryj · 2023-08-14T02:48:43Z

so.. if I am using

    sanity: {
      token: process.env.SANITY_TOKEN,
    },
    auth0: {
      clientID: process.env.Auth0__ClientId,
      redirectUrl: process.env.Auth0__RedirectUri,
      audience: process.env.Auth0__Audience,
      domain: process.env.Auth0__Domain,
      logoutReturnTo: process.env.Auth0__LogoutReturn,
    },
    public: {
      apiUrl: process.env.API_URL || 'https://localhost:5001',
      siteUrl: process.env.NUXT_PUBLIC_SITE_URL || 'http://localhost:4500',
      featureFlags: {
        mapFilters: process.env.FEATURE_MAPFILTERS === 'true',
      },
      googleAnalytics: {
        id: process.env.GOOGLE_ANALYTICS_ID,
        enabled: false,
      },
    },
  },

what do I do for cases that I do not have an event, or how does this work out for the client?

Hebilicious · 2023-08-14T06:40:51Z

@beaudryj this will work, see working example here : https://github.com/Hebilicious/nuxt-authjs-google

beaudryj · 2023-08-15T02:23:08Z

I had that, but it does not seem to work. I want to note that i do my preset build in my CI and ship my dist directory to cloudflare. If i was building on cloudflare do the envvars get set on their wokers at a build time? Or does nitro set the values there on page request

Hebilicious · 2023-08-15T07:17:38Z

I had that, but it does not seem to work. I want to note that i do my preset build in my CI and ship my dist directory to cloudflare. If i was building on cloudflare do the envvars get set on their wokers at a build time? Or does nitro set the values there on page request

You need to manually set the variables, you can use wrangler or the dashboard, see instructions in PR here
https://github.com/unjs/nitro/pull/1547/files

beaudryj · 2023-08-15T14:04:35Z

// In development
export default defineEventHandler((event) => {
  useRuntimeConfig(event).helloThere //general
  useRuntimeConfig(event).secret //undefined
  // Module syntax (cloudflare_module, cloudflare_pages)
  event.context.cloudflare.env.NITRO_HELLO_THERE //general
  event.context.cloudflare.env.SECRET //secret
  // Service worker syntax (cloudflare)
  NITRO_HELLO_THERE //general
  SECRET //secret
});

this block you have here though would not work for pages without events? what do I do in those scenarios

or is it more my nuxt.config.ts should be setup as

      apiUrl: event.context.cloudflare.env.API_URL || 'https://localhost:5001',
      siteUrl: event.context.cloudflare.env.NUXT_PUBLIC_SITE_URL || 'http://localhost:4500',
      showFeedback: event.context.cloudflare.env.SHOW_FEEDBACK === 'true',
      logRocketId: event.context.cloudflare.env.LOGROCKET_ID,
      pubnubPublishKey:event.context.cloudflare.env.PUBNUB_PUBLISH_KEY,
      pubnubSubscribeKey: event.context.cloudflare.env.PUBNUB_SUBSCRIBE_KEY,
      featureFlags: {
        mapFilters: event.context.cloudflare.env.FEATURE_MAPFILTERS === 'true',
      },

Hebilicious · 2023-08-15T14:39:30Z

// In development
export default defineEventHandler((event) => {
  useRuntimeConfig(event).helloThere //general
  useRuntimeConfig(event).secret //undefined
  // Module syntax (cloudflare_module, cloudflare_pages)
  event.context.cloudflare.env.NITRO_HELLO_THERE //general
  event.context.cloudflare.env.SECRET //secret
  // Service worker syntax (cloudflare)
  NITRO_HELLO_THERE //general
  SECRET //secret
});

this block you have here though would not work for pages without events? what do I do in those scenarios

or is it more my nuxt.config.ts should be setup as

      apiUrl: event.context.cloudflare.env.API_URL || 'https://localhost:5001',
      siteUrl: event.context.cloudflare.env.NUXT_PUBLIC_SITE_URL || 'http://localhost:4500',
      showFeedback: event.context.cloudflare.env.SHOW_FEEDBACK === 'true',
      logRocketId: event.context.cloudflare.env.LOGROCKET_ID,
      pubnubPublishKey:event.context.cloudflare.env.PUBNUB_PUBLISH_KEY,
      pubnubSubscribeKey: event.context.cloudflare.env.PUBNUB_SUBSCRIBE_KEY,
      featureFlags: {
        mapFilters: event.context.cloudflare.env.FEATURE_MAPFILTERS === 'true',
      },

You don't need to do that,process.env will work thanks to unenv. However, you have to set the env variables with wrangler or the cf dashboard.

beaudryj · 2023-08-15T15:42:45Z

I have them set in the dashboard. Build my projects with terraform and they are setup on the project I am deploying to. And I am saying that process.env in my runtimeConfig is not working. I deploy my latest to my configured project and the cloudflare variables are not being pulled.

I have values set on both Production and Preview

Hebilicious · 2023-08-15T18:25:22Z

I have them set in the dashboard. Build my projects with terraform and they are setup on the project I am deploying to. And I am saying that process.env in my runtimeConfig is not working. I deploy my latest to my configured project and the cloudflare variables are not being pulled.

I have values set on both Production and Preview

Hard to tell more without a reproduction, but I think your variables need to be prefixed by NUXT_ or NITRO_ in your nitro.config.ts/ nuxt.config.ts

https://nuxt.com/docs/guide/going-further/runtime-config#environment-variables
https://nitro.unjs.io/guide/configuration#update-runtime-config-using-environment-variables

beaudryj · 2023-08-16T02:59:53Z

neither made a difference.

in my

server route sample:

server/routes/signin.js

import { createNonce } from '~/utils/auth';
import buildUrl from 'build-url';
import { defineEventHandler, setCookie } from 'h3';

export default defineEventHandler(async (event) => {
  const runtimeConfig = useRuntimeConfig(event);
  const nonce = createNonce();
  setCookie(event, 'nonce', nonce, { secure: true });

  const url = buildUrl(`https://${runtimeConfig.auth0.domain}`, {
    path: 'authorize',
    queryParams: {
      client_id: runtimeConfig.auth0.clientID,
      response_type: '',
      redirect_uri: runtimeConfig.auth0.redirectUrl,
      scope: '',
      audience: runtimeConfig.auth0.audience,
      nonce: nonce,
    },
  });

  return sendRedirect(event, url, 302);
});

app.vue sample

<template>
  <NuxtLayout>
    <NuxtLoadingIndicator />
    <NuxtPage />
  </NuxtLayout>
</template>

<script setup lang="ts">
const route = useRoute();
const runtimeConfig = useRuntimeConfig();
const domain = runtimeConfig.public.domain;

useHead({
  titleTemplate: '%s - Leagued',
  viewport: 'width=device-width, initial-scale=1',
  charset: 'utf-8',
  htmlAttrs: {
    lang: 'en',
  },
  link: [
    {
      rel: 'apple-touch-icon',
      sizes: '180x180',
      href: '/favicon/apple-touch-icon.png',
    },
    {
      rel: 'icon',
      type: 'image/png',
      sizes: '32x32',
      href: '/favicon/favicon-32x32.png',
    },
    {
      rel: 'manifest',
      type: 'image/png',
      sizes: '16x16',
      href: '/favicon/favicon-16x16.png',
    },
    { rel: 'manifest', href: '/favicon/site.webmanifest' },
    {
      rel: 'mask-icon',
      color: '#5bbad5',
      href: '/favicon/safari-pinned-tab.svg',
    },
    { rel: 'shortcut icon', href: '/favicon/favicon.ico' },
    { name: 'msapplication-TileColor', content: '#ffc40d' },
    { name: 'msapplication-config', href: '/favicon/browserconfig.xml' },
    { name: 'theme-color', content: '#ffffff' },
    {
      rel: 'canonical',
      href: () => `https://example.com${route.path}`,
    },
  ],
});
</script>

Hebilicious · 2023-08-16T05:37:19Z

@beaudryj If you are confident that there's a bug, I recommend that you open an issue in the Nuxt repository with a minimal reproduction attached.

beaudryj · 2023-08-20T01:49:54Z

@Hebilicious thank you for the back and fourth on this.

I found what was tripping us up - https://v2.nuxt.com/docs/configuration-glossary/configuration-env/#processenv--

further digging into the docs I noticed this -

export default {
 runtimeConfig: {
    apiKey: '' // Default to an empty string, automatically set at runtime using process.env.NUXT_API_KEY
    public: {
       baseURL: '' // Exposed to the frontend as well.
    }
  }
}

So I did a deployment using Default to an empty string, automatically set at runtime using process.env.NUXT_API_KEY and it seems to have resolved

pi0 added enhancement New feature or request preset:cloudflare labels Jun 8, 2022

pi0 mentioned this issue Jun 8, 2022

runtimeConfig not parsing environment variables in cloudflare mode nuxt/nuxt#14011

Closed

TheAlexLichter mentioned this issue Feb 18, 2023

docs(cloudflare): add info regarding runtimeConfig and environment variables #958

Merged

7 tasks

pi0 mentioned this issue Apr 16, 2023

fix(cloudflare): expose env from module context #1147

Merged

7 tasks

Hebilicious mentioned this issue Jun 18, 2023

feat: support useRuntimeConfig(event) in all presets without unenv #1318

Closed

7 tasks

Hebilicious mentioned this issue Jul 23, 2023

Nuxt cloudflare-pages deployment fails nuxt/nuxt#21768

Closed

Hebilicious mentioned this issue Aug 7, 2023

docs(cloudflare): add environment variables instructions #1547

Merged

8 tasks

pi0 closed this as completed in #1547 Aug 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support cloudflare environment variables #272

Support cloudflare environment variables #272

pi0 commented Jun 8, 2022 •

edited

Loading

marshallswain commented Jun 28, 2022

timhanlon commented Nov 19, 2022

chrisspiegl commented Mar 23, 2023 •

edited

Loading

atinux commented Apr 10, 2023

pi0 commented Apr 10, 2023

Hebilicious commented Jun 16, 2023 •

edited

Loading

kanelsnurren commented Jul 22, 2023 •

edited

Loading

kanelsnurren commented Jul 22, 2023

Hebilicious commented Jul 22, 2023

kanelsnurren commented Jul 22, 2023

DidoMarchet commented Aug 4, 2023

atinux commented Aug 4, 2023

Hebilicious commented Aug 7, 2023 •

edited

Loading

beaudryj commented Aug 14, 2023

Hebilicious commented Aug 14, 2023

beaudryj commented Aug 15, 2023

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 15, 2023 •

edited

Loading

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 15, 2023 •

edited

Loading

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 16, 2023 •

edited

Loading

Hebilicious commented Aug 16, 2023

beaudryj commented Aug 20, 2023

Support cloudflare environment variables #272

Support cloudflare environment variables #272

Comments

pi0 commented Jun 8, 2022 • edited Loading

marshallswain commented Jun 28, 2022

timhanlon commented Nov 19, 2022

chrisspiegl commented Mar 23, 2023 • edited Loading

atinux commented Apr 10, 2023

pi0 commented Apr 10, 2023

Hebilicious commented Jun 16, 2023 • edited Loading

kanelsnurren commented Jul 22, 2023 • edited Loading

kanelsnurren commented Jul 22, 2023

Hebilicious commented Jul 22, 2023

kanelsnurren commented Jul 22, 2023

DidoMarchet commented Aug 4, 2023

atinux commented Aug 4, 2023

Hebilicious commented Aug 7, 2023 • edited Loading

beaudryj commented Aug 14, 2023

Hebilicious commented Aug 14, 2023

beaudryj commented Aug 15, 2023

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 15, 2023 • edited Loading

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 15, 2023 • edited Loading

Hebilicious commented Aug 15, 2023

beaudryj commented Aug 16, 2023 • edited Loading

Hebilicious commented Aug 16, 2023

beaudryj commented Aug 20, 2023

pi0 commented Jun 8, 2022 •

edited

Loading

chrisspiegl commented Mar 23, 2023 •

edited

Loading

Hebilicious commented Jun 16, 2023 •

edited

Loading

kanelsnurren commented Jul 22, 2023 •

edited

Loading

Hebilicious commented Aug 7, 2023 •

edited

Loading

beaudryj commented Aug 15, 2023 •

edited

Loading

beaudryj commented Aug 15, 2023 •

edited

Loading

beaudryj commented Aug 16, 2023 •

edited

Loading