zurück zur Tech-Wiki
Tech-Wiki/Infrastruktur
C

Coolify

Self-hosted PaaS, Heroku-/Netlify-Alternative auf eigener Hardware.

·Coolify·Apache-2.0

Übersicht

Was ist es?

Coolify ist eine Open-Source-PaaS — self-hosted Heroku/Netlify/Vercel-Alternative auf eigener Hardware. Pulled Git-Repos, baut Docker-Images, deployed mit Reverse-Proxy + TLS. Hier produktiv unter coolify.tjl-it.de für tobiasjonas-ludwig.de.

Quickstart

# Auf einem frischen Server (Ubuntu/Debian):
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Danach UI auf :8000, Git-Repo verbinden, Auto-Deploy aktivieren.

Typische Patterns

  • Git-Push-to-Deploy: git push origin main → Coolify-Webhook → Rebuild. Kein manueller Deploy.
  • Eigene Dockerfile im Repo nutzen statt Nixpacks/Buildpacks, wenn Stack spezifisch.
  • Env-Vars im Coolify-UI setzen (hier: NEXT_PUBLIC_SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY).
  • Preview-Deploys pro Branch / PR.
  • API-Zugriff via Token (.env.coolify im Repo-Root) für Automation ohne UI-Klick.

Gotchas / Was oft schiefgeht

  • Builds laufen auf dem Server, nicht lokal — RAM/Disk-Limits können Builds killen. Server-Specs prüfen.
  • Webhooks von GitHub müssen erreichbar sein → Firewall / DNS.
  • Self-signed-Cert oder Let's-Encrypt-Limit: Custom-Domains brauchen DNS-Setup vor TLS-Issue.
  • Persistent-Volumes für Stateful-Services explizit konfigurieren — sonst Datenverlust bei Redeploy.
  • Logs sind im Coolify-UI, aber für tiefe Debugging SSH (root@87.106.233.81) und docker logs direkt.

Wann nicht?

Bei Enterprise-Skalierung mit Multi-Region und SLA → Vercel / Fly.io / Render. Für Hobby-Projekte ohne eigenen Server → Vercel-Free-Tier reicht.

Eingesetzt in