Eigene Server bleiben eigene Server
Bestehende Maschinen werden per SSH angebunden und mit Docker, Reverse-Proxy, SSL, Firewall und Backups eingerichtet.
Einheitliches Setup, auch auf den Servern, die ihr schon habt.

So unterscheidet sich der Alltag.
| Aufgabe |
|
Ohne MainPath |
|---|---|---|
| Projekt-Setup | Vollständig abgedeckt: Repository, Struktur, CI/CD-Pipeline, Server-Anbindung, Domain | Nicht angeboten: Jedes Projekt trägt die Handschrift der Person, die es aufgesetzt hat |
| Betriebswissen | Vollständig abgedeckt: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf | Nicht angeboten: Wissen steckt in Skripten, Wikis mit unklarem Stand und einzelnen Kollegen |
| Eigene Server nutzen | Vollständig abgedeckt: Bestehende Server per SSH anbinden oder Managed Server nutzen | Teilweise abgedeckt: Möglich, aber jede Maschine wird einzeln gepflegt |
| Server-Grundsetup | Vollständig abgedeckt: Docker, Datenbanken, Reverse-Proxy, SSL, Firewall | Teilweise abgedeckt: Manuelle Einrichtung, dokumentiert im besten Fall im Nachhinein |
| Zugriffsrechte und Rollen | Vollständig abgedeckt: Organisationen, Rollen und Zugriffsrechte regeln Zugang pro Projekt | Teilweise abgedeckt: Berechtigungen sind historisch gewachsen und werden selten aufgeräumt |
| Nachweise für Audits | Vollständig abgedeckt: Audit Log über relevante Änderungen, plus Git-Historie für Umgebungen | Nicht angeboten: Nachweise werden für den Prüftermin zusammengesucht |
| Standort der Verarbeitung | Vollständig abgedeckt: Betrieb in der EU, DSGVO-konform, Auftragsverarbeitungsvertrag möglich | Teilweise abgedeckt: Einzelne Dienste liegen außerhalb der EU und müssen einzeln bewertet werden |
| Onboarding und Vertretung | Vollständig abgedeckt: Remote-Workspaces mit VS Code, JetBrains | Nicht angeboten: Neue Kollegen brauchen Tage, bis eine Umgebung lauffähig ist |
| Fehler im Betrieb | Vollständig abgedeckt: Error-Tracking mit Sentry mit Stacktrace, Release und Kontext | Teilweise abgedeckt: Fehler werden über den Support gemeldet und manuell eingeordnet |
| Abhängigkeit vom Anbieter | Vollständig abgedeckt: Repositories, Pipeline-Konfiguration | Teilweise abgedeckt: Einzelne Werkzeuge und Dienstleister sind nur mit Aufwand ersetzbar |
Grün ist abgedeckt, gelb teilweise, grau nicht vorgesehen.
Sechs Punkte, die Betriebssicherheit und Prüffähigkeit betreffen.
Bestehende Maschinen werden per SSH angebunden und mit Docker, Reverse-Proxy, SSL, Firewall und Backups eingerichtet.
Verarbeitung und Hosting finden in Europa statt, DSGVO-konform und mit Auftragsverarbeitungsvertrag.
Das Audit Log hält relevante Änderungen fest.
Organisationen, Rollen und Zugriffsrechte regeln, wer welches Projekt und welche Umgebung sehen und ändern darf.
Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf.
Jedes Projekt nutzt dieselben GitLab-CI-Schritte für Test, Build und Release.
Organisation, Mitglieder & Abrechnung
Code, Git & Deployments
QA auf Dev & Staging
Kunden-App & Feedback
Ein Projekt als Pilot, danach kontrollierte Ausweitung.
Lege fest, welche Server genutzt werden dürfen, welche Daten wo verarbeitet werden und welche Rollen es geben soll.
Wähle ein Projekt mit klarem Umfang, lege es im Assistenten an und binde einen bestehenden Server per SSH an.
Passe die Pipeline-Konfiguration im Repository an interne Vorgaben an.
Bestehende Anwendungen ziehen nach und nach nach, sinnvoll gebündelt mit ohnehin geplanten Updates oder Relaunches.
Nein. Du bindest bestehende Server per SSH an
MainPath liefert die technische Nachvollziehbarkeit, die Prüfer verlangen
Genau dieses Risiko adressiert die Konfiguration in Git.
MainPath selbst wird DSGVO-konform und mit Auftragsverarbeitungsvertrag in der EU betrieben.
Das Modell besteht aus einem MainPath-Grundpreis
Erzähl uns, was ihr baut. Wir melden uns über das Kontaktformular.