Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-20 14:43:37 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #1725] [FEAT]: adjustable .env file location #1127

New Issue
Open
opened 2026-02-22 18:23:14 -05:00 by yindo · 8 comments
yindo commented 2026-02-22 18:23:14 -05:00
Owner
Copy Link
Copy Source

Originally created by @mdvertola on GitHub (Jun 19, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1725

What would you like to see?

I am currently deploying anythingllm with AWS CDK into ECS fargate using the base image available for anythingllm in dockerhub. I also create an EFS mount to the container at /app/server/storage but since .env gets modified/created on the first startup walkthrough menu, each time I update anythingllm it goes into a state where my customization settings such as custom image persist across the update but all accounts that were created are no longer valid and return Error: Could not validate login.

Based on some local testing, I am able to upgrade without losing login access as I do with my cloud deployments. I believe that this behavior is happening because i am unable to also persist the /app/server/.env location across deployments as i can only mount directories to these fargate containers, not files themselves.

It would be super helpful if i could pass an environment variable into the docker container such as ENV_FILE_PATH so that i could point this to /app/server/storage/.env and persist the environment file along with all app storage data in one directory and one mount.

I am not sure if this is possible or if there may be a better approach but adding this or something similar that only requires mounting a directory rather than a directory and file may open the door to some really simple, cheap, scalable and flexible deployment models with! Would love to contribute the CDK ECS Fargate deployment model to this repo if this can get added!

Originally created by @mdvertola on GitHub (Jun 19, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/1725 ### What would you like to see? I am currently deploying anythingllm with AWS CDK into ECS fargate using the base image available for anythingllm in dockerhub. I also create an EFS mount to the container at `/app/server/storage` but since `.env` gets modified/created on the first startup walkthrough menu, each time I update anythingllm it goes into a state where my customization settings such as custom image persist across the update but all accounts that were created are no longer valid and return `Error: Could not validate login.` Based on some local testing, I am able to upgrade without losing login access as I do with my cloud deployments. I believe that this behavior is happening because i am unable to also persist the `/app/server/.env` location across deployments as i can only mount directories to these fargate containers, not files themselves. It would be super helpful if i could pass an environment variable into the docker container such as `ENV_FILE_PATH` so that i could point this to `/app/server/storage/.env` and persist the environment file along with all app storage data in one directory and one mount. I am not sure if this is possible or if there may be a better approach but adding this or something similar that only requires mounting a directory rather than a directory and file may open the door to some really simple, cheap, scalable and flexible deployment models with! Would love to contribute the CDK ECS Fargate deployment model to this repo if this can get added!
yindo added the enhancementDockerfeature request labels 2026-02-22 18:23:14 -05:00
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@ethyoo commented on GitHub (Jun 19, 2024):

I'm not familiar with AWS CDK or ECS, specifically, but Docker supports an env_file attribute using docker run --env-file ... or by adding the attribute to a Docker Compose file.

It looks like you can pass a list of files to environmentFiles in an ECS task definition: "This parameter maps to the --env-file option to docker run."

@ethyoo commented on GitHub (Jun 19, 2024): I'm not familiar with AWS CDK or ECS, specifically, but Docker supports an [`env_file` attribute](https://docs.docker.com/compose/environment-variables/variable-interpolation/#env-file) using [`docker run --env-file ...`](https://docs.docker.com/compose/environment-variables/set-environment-variables/#use-the-env_file-attribute) or by [adding the attribute to a Docker Compose file](https://docs.docker.com/compose/compose-file/05-services/#env_file). It looks like you can pass a list of files to `environmentFiles` in [an ECS task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment): "This parameter maps to the --env-file option to docker run."
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 19, 2024):

@ethyoo I think that CLI arg only specifies a file for which docker to load ENVs from, which in general would work, but the issue would be persistence since the system does write back changes in ENV params from the app back to a file - which i believe if the primary ask. The changes are written, but the changes are then destroyed when the ephemeral container storage is killed.

@timothycarambat commented on GitHub (Jun 19, 2024): @ethyoo I think that CLI arg only specifies a file for which docker to load ENVs from, which in general would work, but the issue would be persistence since the system does write back changes in ENV params from the app back to a file - which i believe if the primary ask. The changes are written, but the changes are then destroyed when the ephemeral container storage is killed.
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@ethyoo commented on GitHub (Jun 19, 2024):

I think that goes back to best practices for persistent storage and choosing storage options for Amazon ECS tasks.

@ethyoo commented on GitHub (Jun 19, 2024): I think that goes back to [best practices for persistent storage](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/storage.html) and choosing [storage options for Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html).
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@mdvertola commented on GitHub (Jun 19, 2024):

Yes @timothycarambat you hit it right on the head. Apologies if not entirely clear on my end @ethyoo.

Based on @timothycarambat & @ethyoo's discussion would it be worth reframing the goal of this issue towards separating environment variables/files (defined as those that must be set at time of deployment and remain constant throughout a deployment) from application configuration variables/files (defined as those set or changed during application usage).

In other words, what if we move all of the configurations that are either set during the initial setup walkthrough screens or when users make changes to admin settings away from writing to the .env file and into a configuration file inside of /app/storage?

Slightly echoing what @timothycarambat mentioned earlier is that I think the core problem I am trying to solve for here is that anythingllm is writing back to that .env file which is creates a more difficult situation to try to build around.

@mdvertola commented on GitHub (Jun 19, 2024): Yes @timothycarambat you hit it right on the head. Apologies if not entirely clear on my end @ethyoo. Based on @timothycarambat & @ethyoo's discussion would it be worth reframing the goal of this issue towards separating environment variables/files (defined as those that must be set at time of deployment and remain constant throughout a deployment) from application configuration variables/files (defined as those set or changed during application usage). In other words, what if we move all of the configurations that are either set during the initial setup walkthrough screens or when users make changes to admin settings away from writing to the `.env` file and into a configuration file inside of `/app/storage`? Slightly echoing what @timothycarambat mentioned earlier is that I think the core problem I am trying to solve for here is that anythingllm is writing back to that .env file which is creates a more difficult situation to try to build around.
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jun 19, 2024):

Among other places where the ENV is loaded we can start with modifications here:
https://github.com/Mintplex-Labs/anything-llm/blob/421c5c6b91110f9386ffe83d7e4a563f3baae244/server/utils/helpers/updateENV.js#L800

@timothycarambat commented on GitHub (Jun 19, 2024): Among other places where the ENV is _loaded_ we can start with modifications here: https://github.com/Mintplex-Labs/anything-llm/blob/421c5c6b91110f9386ffe83d7e4a563f3baae244/server/utils/helpers/updateENV.js#L800
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@aprt06 commented on GitHub (Jul 15, 2024):

Hi @mdvertola If you mount to the container at /app/server/storage In this case for me I use symlink command in my deployment file k8s
this is just link .env file from persistence to pods
rm /app/server/.env
ln -s /app/server/storage/.env /app/server/.env

@aprt06 commented on GitHub (Jul 15, 2024): Hi @mdvertola If you mount to the container at /app/server/storage In this case for me I use symlink command in my deployment file k8s this is just link .env file from persistence to pods ` rm /app/server/.env ` `ln -s /app/server/storage/.env /app/server/.env`
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@stguitar commented on GitHub (Oct 18, 2024):

I just ran into this as well. I'm using GKE, and I was mounting the persistence storage volume at /storage. I could see by inspecting the sqlite database that my workspaces and things were being saved there. Based on this thread, i changed my mount point to /app/server/storage instead, and now when the new container starts up, it successfully uses my existing attached volume and data, not resetting the environment on update.

I am able to attach a read/write vol though, which sounds like maybe part of @mdvertola issue?

@stguitar commented on GitHub (Oct 18, 2024): I just ran into this as well. I'm using GKE, and I was mounting the persistence storage volume at `/storage`. I could see by inspecting the sqlite database that my workspaces and things were being saved there. Based on this thread, i changed my mount point to `/app/server/storage` instead, and now when the new container starts up, it successfully uses my existing attached volume and data, not resetting the environment on update. I am able to attach a read/write vol though, which sounds like maybe part of @mdvertola issue?
yindo commented 2026-02-22 18:23:14 -05:00
Author
Owner
Copy Link
Copy Source

@stguitar commented on GitHub (Oct 18, 2024):

ill add it seemed odd that the application seems to write fine to the storage directory mounted at an arbitrary location, but the startup procedure seems to be isolated to /app/server/storage/

@stguitar commented on GitHub (Oct 18, 2024): ill add it seemed odd that the application seems to write fine to the storage directory mounted at an arbitrary location, but the startup procedure seems to be isolated to `/app/server/storage/`
yindo changed title from [FEAT]: adjustable .env file location to [GH-ISSUE #1725] [FEAT]: adjustable .env file location 2026-06-05 14:39:07 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label Docker enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#1127
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?