passwords are being stored in .env file

[jduhamel]

Deployrr Version

v6-rc

Operating System

Other (specify below)

Other OS (if applicable)

Arch Linux

Server Environment

Bare Metal

CPU Architecture

x86_64 (amd64)

Docker Version

No response

Bug Area

App Installation

Affected App (if applicable)

No response

GPU Passthrough

None

Bug Description

After deploying NextCloud and N8N I noticed some of the passwords were being stored in the .env file

NEXTCLOUD_ADMIN_PASSWORD='REDACTED'
NEXTCLOUD_MARIADB_ROOT_PASSWORD='REDACTED'
NEXTCLOUD_MARIADB_PASSWORD='REDACTED'
N8N_POSTGRESQL_PASSWORD='REDACTED'

Steps to Reproduce

1. Deploy n8n or nextcloud
2. in shell grep 'PASSW' .env

Expected Behavior

AUTHENTIK_POSTGRESQL__PASSWORD='file:///run/secrets/authentik_postgresql_password'

Actual Behavior

NEXTCLOUD_ADMIN_PASSWORD='REDACTED'
NEXTCLOUD_MARIADB_ROOT_PASSWORD='REDACTED'
NEXTCLOUD_MARIADB_PASSWORD='REDACTED'
N8N_POSTGRESQL_PASSWORD='REDACTED'

Relevant Logs

Additional Context

No response

Pre-submission Checklist

• I have searched existing issues and this hasn't been reported yet.
• I am running the latest version of Deployrr.
• I have checked the documentation for a solution.

[SimpleHomelab]

Thanks for the report. This is working as designed, not a bug.

The file:///run/secrets/ pattern you're referencing from Authentik only provides meaningful security benefits in Docker Swarm mode, where secrets are encrypted at rest in the raft log. Deployrr targets standalone Docker Compose, where "secrets" are just bind-mounted files with no encryption advantage over a properly permissioned .env.

In a non-Swarm setup with both files owned by root and chmod 600, the security posture is effectively identical. The only marginal difference is that env vars show up in /proc//environ, but if an attacker can read that on your host, they can also docker exec into the container and cat the secret file.

Some apps support the file:// indirection (or secrets) but some don't. Deployrr has no control over it. We could add it as an option for apps that support it and, in most cases, if an app supports secret, Deployrr already takes that route. But it wouldn't improve security for the typical Deployrr user running standalone Compose.

Deployrr already has built in health check if the permissions of .env are too liberal.