client app env vars at run time vs build time
Hi, im trying to deploy a wasp application to a self hosts kubernetes cluster that could potentially have multiple environments so im not too keen on settings any client side env vars on build/ci for example here: https://wasp.sh/docs/deployment/deployment-methods/paas#3-deploying-the-web-client-
does anyone have any suggestions to configure this? im thinking to run the npm build on container runtime
Platform as a Service (PaaS) | Wasp
This document explains how to build and prepare your Wasp app for deployment.
2 Replies
Hi @Kofi_anan. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Wasp client-side environment variables are embedded into the client code at build time, not at runtime. This means that any variables you want available in your React frontend must be set before or during the build process (e.g., with
- Client env vars are embedded at build time, not runtime. - You must set them before/during the build (e.g., in your CI/CD pipeline or by building in the container at startup). - There is no built-in Wasp support for runtime injection of client env vars after the build. If you need true runtime configurability, you would need to implement a custom solution (e.g., fetching config from an endpoint at runtime), but this is outside the standard Wasp workflow and not covered in the official docs. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Kofi_anan, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
REACT_APP_SOME_VAR_NAME=somevalue npm run build). After the build, these values are hardcoded into the static files and cannot be changed at runtime by simply setting environment variables in the container or Kubernetes pod.
This is a limitation of how Vite (the build tool Wasp uses) and most modern frontend frameworks work: environment variables are replaced during the build, not dynamically loaded at runtime. The Wasp documentation and community discussions confirm this approach and clarify that you cannot inject or change client env vars after the build step, even if you set them in your container or Kubernetes environment at runtime. You must provide them to the build command itself, for example:
If you want to have different client env vars for different environments (e.g., dev, staging, prod) in Kubernetes, you would need to trigger a new build for each environment, embedding the appropriate values at build time. Running the build inside the container at runtime (i.e., building the frontend as part of the container startup) is technically possible, but it's not a common or recommended practice for production deployments, as it increases startup time and complexity. However, if you need this flexibility, you could design your container to run the build step on startup, using environment variables passed to the container at that time.
For more details, see:
- Wasp docs: Defining Env Vars in Production
- Wasp docs: Client Env Vars
- Discord discussion: client env vars on Fly.io
Summary:- Client env vars are embedded at build time, not runtime. - You must set them before/during the build (e.g., in your CI/CD pipeline or by building in the container at startup). - There is no built-in Wasp support for runtime injection of client env vars after the build. If you need true runtime configurability, you would need to implement a custom solution (e.g., fetching config from an endpoint at runtime), but this is outside the standard Wasp workflow and not covered in the official docs. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Kofi_anan, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
As the bot said, we embed the env vars in the client (and some in the server) at build time, so your safest bet for now is to run a build for each different environment you need.