[Bug]: Wrong options appear on admin panel on self hosted version

[rhuanbarreto]

Is there an existing issue for this?

• [X] I have searched the existing issues

Description

When deploying Appsmith using a self hosted version in docker (without a volume) and configuring a list of environment variables like:

• APPSMITH_MONGODB_URI
• APPSMITH_MAIL_ENABLED
• APPSMITH_ADMIN_EMAILS
• APPSMITH_SIGNUP_ALLOWED_DOMAINS
• APPSMITH_MAIL_FROM
• APPSMITH_REPLY_TO
• APPSMITH_MAIL_HOST
• APPSMITH_MAIL_PORT
• APPSMITH_MAIL_SMTP_TLS_ENABLED
• APPSMITH_MAIL_USERNAME
• APPSMITH_MAIL_PASSWORD

The values don't appear in the admin panel. Instead other values appear or fields are even empty.

In my case I wanted to test the email functionality and couldn't send a test email because the configs were not appearing there.

I expected the values to appear in the UI in read-only mode once they are set in an environment and shouldn't change once the storage is ephemeral.

Steps To Reproduce

• Deploy appsmith using docker compose
• Set environment variable values
• Access the admin panel
• Values will not appear there

Public Sample App

No response

Environment

Production

Issue video log

No response

Version

Self Hosted v1.9.15

Front conversations

[sharat87]

Hey @rhuanbarreto, when you say

configuring a list of environment variables

Do you mean these env variables are set in your docker-compose.yml file, or some other such external configuration? If yes, then this is unfortunately expected. What the Admin Settings currently shows is the values from the stacks/configuration/docker.env file. But these can be overridden by setting external env variables, like in a docker-compose.yml, or with docker run -e.

This is a known issue, and we are working towards a solution by moving such configuration from env variables to the database, so there's one source of truth for them.

[rhuanbarreto]

yes it's set as environment variables.

I see this solution of saving those configurations in the database or in a file with skepticism. Security-wise, a database or a file can be exfiltrated by any malicious agent. And environment variables are normally protected/encrypted in memory to avoid that.

Also, storing configuration breaks the twelve-factor app principle https://12factor.net/config

[sharat87]

Hey @rhuanbarreto, thanks for sharing. I'm a big fan of 12factor, and I'd so not break it with this. 🙂

Let me explain. We're not moving any and all env variables, that'd even be impossible, like, the DB URI at least should be an env variable... we can't get that from the DB! So, what we're moving, is configuration env variables. This allows us to improve the experience by not having to restart when changes are applied, running multi-tenant instances of Appsmith, and even store these configurations in encrypted form in the database.

[rhuanbarreto]

Yes. But at the same time, for the ones deploying single tenant instances of Appsmith, it's very important to set configurations like SSO, SMTP, license, sentry, signin options like admin emails through environment variables so those things don't need to be configured as state in the DB and can be easily deployed in the case of a disaster recovery where the DB just corrupted.

So having this written in the documentation that if you change the environment variables you need to restart the instance, is already good enough.

Also making sure precedence is respected is important. If environment variables are set, they should overrule the DB configs and disable any inputs in the admin config in the frontend.