Add Service Stack page for Github App based deployments

[louisab-dev]

Coolify is great with the one-click deployments for services providing a clear access to the different part of the services running and allowing for a specific configuration change or a setting up a database backup when a database is involved in the Service Stack.

Here is an example

This is possible for services based on a docker-compose.yml file. However this is not possible on deployments based on a github app even if the deployment is based on a docker-compose file.

Here is an example with a project deployed using a Github and a docker-compose file.

This would be a great addition to be able to view the health-checks of the different services and update settings for a specific part of the service.

[djsisson]

@louisab-dev there are 2 different types of projects in coolify, service (with a stack) and application.

Since you are in a repo, if you want to make a change to your compose stack, you just make it in your repo and redeploy, it doesn't make sense to be able to make a change in coolify, as it would just get overwritten next time you push

If you have a compose and want to have a service stack, then you can create new project, paste in compose, and set context to be your repo
using https or ssh(if private)

[louisab-dev]

You're right it doesn't make sense to be able to change settings this way. However I still think it would be a good addition to view the different services running with their health-checks. Also if a postgres database if detected in the compose file, having the backup option displayed would be great since I don't think there is a way to use coolify's backup system yet.

I'm not sure to understand the proposed approach to use a docker compose file and to set context to be your repo, I did not find any documentation for this in coolify docs, could you send a link please? Would that allow me to have new deployments upon a push on my repository as well?

Thanks!

[djsisson]

an example docker compose project using a public repo specifying branch and folder within repo:

services:
  app:
    build: 
      args:
        - REPO=djsisson/docker-events
        - BRANCH=main
      context: https://github.com/djsisson/docker-events.git#main:/agent
      dockerfile: Dockerfile
    image: app:latest
    pull_policy: build
    environment:
      - SERVICE_FQDN_APP_8000
    expose:
      - 8000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
  postgres:
    image: postgres:17-alpine
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "${SERVICE_POSTGRES_USER}"]
    environment:
      - POSTGRES_USER=${SERVICE_POSTGRES_USER}
      - POSTGRES_PASSWORD=${SERVICE_POSTGRES_PASSWORD}
    volumes:
      - postgres-test:/var/lib/postgresql/data

An example using a private repo using https (you set your pat token as a secret can be env or file)

services:
  app-private:
    build:
      args:
        - REPO=djsisson/my-app-private
        - BRANCH=main
      context: 'https://github.com/djsisson/my-app-private.git'
      dockerfile: Dockerfile
      secrets:
        - GIT_AUTH_TOKEN
    image: 'app-private:latest'
    pull_policy: build
    environment:
      - SERVICE_FQDN_APP_3000
    expose:
      - 3000
  postgres:
    image: 'postgres:17-alpine'
    healthcheck:
      test:
        - CMD
        - pg_isready
        - '-U'
        - '${SERVICE_POSTGRES_USER}'
    environment:
      - 'POSTGRES_USER=${SERVICE_POSTGRES_USER}'
      - 'POSTGRES_PASSWORD=${SERVICE_POSTGRES_PASSWORD}'
    volumes:
      - 'postgres-test:/var/lib/postgresql/data'
secrets:
  GIT_AUTH_TOKEN:
    environment: GIT_AUTH_TOKEN

an ssh is similar , you would just use:

     context: '[email protected]:djsisson/my-app-private.git'
      ssh:
        - default=/data/coolify/ssh/keys/ssh_key@d440o48o88s0owwc4swkk4gw

where this is a path to an ssh key you generated in coolify

Then in your github workflow you add a webhook to tell coolify to redeploy

[louisab-dev]

Thank you this looks like a good solution.

[thebadking]

I agree that the "view the different services running with their health-checks" is definitely a plus, the other option is to go to the logs tab and press load logs which is not the most user friendly and the colors of the state of each service are also a quick read of health instead of reading each docker logs