Community App - required environment variables?

[ekevu123]

I have successfully created a working CloudronVersions.json: https://github.com/Tymeslot/tymeslot/blob/main/CloudronVersions.json

However, my app requires some environment variables to be startable. At the moment, the installation crashes until the user sets them and restarts the app afterwards.

Is there any way to handle this?

[robi]

Do any placeholder vars prevent the crash?

[fbartels]

In your documentation i found this

‘ SECRET=$(openssl rand -base64 64 | tr -d '\n')\ncloudron env set --app tymeslot.yourdomain.com \\n SECRET_KEY_BASE=$SECRET \\n PHX_HOST=tymeslot.yourdomain.com \\n PORT=4000’

Information like the domain are exposed by Cloudron already. https://docs.cloudron.io/packaging/cheat-sheet#environment-variables

[ekevu123]

Correct, but I'd still need to set a secret key, which is used for encryption. If I generate it automatically like that, wouldn't it be regenerated with every update or even app restart, which we should avoid?

For my version, I set it via cloudron env set, but this means the user would need to do the same.

[robi]

There are many packaged apps that do this as a first run setup then not.

You can check for logs, unique config signatures, db entry, .first_run file or other hints first run and setup is done.

[ekevu123]

But how do I do this for a secret key? I could generate it upon first run, but wouldn't it be regenerated then when updating, which shouldn't happen?

[fbartels]

As Robi is already saying. You can have a look at how other apps are doing this at https://git.cloudron.io/packages. A simple example is at https://docs.cloudron.io/packaging/cheat-sheet#one-time-ini as well.

The important thing is that you are creating this file inside of /app/data so that it is part of the persistent and backed up data

[timconsidine]

@ekevu123
if you have a startup.sh or other launch script, it is common to have the script touch /app/data/initialized during first setup, all setup inside a test whether .initialized is present or not.
If so, skip setup.
If not, then do setup.
Setup including key generation.

I haven't reviewed how you launch the app, so not sure how viable it is for you, but it's very common for other apps.

---

if [ ! -f /app/data/.initialized ]; then
  cp -a -n /app/code/defaults/config/. /app/data/config/ || true
  touch /app/data/.initialized
fi