starred/anything-llm

Fork 0

mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-03-02 22:57:05 -05:00

[FEAT]: adjustable .env file location #1138

New issue

Open

opened 2026-02-28 05:16:50 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 05:16:50 -05:00

Owner

Originally created by @mdvertola on GitHub (Jun 19, 2024).

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). ### 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!

deekerman added the

enhancement

Docker

feature request

labels

2026-02-28 05:16:50 -05:00

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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."

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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.

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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).

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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.

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

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

Among other places where the ENV is loaded we can start with modifications here:
github.com/Mintplex-Labs/anything-llm@421c5c6b91/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

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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`

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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?

deekerman commented

2026-02-28 05:16:56 -05:00

Author

Owner

@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/`

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anything-llm#1138

No description provided.

Rows
Columns