New features that would greatly enhance coolify

[peaklabs-dev]

Some general features that would greatly enhance coolify:

• Improvements for cron: [Improvements]: Scheduled tasks #1622
• Integrated with cloud providers -> Especially integrated with Hetzner Cloud API so coolify triggers and automatic snapshot every day or multiple times a day in Heztner -> full server snapshot via the hetzner API
• Add a staging manager -> So we can automatically create staging sites for example for WordPress and other sites and test and change things and then let us push things to live -> in WordPress let us pull change from live to stage and push staging changes to live --> only the changes should be pushed
• Let us manage virtual hosted, sites-enabled files directly in the GUI -> example like in this panel: https://www.cloudpanel.io/docs/v2/frontend-area/vhost/
• Add a backup manager where we can schedule backups manage backups and restore them for each application or the whole coolify instance -> backup and restore very cleanly through UI
• Let us backup entire containers not just databases
• Backup the whole coolify instance to the cloud
• Backup to SFTP not only s3
• Backups only to remote storage not also localhost
• Let us set delete after 7 days for backups also for cloud storage
• add a light mode to coolify
• Expand the sidebar for easier navigation (not just icons)
• add the ability to have the same site on multiple coolify instances -> everything should be synced up and load balanced them -> main coolify acts as a professional high power load balancer
• Let us load balance multiple coolify instances which load balance a site behind them
• Let us change root directory in the panel settings
• Let us manage fields of a service and of the whole coolify instance in coolify itself
• Let us change PHP version of the application in one click -> for example in WordPress let us switch from PHP 8.2 to 8.3 in one click and safe (reload php automatically) Also let us change important PHP variables from the GUI like memory_limit, max_execution_time
  max_input_time, max_input_vars, post_max_size, upload_max_filesize...
• Let us see all our installed software in one place and restart them -> like PHP version, redis...
• let us mange files in coolify for each application a file manager directly in coolify would be nice
• Services template builder -> let us add compose file and then add redis, MariaDB and so on with one click (existing services can be added with one click)
• Add server Timzone picker
• Add slack notification metode
• Add custom webhook notification method so we can integrate with Albato zapier and so on

These are the most important requests I think.
A lot more cool features that coolify v4 should definitely have can be found in the documentation of this great panel which has so many good features that I think Coolify laks: https://www.cloudpanel.io/docs/v2/introduction/

[peaklabs-dev]

@andrasbacsai Could you take a look at these features too and maybe implement some of them for the next release or until v4-beta.500?

[luckydonald]

• Backup the whole coolify instance to the cloud

and

• Backup to SFTP not only s3

would be great.

[luckydonald]

• Let us change PHP version of the application in one click -> for example in WordPress let us switch from PHP 8.2 to 8.3 in one click and safe (reload php automatically) Also let us change important PHP variables from the GUI like memory_limit, max_execution_time, max_input_time, max_input_vars, post_max_size, upload_max_filesize...

Wouldn't that be possible already in a text field way by env vars in the docker-compose template?
I.e. having image: php:${PHP_VERSION} in your docker-compose?

Continuing the thought:
Maybe there could be SERVICE_DROPDOWN_<name>?

services:
  foo:
    image: "php:${SERVICE_DROPDOWN_PHP_VERSION}"
    environment:
      SERVICE_DROPDOWN_PHP_VERSION: '["8.0", "8.2", "${SOME_OTHER_VAR_FOR_THE_LULZ}"]'
      # or:
      SERVICE_DROPDOWN_PHP_VERSION_OPTION: 8.0
      SERVICE_DROPDOWN_PHP_VERSION_OPTION: 8.2
      SERVICE_DROPDOWN_PHP_VERSION_OPTION: ${SOME_OTHER_VAR_FOR_THE_LULZ}
      # maybe we don't even need the _OPTION part?
      # if those needs to be unique, possibly SERVICE_DROPDOWN_PHP_VERSION_1, _2, _3 ?

So I have the following two ideas:

1. SERVICE_DROPDOWN_PHP_VERSION: "json list"
   - probably need to quote it so that yml doesn't parse it as actual object...
   - but quoting everything twice might make variable interpolation ugly...
2. SERVICE_DROPDOWN_PHP_VERSION_OPTION: 8.0
   • Basically one line per entry
   • this way would give nicer git diffs for changes, I.e. line with 7.2 removed and line with 8.4 added, the rest unchanged
   • also no confusion about stringified json of 1.. I feel that would cause a lot of users hitting problems and spamming the bug tracker, lol