# understanding env var handling of zinit **URL:** \ **Category:** ThreeFold Technology\ **Created:** [December 29, 2025, 7:17am UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674 "2025-12-29T07:17:21Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![torstello](https://staging.forum.threefold.io/letter_avatar_proxy/v4/letter/t/3ec8ea/32.png) [@torstello](https://staging.forum.threefold.io/u/torstello)\ **Post date:** [December 29, 2025, 7:17am UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/1 "2025-12-29T07:17:22Z")
after reading / learning from the following sources: [Case Study: Nextcloud AIO | ThreeFold Manual](https://manual.grid.tf/labs/documentation/developers/flist/flist_case_studies/flist_nextcloud_case_study) [zinit/docs/services.md at master · threefoldtech/zinit · GitHub](https://github.com/threefoldtech/zinit/blob/master/docs/services.md) [zos\_images/tfgrid3/nextcloud at development · threefoldtech/zos\_images · GitHub](https://github.com/threefoldtech/tf-images/blob/development/tfgrid3/nextcloud) it still not clear for me how/when/where the environment variables are actually set that the zinit process and `/scripts/*.sh` use. In the case of the official nexcloud-aio flist/lab for example i see ```auto # cat /etc/zinit/caddy.yaml exec: /scripts/caddy.sh oneshot: true ``` no varialbe is set with the `env` parameter in the zinit yaml file. but the referenced script (/scripts/caddy.sh) uses several env vars like `$NEXTCLOUD_DOMAIN, $IPV4, $GATEWAY` so where are these values actually defined? The file within the lab deployment (/etc/caddy/Caddyfile) also has `{$DOMAIN}:{$PORT}` in it. ---
**Author:** ![yadalamahendra](https://staging.forum.threefold.io/user_avatar/staging.forum.threefold.io/yadalamahendra/32/822_2.png) [@yadalamahendra](https://staging.forum.threefold.io/u/yadalamahendra)\ **Post date:** [December 29, 2025, 7:21am UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/2 "2025-12-29T07:21:08Z")
Hi @scott & @Mik , your insight would be appreciated. Thank you. ---
**Author:** ![scott](https://staging.forum.threefold.io/user_avatar/staging.forum.threefold.io/scott/32/604_2.png) [@scott](https://staging.forum.threefold.io/u/scott)\ **Post date:** [December 29, 2025, 11:30pm UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/3 "2025-12-29T23:30:36Z")
Our micro VMs, which are used for all Labs deployments, are inspired by containers. Any environment variables set at the time of deployment are exported into the environment of the PID 1 that gets started when the VM boots. In the case of our official images, that will be `zinit`. From there, `zinit` also exports its environment to all of the processes that it spawns. So environment variables set on the deployment get automatically passed down to the various services. As for Caddy, it supports using environment variables directly in the Caddyfile. So if a variable is set in the environment of Caddy when it launches, it will substitute that value into the Caddyfile. ### Demo with Docker Our micro VM images come from Docker images, and we can use Docker to quickly demonstrate the overall concept. In the first shell I just start the container and let it run (this will kick off `zinit`): ![image](https://staging.forum.threefold.io/uploads/default/original/2X/c/c7b9f76fa31f051d9bba045cf6be00957a710299.png) Then in a second shell I connect to the container and demonstrate how a simple `zinit` service accesses the environment variable: ![image](https://staging.forum.threefold.io/uploads/default/original/2X/2/2537ecd2cb86cad1afa1eaf16e86cfcfb8b215f1.png) Whereas with Docker we use `--env` to set the variable value, in our VMs we set them via the deployment tool or SDK. ---
**Author:** ![torstello](https://staging.forum.threefold.io/letter_avatar_proxy/v4/letter/t/3ec8ea/32.png) [@torstello](https://staging.forum.threefold.io/u/torstello)\ **Post date:** [December 30, 2025, 12:30pm UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/4 "2025-12-30T12:30:59Z")
thanks a lot for the explanation, very much appreciated! that brings me much closer to develop my own flist(s). ---
**Author:** ![scott](https://staging.forum.threefold.io/user_avatar/staging.forum.threefold.io/scott/32/604_2.png) [@scott](https://staging.forum.threefold.io/u/scott)\ **Post date:** [December 30, 2025, 6:36pm UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/5 "2025-12-30T18:36:22Z")
My pleasure! Let me know if I can answer any other questions. ---
**Author:** ![torstello](https://staging.forum.threefold.io/letter_avatar_proxy/v4/letter/t/3ec8ea/32.png) [@torstello](https://staging.forum.threefold.io/u/torstello)\ **Post date:** [December 30, 2025, 9:29pm UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/6 "2025-12-30T21:29:29Z")
ok )) - Could you explain why the zinit repo is now archived (read only)? [GitHub - threefoldtech/zinit: A init replacement that feels like runit written in rust+tokio · GitHub](https://github.com/threefoldtech/zinit) - Will there be any (big) changes for the (micro-) vm deloyments in the next grid version (v4)? - do i understand [the documentation](https://manual.grid.tf/labs/documentation/dashboard/deploy/vm_intro/vm_differences) right, that the micro vm is run as a linux container and the full vm on a (xen or other) hypervisor? - Then the nextcloud (aio) lab deployment runs on a micro vm (b/c it’s based on a flist); but in this case the nc-aio mastercontainer downloads and starts/administers multiple other containers. That would mean there is a docker install within an already running (docker) container? I’m especially interested in the nc deployment b/c i would (for example) like to also mount an additional backup disk but there’re no further config options when using the official lab deployment. ---
**Author:** ![scott](https://staging.forum.threefold.io/user_avatar/staging.forum.threefold.io/scott/32/604_2.png) [@scott](https://staging.forum.threefold.io/u/scott)\ **Post date:** [December 30, 2025, 11:26pm UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/7 "2025-12-30T23:26:40Z")
> [@torstello](#): > > Could you explain why the zinit repo is now archived (read only)? > [GitHub - threefoldtech/zinit: A init replacement that feels like runit written in rust+tokio · GitHub](https://github.com/threefoldtech/zinit) We are migrating to a self hosted git forge. Zinit can be found here now: [Making sure you're not a bot!](https://forge.ourworld.tf/geomind_code/zinit) > [@torstello](#): > > Will there be any (big) changes for the (micro-) vm deloyments in the next grid version (v4)? This is still a work in progress, but I think we’ll have similar support for the micro VM images like we use in v3. > [@torstello](#): > > - do i understand [the documentation](https://manual.grid.tf/labs/documentation/dashboard/deploy/vm_intro/vm_differences) right, that the micro vm is run as a linux container and the full vm on a (xen or other) hypervisor? > - Then the nextcloud (aio) lab deployment runs on a micro vm (b/c it’s based on a flist); > but in this case the nc-aio mastercontainer downloads and starts/administers multiple other containers. That would mean there is a docker install within an already running (docker) container? Micro VMs are VMs. The connection to Docker comes from: 1. The fact that we support converting Docker images to our VM image format 2. Some aspects are in the spirit of containers, like the environment variables and entrypoint settings A micro VM is provided with a generic kernel by Zos. Thus the image doesn’t need to contain a kernel (it can be as small as a single binary, just like a container). Zos also provides a small initramfs that does a couple things like setting up the disks and the networking before launching the entrypoint. So Docker can run fine inside a micro VM, with a [caveat](https://staging.forum.threefold.io/t/how-to-use-docker-in-threefold-vms/4583) about where the data is stored. > [@torstello](#): > > I’m especially interested in the nc deployment b/c i would (for example) like to also mount an additional backup disk but there’re no further config options when using the official lab deployment. There are a couple of ways to customize the deployment. One would be to use the micro VM deployment flow in the dashboard and fill in the env variables manually. Then you could add the additional disk. Another would be to use Terraform with the official flist image (if this interest you I can provide a template). I think adding and using a backup disk should work fine without needing to customize the flist actually. ---
**Author:** ![torstello](https://staging.forum.threefold.io/letter_avatar_proxy/v4/letter/t/3ec8ea/32.png) [@torstello](https://staging.forum.threefold.io/u/torstello)\ **Post date:** [December 31, 2025, 9:49am UTC](https://staging.forum.threefold.io/t/understanding-env-var-handling-of-zinit/4674/8 "2025-12-31T09:49:33Z")
Thanks again for the explanation! Yes, please share a terraform template, should be similar to the one [in the documentation](https://manual.grid.tf/labs/documentation/system_administrators/terraform_toc/terraform_full_vm).