What's the difference between "dynamic" and "static" env variables in SvelteKit?

[aradalvand]

I can't quite figure this out, I wish the documentation made this a little more clear.

I'm struggling to understand the difference between "dynamic" and "static" environment variables in SvelteKit (imported from $env/dynamic/... and $env/static/... respectively) and more importantly under which circumstances I should prefer one over the other.

So for example, my SvelteKit app acts as my frontend and then I also have a backend server (written in a different programming language) acting as the API which the frontend talks to. Now, I'd like to use the handleFetch hook to replace the public URL of my API with a local one whenever a server-side fetch request is being sent to the API (in order to hit it directly and bypass any proxies, as per the example here) so I need to have two environment variables PUBLIC_API_URL and LOCAL_API_URL — which would obviously have different values in production and development — but I'm not sure if I'm supposed to use $env/dynamic or $env/static in a case like this.

I'd appreciate it someone enlightens me here.

[theetherGit]

$env/dynamic/private

• This give you access to process.env parameters on the basis of adapters which means it depends on your deployment too.
• For eg. you can access 'NODE_ENV', which is a node parameter.
• You can't use this on client side code. server side only.

$env/static/private

• This give you access to process.env parameters and .env parameters without PUBLIC_ prefix using vitejs.
• This will be statically injected to your code on build time while $env/dynamic/private won't be.

$env/dynamic/public

• It include all PUBLIC_ prefixed .env parameters.
• Here it will send all the PUBLIC_ parameters in request to client side.
• Using it is little bit harmful because it will make request more big.

$env/static/public

• It's same as $env/dynamic/public but here all the .env parameters will be injected to code on build time.

Sveltekit also mentioned that prefer using public static env for static parameters because this will make requests smaller.

As per your query you wanna replace your request api which will be done on client because you are using handle fetch so you can use PUBLIC_API_URL using $env/static/public.

Make sure if you are using any .env parameters in client code always use PUBLIC_ prefix this will allow to expose it to client otherwise it won't be accessible on client.

[mynthon]

Great answer, but maybe you can explain to me why is $env/dynamic/private the only method that skips variables from .env? And as I understood correctly "dynamic" methods are the only option when ENVIRONMENT variables are not accesible during buid time?

[benmccann]

Static variables get replaced at build time and dynamic variables get replaced at runtime. Static variables allow compile-time computations which can give better performance - e.g. if they're used in an if condition which contains expensive code inside such as a dynamic import. But for the most part the question is really just about when you want to set the variable - buildtime or runtime.

[theetherGit]

Thank you so much ☺️

[ioucyf]

So for sensitive env variables, such as api keys etc, is one more recommended to use than the other? Or do both dynamic/private and static/private are considered just about the same -security-wise?

[benmccann]

Yes, they're both private from a security perspective

[zerosym]

I know this is an old topic but I was hoping someone could clear this up for me. I'm still confused over the documentation (and replies here even) about preferring $env/static/private over $env/dynamic/private. I understand that using static could potentially remove some unneeded code at build time, but from a security perspective I'm baffled at this recommendation or the suggestion that they are even remotely equivalent.

A direct example from https://learn.svelte.dev/tutorial/env-static-private

<script>
	import { PASSPHRASE } from '$env/static/private';
	export let form;
</script>

From https://learn.svelte.dev/tutorial/env-dynamic-public

As with private environment variables, it's preferable to use static values if possible, but if necessary we can use dynamic values instead:

Isn't it an accepted practice to keep secrets out of builds such as docker images? You wouldn't go committing unencrypted secrets to your Github repos, so why would you have them statically injected into your code at build time? In this containerized era builds are commonly done in CI/CD pipelines and then shipped off as images to the deployment platforms, hence the whole industry around providing secure storage of secrets (Vault, SOPS, etc.) aimed at injecting them at run time...

Additional:
How Nuxt handles envs:

runtimeConfig vs app.config

As stated above, runtimeConfig and app.config are both used to expose variables to the rest of your application. To determine whether you should use one or the other, here are some guidelines:

runtimeConfig: Private or public tokens that need to be specified after build using environment variables.

app.config: Public tokens that are determined at build time, website configuration such as theme variant,
title and any project config that are not sensitive.

To put it simply, I believe static/private is a contradiction in itself -- any truly private configuration should not be directly compiled into the code at build time. The docs do not provide any legitimate example (in my view) of a valid usage for static/private yet pushes it over dynamic/private.