How do I handle env variable imports when building from within a Github Action?

[olexatourko]

My SvelteKit frontend is a microservice that's part of a larger application. I have a GitHub Action which builds and publishes my frontend as a Docker image. The action encounters this error while building the SvelteKit app:

Error: 'PUBLIC_SOME_VARIABLE' is not exported by $env/dynamic/public, imported by src/routes/billing/+page.svelte

It makes sense considering that I don't include a .env file in the repository. Instead I include a .env.example and create a real .env file for my dev machine and production host (it gets mounted through Docker).

How can I have an automated build step for my frontend without actually committing any env variables to my repo?

[olexatourko]

Temporary Solution

For now I've been able to get around this by moving the app build step out of the Docker image build.

dockerfile

FROM node:18-alpine AS base
WORKDIR /frontend
COPY frontend/package.json .
COPY frontend/package-lock.json .

# Builds development image
FROM base AS development
RUN npm install
ENTRYPOINT ["npm", "run", "dev"]

# Builds production image
FROM base AS production
COPY frontend/ ./
RUN npm install
# Build happens on container startup intsead of image build because: https://github.com/sveltejs/kit/discussions/7265
ENTRYPOINT ["npm", "ru
n", "serve"]

package.json scripts
I added the serve command

  "scripts": {
    "dev": "vite dev --host 0.0.0.0",
    "build": "vite build",
    "serve": "npm run build && node build/index.js",
    "preview": "vite preview",
    "check": "svelte-kit sync && svelte-check --tsconfig ./jsconfig.json",
    "check:watch": "svelte-kit sync && svelte-check --tsconfig ./jsconfig.json --watch"
  }

Further Research / Notes

I tried playing around with the Vite Env Mode, and got build to read from an alternatively named .env file like .env.buildonly. My idea was that I could commit .env.buildonly to the repo, which would then contain the env keys but no values. Then when I ran the built application I could get it to read from a real .env file with values set.

Unfortunately I couldn't get this to work. I'm guessing that once a SvelteKit app is built the env variables are part of the built package.

I could maybe get around this by using dotenv to read from a .env file at runtime, but then that involved implementing something like $env/dynamic and $env/static for the clientside.

Idk, I'm mostly a backend dev that doesn't spend much time with JS or Vite.

[cotyhamilton]

I wouldn't use the static environment variables, you're correct that those get baked into the build, I'm not sure why that's still promoted with SSR...

Just use runtime environment variables and pass them in to the container on docker run

[iaingalloway]

Did you ever find a better solution? I have a similar problem where I've got a sveltekit app that I'm containerising with a multi-stage dockerfile. I definitely don't want to use different container images per-environment, but I'd rather not use $env/dynamic/public if there's any way I can avoid it.

I could grab application variables on startup and squirt them into a static file that I reference directly, but that seems awfully manual. It seems worth a little time searching for an easier way.

[simonnice]

Anyone that has a better solution for this? I'm currently struggling with this exact issue on my project. I've tried setting the values as Github Secrets in my workflow and other solutions but to no avail.

[miguelvalente]

Did you end up figuring out a solution? I'm also using GitHub Secrets.

[fjukstad]

I overcame the errors by adding a .env file with a placeholder

PUBLIC_SOME_VARIABLE=

in my repository, and a local .env.development on my machine with

PUBLIC_SOME_VARIABLE=secret

[iaingalloway]

I don't think that helps in this scenario. You'd need to build env.local into the container - meaning a) you'd need those values available at build time, b) you'd need to be comfortable shipping those values as part of a container image, and c) you'd need different container images per-environment.

The problem is that static values are baked into the build, and there's nowhere "natural" to put values that we won't know until startup time. In that case either we need to defer the entire build until runtime, use dynamic, or do some work "outside" the framework to do something else.

[fjukstad]

Since the .env file only contains empty placeholder environment variables (only key names and empty values), I'm happy with adding the .env file to the container. I will use Github Secrets, Azure KeyVault etc. for storing the actual values, and pass them to the container when I run the app, so I don't see an issue with adding a placeholder .env to the repository or container. Maybe there's something that I'm missing?

[iaingalloway]

I created an MCVE here: https://github.com/iaingalloway/svelte-stores-mcve

Notice that the values in $env/static/public aren't set when run from the container, because the (empty) placeholder values from .env were baked into the build.

To get around this we need to do one of:

1. Make the value available to docker build at build time, meaning we need a different container image for each environment
2. Use $env/dynamic/public instead of $env/static/public
3. Run npm run build inside our actual production container, meaning we have a much larger, much more complicated, and much more vulnerable container image
4. Something else?

It might be that using $env/dynamic/public is fine, and that I've misunderstood or been misled by the documentation regarding what it's for. It might be that there's a better way that I'm missing.

[jyrive]

I had similar kind of problem, when with $env/static/public variables which are passed on build time. Locally I use .env file obviously, but didn't want to push it to repo. In my application I use sveltekit, github actions to build it and deploy as azure static web app.

I came up with following solution:

1. I added the environment variables as github secrets, more info here: https://docs.github.com/en/actions/security-guides/encrypted-secrets
2. then in github action yaml file added them as environment variables, more info here: https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

Following is example in practice what yaml file looks like on build section (example environment variable is named PUBLIC_ERROR_MESSAGE)

[DougAnderson444]

THIS works.

[DougAnderson444]

If it's not a secret, you can also use ${{ vars.NAME }} too

[shahin-salehi]

This actually saved my life

[SMoralesKGrow]

This was so obvious, thanks that solves my problem.

[FernandoArteaga]

In my workflow, I have a step that copies a .env.ci file which contains placeholders, as the .env file.
Then I do an envsubst for substituting the placeholders with my environment and secrets variables.

.env.ci file

PUBLIC_ENV=${APP_ENV}
PUBLIC_API_KEY=${API_KEY}

build workflow

name: "Build sveltekit app"

on:
  workflow_call:

jobs:
  install_build:
    name: "Build app config"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: "Setup pnpm"
         uses: pnpm/action-setup@v3
         with:
           version: 8
           run_install: false
      - name: "Setup Node"
         uses: actions/setup-node@v4
         with:
           node-version: 18
           cache: "pnpm"

      - name: "Replace env variables (dev)"
         uses: danielr1996/envsubst-action@1.0.0
         env:
            APP_ENV: ${{ vars.APP_ENV }}
            API_KEY: ${{ secrets.API_KEY }}
         with:
            input: .env.ci
            output: .env

      - name: "Install dependencies"
         run: pnpm install

      - name: "Build app"
         run: pnpm build

[anly2]

All of the above approaches, as far as I can see, still end up baking in the secrets in the docker image.
Sure, they are not committed in git/vcs, but if I get the docker image, I can see the secrets in it. Which in my case is not acceptable.

---

I ended up using $env/dynamic/* everywhere.
But I had to add "fallbacks":

Basically, added this code as early as possible:

try {
  const { env: dynamicEnv } = await import("$env/dynamic/private");
  const staticEnv = await import("$env/static/private");
  // Iterate these objects as PUBLIC_ vars are split out already
  Object.keys(staticEnv ?? {}).forEach(k => dynamicEnv[k] ??= process.env[k] ?? staticEnv[k])
  // ^^^ SAME for public vars
} catch () {}

The process.env[k] part is necessary if loading config with a call like dotenv.config({ path: ".env.local" });.
That is because that call will only load values in process.env and none of the $env modules.

---

Separately, because I didn't want to update the usages everywhere in code to be prefixed with env., I used destructuring right after the import statement:

import { env } from "$env/dynamic/private";
const {
	API_KEY,
} = env;

I wish I didn't have to do this :(
But $env/static/ is immutable.
And cannot destructure as part of the import statement itself, as far as I know.

[ryanovas]

The way environment variables seem to be handled in sveltekit is very odd to me because it almost forces you to bake all your env vars and secrets right into the build, which is kind of a big nono for both security and the ability to reuse Docker images in different environments...

For example, if I wanted to have an automated pipeline that deploys a docker image to a staging environment, run e2e tests on it, then take that same image and deploy it to production I can't - I'm forced to rebuild the entire image and inject a different set of variables right into the container.

Also, if anyone got a hold of my container all the secrets are cached in the build.

On top of all that, I still have to use dotenv in order to build/deploy the images since the node adapter doesn't seem to support env vars out of the box, so we're not even getting huge value from using this built-in version of env var handling?

I don't understand why we have regressed on a solved problem here? Why can't we have a simple interface to get an env var from a .env first then fallback to process.env on the backend, and do the same but pre-render public env vars for the front end? I don't understand why they have to be considered extra network cost when none of the other variables that sveltekit is pre-rendering are? It kind of just seems like the authors like .env files and want to force us to use them? It kind of seems like the only solution here is to use dynamic env vars and eat whatever this extra network cost is on the front end...