Which environment variables are used by each container?
Hello, I'm trying to figure out which environment variables are used by each containers, but I don't see them anywhere documented (only what they do, but not which continer makes use of them).
What I'm trying to accomplish:
I want each container to have exactly the info it needs, no more no less.
For example, I don't think the proxy needs the database credentials.
Is there somewhere I can get this info?
Thanks
51 Replies
There is no good documentation of this yet, it's one of the things we've been putting off unfortunately
I don't mind looking into the code, assuming that for each service/container there is a "config init" file.
If there is such thing, can you point me to it?
The best way is to just do a search for
process.env. that will show most of the variables.Thanks
I'll see if I can create a small
.md file with a table.
And you can update/fix/extend it afterwardsIt would be great to add a section to the docs.
Sounds good!
In the
docs/ folder you can run the docs locally and they work with .md files. You could add a new section under administration for Environment Variables
We can help correct and update them if you put together an initial draft. I'd also like to simpliy/consolidate this and whitelist the specific env variables in the compose files as well.
I'm thinking something like
| env | description | default | services |
Nitpick but under the install section might be a better spot?
Administration is mostly concerned with things in the UI
Fair enough, yeah that's probably better.
I'd also love to delete all the comments from the example.env and all the other places they show up (copied) in the docs.
Yeah absolutely, I'd love for all that documentation to be in this new page instead
Yes, just link to the new page instead.
So the example.env is only the vars that are strictly required, and nothing else
I suppose server + microservices use the same envs right?
Mostly yes, I think there may be a handful that are different though?
There is a port one specific to each
Cool I'll keep an eye
Both use
NODE_ENV, DB*, REDIS*, TYPESENSE*
Both use IMMICH_MEDIA_LOCATION and IMMICH_MACHINE_LEARNING_URLand
TZ ?That's just for testing
Some unit tests would fail depending on what timezone you were running them in 😛
I see it's added in the FAQ
https://immich.app/docs/FAQ#why-does-my-uploaded-photo-show-up-with-the-wrong-date-or-time-in-immich
FAQ | Immich
What is the difference between the cloud icon on the mobile app?
REVERSE_GEOCODING* is only used in microservices I believe
TZ is not specific to immichYea it's system specific, but for example microsservices use it, if I'm understanding correctly
No we don't.
We use exiftool to extract metadata and it uses the time zone of the container as a fallback in some situations.
Microservices uses exif tool and exif tool uses TZ in some situations. If you want to document that, that's fine with me.
It's not an "immich" envirionment variable in my opinion if we don't ever read it and do something based it being set to something.
But it's worth noting we use certain tools which can be configured with their own environment variables, which should have their own documentation somewhere.
This an initial draft so far.
Categories can be added for those tools
(Description could be expanded later)
TZ does not default to UTC by default
Or we can remove the description from the table
And have after each section (
##), subsections (###) for each env with a longer description
And instaeld of description on the table we have a Required column with yes/no valueI think different sections is good for groups of stuff, but tables for the actual envs like you have them for redis, typesense, etc. is good.
Is mapbox removed? I can only find refs in a
.env.test fileIndeed
Cool, I'll clean it up too
Awesome stuff!
Is the
JWT_SECRET removed?A few notes from my first look through:
REVERSE_GEOCODING_DUMP_DIRECTORY can be moved to Paths, and that section might want a general note that these are all paths internal to the container?
If DB_URL is set, none of the other DB_* vars are used. I'm not sure whether this also applies to the redis or typesense settings (can't check rn).JWT secret is not used anymore.
Yes - if redis url is provided the rest of them are ignore. If typesense url is provided the rest of the are ignored.
Yep pushed some updates regarding those!
Do you know what happens with redis_socket?
It can be used to specify a socket?
We can link to redis io documentation for details on each one
I mean, does it prefer socket if both hostname and socket is defined?
https://ioredis.readthedocs.io/en/latest/API/
Local domain socket path. If set the port, host and family will be ignored.
awesome
I think all the reverse geocoding stuff should be in one section
If you look at the deployment you have some misc ` symbols
https://immich-136b3d57o-immich.vercel.app/docs/install/environment-variables
Hmm looks like double ` is not intepreted as empty.
For empty defautls should we keep the field empty or for example
-Just don't put a value in it
Are you running the docs locally?
Not yet, just trying to get the info there and then work on formatting
It auto-refreshes on save
You can use
:::info and :::tip
I'm off for today! Will do some more tomorrow!
Cya
fwiw I had to go through this process manually as I write all my own Kubernetes manifests
https://github.com/uhthomas/automata/tree/6aebeea4d3bd66c47aa0eb2d8a1dbacdc23a9b71/k8s/unwind/immich
Would be good to compare
Thanks! From a quick look seems that everything looks ok!
Cool! Thanks for checking