Environment File Resets After Application Restart

[halkhamis]

Hello Cloudron Support,

I have deployed FreeScout on Cloudron and I am experiencing an issue with the .env file configuration.

Whenever I modify the .env file and restart the application (or the app restarts automatically), all changes are discarded and the .env file is reset back to the default configuration.

This behavior prevents persistent configuration changes and makes it difficult to manage custom environment settings.

Steps to reproduce:

Open the app terminal / filesystem.
Modify values in the .env file.
Restart the application.
Observe that the .env file is reverted to the default state.

Expected behavior:

Changes made to the .env file should persist after application restarts.

Actual behavior:

The .env file is overwritten/reset during restart.

Could you please advise:

Whether this is expected behavior in the Cloudron FreeScout package.
The correct method/location for persisting custom environment variables.
If there is a supported way to prevent the .env file from being regenerated.

Thank you.

[james]

Hello @halkhamis

@halkhamis said:

Changes made to the .env file should persist after application restarts.

Yes and No.
It depends on the environment variables you are looking to override.
Certain variables are configured on every app restart by Cloudron to ensure the app is working.

For example these variables are always set - https://git.cloudron.io/packages/freescout-app/-/blob/master/start.sh?ref_type=heads#L51-L60

echo "=> Set configs"
crudini --set /app/data/env "" APP_URL "${CLOUDRON_APP_ORIGIN}"
crudini --set /app/data/env "" APP_FORCE_HTTPS "true"
crudini --set /app/data/env "" DB_CONNECTION "mysql"
crudini --set /app/data/env "" DB_HOST "${CLOUDRON_MYSQL_HOST}"
crudini --set /app/data/env "" DB_PORT "${CLOUDRON_MYSQL_PORT}"
crudini --set /app/data/env "" DB_DATABASE "${CLOUDRON_MYSQL_DATABASE}"
crudini --set /app/data/env "" DB_USERNAME "${CLOUDRON_MYSQL_USERNAME}"
crudini --set /app/data/env "" DB_PASSWORD "${CLOUDRON_MYSQL_PASSWORD}"
crudini --set /app/data/env "" APP_DISABLE_UPDATING "true"

Also when the Cloudron User Management was chosen when the app was installed the following configurations will always be set - https://git.cloudron.io/packages/freescout-app/-/blob/master/start.sh?ref_type=heads#L116-L139

if [[ -n "${CLOUDRON_OIDC_ISSUER:-}" ]]; then
    echo "=> Configure OIDC"
    OAUTH_PROVIDERS=$(gosu cloudron php <<'EOF'
<?php
    echo addslashes( serialize( [
        [
            'active' => 1,
            'default' => 1,
            'provider' => "oauth",
            'name' => getenv("CLOUDRON_OIDC_PROVIDER_NAME") ?? "Cloudron",
            'id' => "cloudron",
            'client_id' => getenv("CLOUDRON_OIDC_CLIENT_ID"),
            'client_secret' => getenv("CLOUDRON_OIDC_CLIENT_SECRET"),
            'auth_url' => getenv("CLOUDRON_OIDC_AUTH_ENDPOINT"),
            'token_url' => getenv("CLOUDRON_OIDC_TOKEN_ENDPOINT"),
            'user_url' => getenv("CLOUDRON_OIDC_PROFILE_ENDPOINT"),
            'user_method' => "POST",
            'proxy' => "",
            'mapping' => "",
            'scopes' => "openid profile email"
        ]
    ] ) );
EOF
    )

So without the detail from you which exact variables you are trying to change, I can only assume they are one of the default sets of Cloudron.

[halkhamis]

The variables I changed are:

DB_CONNECTION=mysql
DB_HOST=here
DB_PORT=3306
DB_DATABASE=here
DB_USERNAME=here
DB_PASSWORD=here

[james]

Hello @halkhamis
Changing the database environment variables is currently not support and set on every start of the app.
Why do you want to change the database connection?

[halkhamis]

The reason I changed the database variables is that I’m using a managed database hosted on AWS/Azure.

[james]

Hello @halkhamis
Cloudron does manage all the requirements for apps within itself.
There is no need for an external database.
Can you maybe elaborate why you want to use an external database?

[halkhamis]

The reason I changed the database variables is that I’m using a centralized managed database hosted on AWS. It provides additional security and encryption features, along with capabilities such as Point-in-Time Recovery (PITR) for backup and disaster recovery purposes. It also offers high availability and improved reliability compared to a locally hosted database.

[james]

Hello @halkhamis
If you want to use an external database with Freescout you will have to fork the Freescout package and change it so that you can use an external database.
It sounds like you want to use enterprise and high availability features for a software that is not highly available in the first place, so the HA of the DB will offer nothing when the software is down anyway.
Cloudron also provides the security and encryption for the DB and also offers the backup and restore for the app and database itself, but not PITR.

[abo_shahad]

Mr. @james,

I have the same setup and faced a similar issue. Currently, I'm using Alibaba Cloud RDS, which provides multiple enterprise-grade features such as High Availability (HA), Disaster Recovery (DR), and Point-in-Time Recovery (PITR).

I'm planning to adopt a two-tier architecture by separating the application tier (Cloudron) from the database tier. The goal is to better separate responsibilities and specializations across the team, while also improving scalability, maintainability, and operational management.

Is there any recommended approach to achieve this without forking the package?

[ccfu]

You could install Freescout in a LAMP app, but you would lose the automatic updates.

[nebulon]

@abo_shahad this mostly will not work in the long run, as the database backups might get out of sync of the other app data stored on the local filesystem of freescout. Generally Cloudron is designed in a way where the database is part of the app so to speak, so apps can be backed up and restored fully from one system. This is especially important when some update fails. In your case with the database having different backup/restore points from the app, this will be non-trivial to restore to a working app state if an update breaks.

So as @ccfu suggests using LAMP to run freescout would work, but I am not really sure if there is much benefit using Cloudron then for this. Essentially you are "fighting" the platform instead of using its benefits.

[abo_shahad]

@nebulon
Thanks for the clarification. I understand Cloudron’s design philosophy regarding keeping the database tightly coupled with the application for consistent backups and restores.

However, in our case, the main objective of using Alibaba Cloud RDS is that the database layer is fully managed independently, including backups, HA, DR, PITR, monitoring, and recovery procedures.

From an infrastructure and security perspective, we also need a separate recovery path in case the Cloudron server itself becomes corrupted during an upgrade, suffers complete filesystem failure, or even gets impacted by ransomware attacks such as Shamoon-style destructive malware encrypting the entire server storage.

In these scenarios, having the database isolated and continuously protected on a managed RDS platform gives us a strong fallback and significantly improves resilience and disaster recovery capabilities.

Our goal here is mainly to follow infrastructure best practices by separating the application tier from the database tier, both operationally and from a security/recovery standpoint, rather than relying on a single tightly coupled host for everything.

[abo_shahad]

@ccfu "fighting" the platform is good idea

[james]

Hello @abo_shahad
I am a little curious, because you stated before:

@halkhamis said:

I’m using a managed database hosted on AWS/Azure.

and now it is:

@abo_shahad said:

Alibaba Cloud RDS

so the DB infrastructure changed from AWS to Alibaba within two days?

@abo_shahad said:

From an infrastructure and security perspective, we also need a separate recovery path in case the Cloudron server itself becomes corrupted during an upgrade, suffers complete filesystem failure, or even gets impacted by ransomware attacks such as Shamoon-style destructive malware encrypting the entire server storage.

If a backup site based on S3 is used and not a local mounted one, this can be completely avoided.
Many S3 providers offer write-once, read-many.
So when the backup gets stored encrypted on the S3, it can't even be encrypted again by a ransomware.
Also, Cloudron full system backups include everything to restore from 0 to 100.
So even if the full drive gets encrypted, you can restore the whole set up from a Cloudron backup without the need to restore the whole server.
Just a fresh Ubuntu and the Cloudron restore from the backup site is enough for 0 to 100.

But I can see that you really want to do this.
So your options are to fork the Freescout app and maintain it yourself or install it manually in the LAMP as suggested before.
Still, this will cause issues with the Cloudron backup and restore process leading to even bigger issues and frustration when the need to recover arises.