Lösung

Self hosted PaaS: eigene Server behalten, den Betrieb der Plattform abgeben

Deployment auf eigener Infrastruktur führt meist zu einem Open-Source-Werkzeug auf dem Server – das verschiebt nur den Aufwand. Wir betreiben die Plattform, du die Server, Updates inklusive.

Eigener Server per SSH oder Managed Server, der Zugang bleibt bei dir
Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet
Pipeline-Konfiguration liegt lesbar im Repository, kein geschlossener Mechanismus

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Docker
Datenbanken
Reverse-Proxy
SSL
Backups
Firewall
Demnächst Kubernetes
Demnächst Monitoring

Das Server-Grundsetup entsteht automatisch, der SSH-Zugang bleibt bei dir.

Kurz gesagt

Beide Wege führen zu Deployments auf deiner eigenen Infrastruktur. Der Unterschied liegt darin, wer die Plattform darunter betreibt.

Ein selbst betriebenes PaaS-Werkzeug läuft auf deinem Server, Updates und Ausfälle bleiben deine Aufgabe.
Die Application Platform richtet deine Server ein und betreibt die Steuerungsebene für dich.

Selbst betriebenes PaaS-Werkzeug und Application Platform im Vergleich

Die Gegenüberstellung beschreibt den typischen Alltag mit einem selbst installierten Open-Source-Werkzeug im Vergleich zu einer betreuten Plattform, die auf deinen Servern arbeitet.

Aufgabe	Application Platform	Selbst betriebenes PaaS-Werkzeug
Deployment auf eigener Infrastruktur	Vollständig abgedeckt: Eigener Server per SSH oder Managed Server	Vollständig abgedeckt: Kernidee, läuft vollständig auf deiner Maschine
Installation der Plattform	Vollständig abgedeckt: Entfällt, die Steuerungsebene wird betrieben	Nicht vorgesehen: Du installierst und konfigurierst das Werkzeug selbst
Updates und Sicherheitspatches	Vollständig abgedeckt: Für die Plattform übernommen	Nicht vorgesehen: Liegt bei dir, inklusive Breaking Changes
Server-Grundsetup	Vollständig abgedeckt: Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups	Teilweise abgedeckt: Je nach Werkzeug teilweise abgedeckt, der Rest bleibt Handarbeit
CI/CD-Pipelines	Vollständig abgedeckt: GitLab-CI für Test, Build, Publish und Release	Teilweise abgedeckt: Meist nur Deployment, CI separat anbinden
Mobile Apps und Store-Releases	Vollständig abgedeckt: Flutter, Expo und native Projekte bis in die Stores	Nicht vorgesehen: Nicht Teil des Werkzeugs
Kontrolle über die Plattform selbst	Teilweise abgedeckt: Du steuerst Projekte und Server	Vollständig abgedeckt: Quelloffen, im Zweifel anpassbar

Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen.

Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was du bekommst, ohne die Plattform zu betreiben

Sechs Punkte, die den Unterschied zwischen einer installierten Software und einem betreuten Setup ausmachen.

Deine Server, dein Zugang

Bring einen eigenen Server per SSH mit oder nutze einen Managed Server.

Grundsetup ohne Handarbeit

Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet.

Pipelines statt reinem Deployment

GitLab-CI deckt Test, Build, Publish und Release ab.

Betrieb in der EU

Plattform, Repositories und Managed Server laufen in der EU, mit AVV.

Eigene Maschinen und Managed Server nebeneinander verwalten.

So richtest du dein self hosted Setup ein

Vier Schritte vom leeren Server bis zum ersten Deployment.

Server anbinden

Hinterlege einen eigenen Server per SSH oder buche einen Managed Server.
Grundsetup abwarten

Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden aufgesetzt.
Projekt anlegen

Wähle im Assistenten deinen Stack. Repository, Pipeline und Domain entstehen mit.
Deployen und weiterarbeiten

Ein Push löst die Pipeline aus. Variablen und Zugangsdaten pflegst du zentral.

Häufige Fragen

Ist die Application Platform selbst gehostet?

Teilweise. Deine Anwendungen laufen auf Servern mit SSH-Zugang, die Steuerungsebene betreiben wir. Für reine Datenhaltung reicht das, für eine fremde Steuerungsebene brauchst du Open Source.

Was spricht für ein selbst betriebenes Open-Source-Werkzeug?

Keine Lizenzkosten, lesbarer Quellcode, keine Abhängigkeit vom Anbieter. Für Teams mit Betriebserfahrung eine solide Entscheidung.

Kann ich meinen bestehenden Server weiterverwenden?

Ja. Du hinterlegst die SSH-Zugangsdaten, die Plattform richtet Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups ein.

Prüfe den Zwischenweg an einem Projekt

Registriere dich kostenlos, binde einen Server an und vergleiche den Aufwand mit deiner bisherigen Installation.

Kostenlos registrieren Mit uns sprechen