SHC vs Coolify

This document compares Coolify (a popular self-hosted PaaS) with SHC to help users understand the differences and migration paths.

Coolify Features That SHC Doesn’t Support

1. Application Building from Source

Coolify has extensive build capabilities that SHC lacks:

Nixpacks - Automatic framework detection and build (Node.js, Python, Go, etc.)
Dockerfile builds - Build images from Dockerfiles in your repo
Buildpacks - Cloud Native Buildpacks support

SHC is deployment-focused only - it deploys pre-built Docker images, not source code.

2. Git Push Auto-Deploy (CI/CD)

Coolify provides:

Webhook integration for GitHub/GitLab/Bitbucket
Automatic builds on push
Preview deployments for pull requests
Commit-based deployment tracking

SHC has Git repo support but only for syncing app definitions, not for CI/CD pipelines.

3. Web UI

Coolify is web-first with a full dashboard. SHC is CLI-only by design - this is intentional but means no browser-based management.

4. Let’s Encrypt Auto-SSL

Coolify automatically provisions SSL certificates. SHC uses Traefik ACME when TLS is enabled, with DNS records managed by SHC and HTTP-01 as the default challenge.

SHC Features That Coolify Doesn’t Have

Feature	SHC	Coolify
CLI-first	✅ Primary interface	❌ Web-only
Multi-tenant	✅ Built-in tenant isolation	❌
VApp system	✅ Plugin extensions (Keycloak realms, WordPress plugins)	❌
Plug/Socket integrations	✅ Declarative app dependencies	❌
Typed variables	✅ Schema-validated config	❌

What Does a Coolify App Look Like?

Coolify uses standard Docker Compose with some magic environment variables:

# documentation: https://example.com/docs
# slogan: My awesome app
# tags: web, api
# logo: my-app.svg
# port: 8080

services:
  myapp:
    image: myapp:latest
    environment:
      - DATABASE_URL=${DATABASE_URL:?}  # Required variable
      - SERVICE_FQDN_MYAPP              # Magic variable for auto-generated URL
    volumes:
      - myapp-data:/data

Coolify detects environment variables and shows them in the UI.

Do Coolify Apps Work in SHC?

Partially, with modifications. Here’s the comparison:

Aspect	Coolify Format	SHC Format
Compose file	Standard `docker-compose.yml`	`compose.yaml` with Jinja2 templating
Variables	`${VAR}` environment variables	`{{ vars.name }}` in templates
Metadata	YAML comments at top	Separate `app.yaml` file
Dependencies	Manual container links	Plug/Socket YAML files

Migration Steps

To migrate a Coolify app to SHC, you would need to:

Create an app.yaml with metadata and typed variable definitions
Convert ${VAR} placeholders to {{ vars.varname }} Jinja2 syntax
Optionally add socket/plug definitions for integrations

Example Conversion

Coolify docker-compose.yml:

services:
  app:
    image: myapp:latest
    environment:
      - DB_HOST=${DB_HOST}
      - DB_PASSWORD=${DB_PASSWORD}

SHC app.yaml:

name: myapp
version: "1.0"
description: My app

vars:
  db_host@string!: Database hostname
  db_password@secret!: Database password

SHC compose.yaml:

services:
  app:
    image: myapp:latest
    environment:
      DB_HOST: "{{ vars.db_host }}"
      DB_PASSWORD: "{{ vars.db_password }}"

When to Choose Each

Choose Coolify if you:

Want to deploy from source code (not just Docker images)
Need auto-deploy on git push / CI/CD
Prefer a web UI
Want automatic SSL certificate provisioning

Choose SHC if you:

Prefer terminal/CLI workflows
Need multi-tenant isolation
Want declarative app integrations (plug/socket)
Need VApp extensions (sub-app plugins)
Want typed, schema-validated configuration
Need to script and automate everything