Canine: selbst gehostetes PaaS für Kubernetes mit git push und Web-UI
Ein entwicklerfreundliches PaaS für Ihr Kubernetes. Stellen Sie Anwendungen mit Git Push bereit, verwalten Sie Dienste über eine intuitive Weboberfläche und nutzen Sie die volle Leistung von Kubernetes, ohne YAML schreiben zu müssen.
Auf einen Blick
- Was ist das?
- Canine verspricht Heroku-Bequemlichkeit auf dem eigenen Kubernetes-Cluster: Deployment per git push, Dienste über eine Weboberfläche, kein Pflicht-YAML. Was das README konkret dokumentiert und wo es still bleibt.
- Für wen ist es gedacht?
- Canine passt für kleine Teams, die einen Kubernetes-Cluster betreiben, aber weder kubectl-YAML noch eine eigene CI-Pipeline pflegen wollen und stattdessen git push plus Weboberfläche bevorzugen. Es passt nicht, wer eine vollständig dokumentierte, versionierte Selbsthosting-Lösung mit klarer Grenze zur Bezahlstufe sucht, denn das README lässt Umfang der Cloud-Funktionen, Release-Zahlen und Sicherheitsangaben offen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Ruby, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Canine als PaaS auf dem eigenen Kubernetes-Cluster
Kubernetes bietet volle Kontrolle und verlangt dafür jede Menge YAML, Manifeste und kubectl-Aufrufe. Genau diese Reibung will Canine beseitigen. Das Projekt von CanineHQ (CanineHQ/canine, in Ruby geschrieben) beschreibt sich als selbst gehostete Deployment-Plattform, die die Einfachheit von Platform-as-a-Service im Stil von Heroku auf die eigene Kubernetes-Infrastruktur bringt.
Drei Versprechen strukturieren das README: Anwendungen werden per git push bereitgestellt, Dienste laufen über eine intuitive Weboberfläche, und die volle Kraft von Kubernetes bleibt erreichbar, ohne YAML schreiben zu müssen. Anders als bei gehosteten PaaS-Angeboten verbleibt die Infrastruktur beim Betreiber, das README erlaubt beliebige Cluster, ob Cloud, on-premise oder Edge. Unter der Apache-2.0-Lizenz freigegeben zählt das Repository laut Metadaten rund 2.900 Sterne.
Deployment per git push mit GitHub- und GitLab-Webhooks
Der zentrale Arbeitsablauf ist git-getrieben. Man verbindet ein GitHub- oder GitLab-Repository, und Canine deployed automatisch bei jedem Push. Laut Feature-Tabelle läuft die Anbindung über Git-Webhooks für kontinuierliche Bereitstellung, und das Image-Building ist eingebaut: Canine erzeugt Docker-Images automatisch, entweder aus einem Dockerfile oder über Buildpacks, und übernimmt die komplette Pipeline bis zum Cluster.
Drei Diensttypen sind vorgesehen: Web-Dienste, Hintergrund-Worker und geplante Cron-Jobs. Das bedeutet, dass auch Jobs ohne Web-Traffic, etwa nächtliche Aufräumläufe, über dieselbe Oberfläche laufen wie die eigentliche Anwendung. Die konkreten Schritte zur Webhook-Konfiguration stehen nicht im README, sondern in der verlinkten Dokumentation unter docs.canine.sh; wer die Pipeline prüfen will, startet dort.
Von CPU-Limits bis SAML: was die Feature-Tabelle verspricht
Die Tabelle im README listet den Rest des Funktionsumfangs. Ressourcen lassen sich mit CPU-, Speicher- und GPU-Limits versehen, benutzerdefinierte Domänen kommen mit DNS-Integration und automatischem SSL, Umgebungsvariablen und Kubernetes-Secrets werden verwaltet, und persistente Volumes decken zustandsbehaftete Anwendungen und Datenbanken ab.
Auf Organisationsebene gibt es kontobasierte Mehrinstanzfähigkeit mit Team-Zusammenarbeit und Zugriffskontrolle. Zwei Einträge richten sich an Fortgeschrittene: custom Pod Templates erlauben die Feinanpassung von Kubernetes-Pods über YAML, und Enterprise-SSO unterstützt SAML, OIDC und LDAP. Bemerkenswert an diesem letzten Punkt: Der Anspruch lautet, ohne YAML auszukommen, für Sonderfälle bleibt der Weg zurück zu YAML aber ausdrücklich offen. Anwendungsbeispiele oder Screenshots zu diesen Funktionen liefert das README nur spärlich.
Installation mit canine.sh/install.sh, Docker Compose und PORT
Die Anforderungen sind knapp gehalten: Docker ab Version v24.0.0 und Docker Compose ab v2.0.0, sonst nichts. Der schnelle Weg ist ein Einzeiler, curl -sSL https://canine.sh/install.sh | bash, dessen Inhalt im README allerdings nicht offengelegt wird.
Wer nachvollziehen will, was passiert, geht den manuellen Weg: git clone https://github.com/CanineHQ/canine.git, cd canine, dann echo "SECRET_KEY_BASE=$(openssl rand -hex 64)" > .env, um einen geheimen Schlüssel zu erzeugen, und abschließend docker compose up -d. Danach antwortet die Weboberfläche unter http://localhost:3000. Soll ein anderer Port laufen, setzt man die Umgebungsvariable PORT beim Aufruf, etwa PORT=3456 docker compose up -d. Auffällig ist, dass das README keine Versionsnummern zur Software selbst, kein Release-Intervall und keinen Changelog nennt; die Versionshistorie muss man sich im Repository selbst zusammensuchen.
Canine Cloud: die Bezahlstufe und ihre offene Grenze
Neben der selbst gehosteten Variante existiert Canine Cloud, eine Zusatzstufe für kleine Teams. Sie umfasst laut README eine GitHub-Integration für Deployment-Workflows, Team-Zusammenarbeit mit rollenbasierter Zugriffskontrolle, Echtzeit-Metriken und Monitoring sowie, sinngemäß, deutlich weniger Wartung für den Nutzer. Preise stehen auf der Landingpage canine.sh.
Wichtig für die Kaufentscheidung und zugleich die größte Lücke des Dokuments: Das README sagt nicht, welche dieser Cloud-Funktionen gegebenenfalls auch in der selbst gehosteten Version stecken, und es listet keine Einschränkungen der freien Variante auf. Da die Feature-Tabelle Zugriffssteuerung bereits auf der Selbsthosting-Seite verspricht, bleibt unklar, wo genau die Grenze zwischen beiden Stufen verläuft. Wer auf solche Abgrenzungen angewiesen ist, muss auf der Landingpage oder in der Dokumentation nachfragen.
Apache 2.0 und die Alternative: Kubernetes direkt mit kubectl
Canine steht unter der Apache-2.0-Lizenz. Sie erlaubt die Nutzung, Veränderung und Verbreitung für kommerzielle und nicht-kommerzielle Zwecke, einschließlich Unterlizenzierung, und ergänzt die Urheberrechtslizenz um eine Patentlizenz unter den Bedingungen ihres Abschnitts 3. Für den Einsatz im Unternehmen bedeutet das: Eigene Anpassungen am Code sind erlaubt und dürfen weitergegeben werden, Garantie oder Support-Versprechen entstehen daraus keine; kommerzieller Support wird vom Hersteller separat über canine.sh angeboten.
Die naheliegende Alternative ist der Verzicht auf eine PaaS-Schicht: Kubernetes direkt mit kubectl und selbst gepflegten Manifesten. Dieser Weg gibt maximale Kontrolle über jede Zeile der Konfiguration und keine zusätzliche Software im Cluster, kostet aber YAML-Wartung, Build-Pipeline und Onboarding für jedes neue Projekt. Canine will genau diesen Aufwand abnehmen; wer ihn ohnehin beherrscht und nur ein oder zwei Dienste betreibt, gewinnt durch die zusätzliche Schicht wenig, während Teams mit regelmäßigen Deployments von git push und Weboberfläche spürbar entlastet werden.
Redaktionelles Fazit
Canine passt für kleine Teams, die einen Kubernetes-Cluster betreiben, aber weder kubectl-YAML noch eine eigene CI-Pipeline pflegen wollen und stattdessen git push plus Weboberfläche bevorzugen. Es passt nicht, wer eine vollständig dokumentierte, versionierte Selbsthosting-Lösung mit klarer Grenze zur Bezahlstufe sucht, denn das README lässt Umfang der Cloud-Funktionen, Release-Zahlen und Sicherheitsangaben offen. Vor dem produktiven Einsatz sollte man den manuellen Installationsweg mit docker compose up -d und SECRET_KEY_BASE durchspielen, die Funktionsliste der Feature-Tabelle gegen die eigene Cluster-Umgebung prüfen und bei unklaren Punkten die Dokumentation unter docs.canine.sh konsultieren.
Community-Notizen