Custom Server environment variable
I have tried adding a new custom server env variable. Refer to below.
import { env } from 'wasp/server'
console.log(env.SOME_VAR_NAME)
But when I tried to use env.MY_CUSTOM_VAR
It seems to not recognize it. What do I have to do?
4 Replies
Wohooo @yj69, you just became a Waspeteer level 1!
Hi @yj69. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
To use a custom server environment variable in Wasp, you should:
1. Add your variable to
Use
.env.server
at the root of your project, for example:
2. Access it in your server code using process.env.MY_CUSTOM_VAR
:
The knowledge sources do not mention an env
object exported from 'wasp/server'
that would automatically include your custom environment variables. Instead, the documented way is to use process.env
directly for server-side variables Docs: Env Variables.
3. Note: The config
object from 'wasp/server'
only exposes certain built-in configuration fields (like frontendUrl
), not arbitrary custom environment variables Docs: Accessing the configuration.
So, to summarize:Use
process.env.MY_CUSTOM_VAR
in your server code to access your custom environment variable. If you try to use env.MY_CUSTOM_VAR
from 'wasp/server'
, it will not work because this is not supported according to the current documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @yj69, 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?Hey, @yj69 this is a bit unclear from the docs (sorry about that, we have an issue to work on this!) - but you need to defined the env validations like this: https://wasp.sh/docs/project/env-vars#custom-env-var-validations
Then you'll get them exposed on the
env
object 🙂Env Variables | Wasp
Environment variables are used to configure projects based on the context in which they run. This allows them to exhibit different behaviors in different environments, such as development, staging, or production.
Thanks!