[Feature Request] Improve Environment Variable Management for Infrastructure-as-Code (Terraform/Cloud-init) Automation

[collisdigital]

Description

When deploying Devpush via automation tools (like Terraform and Cloud-init), there is a hurdle in managing configuration values (Domain, App Secrets, etc.). Currently, the installer is "opinionated" and generates a default .env file upon execution, which creates a challenge for automation scripts that need to inject specific, user-defined values.

The Current Challenges

• Race Condition: If a script (like Cloud-init) tries to write a .env file before the installer runs, the installer may overwrite it.

• Brittle Merging: Users currently have to write "merge" scripts or use sed to surgically edit /var/lib/devpush/.env after the installer finishes. This is error-prone and breaks if the default .env template changes.

• Goal: Enable a "Single Source of Truth" deployment where infrastructure parameters can be passed to the installer or picked up automatically without manual file manipulation.

Suggested Solutions

1. Support an --env-file Flag in the Installer

Modify the installer script to accept a path to an existing environment file. If provided, the installer could either skip generating random secrets and use the provided file as the primary configuration or take the provided file and merge it in automatically during the install process.

Example usage: curl -fsSL https://get.devpu.sh | bash -s -- --env-file /tmp/predefined.env

2. Support a .env.d/ Directory for Overrides

Adopt a modular configuration pattern where the main application loads variables from a directory in addition to the primary .env file.

• Concept: Devpush loads /var/lib/devpush/.env first, then loads all files in /var/lib/devpush/conf.d/*.env.

• Automation Benefit: Terraform can simply drop a 01-infra.env file into that folder. This avoids the need to "edit" the main file and ensures infrastructure-managed values always take precedence.

3. Environment Variable Injection via Shell

Allow the installer to detect existing environment variables in the shell session and use those to populate the .env file with the values that it finds in addition to the auto-generation ones (unless those exist also).

Usage:

export APP_HOSTNAME=app.example.com 
export GITHUB_APP_ID=xyz 

# Script sees already set variables and stores them in .env file during install
curl -fsSL https://install.devpu.sh | sudo bash

Impact

Implementing a solution would make Devpush "Cloud-Native" friendly, allowing for seamless, one-click deployments on Hetzner, AWS, and DigitalOcean etc. via Terraform without the need for custom "hacky" merge scripts.

References

See https://github.com/collisdigital/devpush-hetzner-infra for an example of a Terraform automation project that deploys devpsuh. This project works around the current issue, specifically devpush-config.yaml creates a temporary /etc/opt/devpush/.env.custom file during provisioning containing user configured values, then after the devpush installer script finishes merge_env.sh merges the custom variables into the /var/lib/devpush/.env file - it's a bit fragile and more commplex than it needs to be.