Enhancement Proposal: Transition Standalone Databases to Declarative Compose Setup

[Megajin]

Hello everyone,

I’d like to propose an improvement regarding the handling of standalone database installations in Coolify.

While reviewing the source code, I came across the standalone-php and action.php files. During my testing, I encountered several issues related to database instances — including, but not limited to, #5450, #4911, and #4519. Additionally, toggling the SSL option (enable → disable → re-enable) does not seem to have any effect unless the container is manually recreated.

This isn’t meant to be a bug report, but rather a discussion around architecture and usability. Currently, the PHP backend logic is responsible for generating docker-compose.yml files, managing reverse proxy settings, and handling init scripts. While functional, this setup introduces several limitations:

• It’s difficult to recover from broken database containers without deleting the entire instance.
• Permission issues (especially in PostgreSQL) cannot be resolved without low-level workarounds.
• Any manual changes to the generated compose file are lost after an update or container action.

Proposal:
Shift away from dynamic PHP-based container orchestration and instead move to static, customizable docker-compose.yml templates for each supported database. This approach has several advantages:

• Easier debugging and recovery: If something breaks, users can directly inspect and fix the compose.yml.
• Better transparency and control: Users understand what is deployed and can tailor it to their needs (e.g. add volumes, adjust entrypoints, tweak networking).
• Simplified permission management: Fixing issues becomes a matter of modifying a file and re-deploying.
• Consistency: Other parts of Coolify already rely on static docker-compose.yml definitions, so this would bring the architecture in line.

As a workaround, I currently rename the original database binary (in this case PostgreSQL), insert a custom wrapper script to fix permissions, and then start the actual process. While effective, this is not an ideal long-term solution.

I believe adopting static compose definitions for standalone databases would improve maintainability, transparency, and user experience — especially for teams running Coolify in production environments.

Happy to hear your thoughts.