Weg von Heroku nach Europa: eine praktische Migrationsanleitung
Heroku hat definiert, wie sich Deployment anfühlen soll: Code pushen, URL bekommen, nie über Server nachdenken. Wenn du wegen Datenstandort, Kosten oder beidem nach Europa wechselst, musst du dieses Gefühl nicht aufgeben. Diese Anleitung zeigt, was sich beim Umzug einer typischen Heroku-App wirklich ändert (ein Web-Prozess, Config Vars, Heroku Postgres, eine eigene Domain), mit einem Migrationspfad, der an einem Nachmittag machbar ist.
Warum Teams überhaupt wechseln
Heroku läuft auf AWS, und Salesforce ist ein US-Unternehmen. Deine Daten unterstehen damit US-Recht, inklusive CLOUD Act. Der kann US-Anbieter zur Herausgabe von Daten verpflichten, egal in welcher Region sie physisch liegen. Für viele europäische Teams, besonders mit Schweizer oder EU-Kunden in regulierten Branchen, ist das ein Compliance-Gespräch, das sie nicht immer wieder führen wollen.
klickops nimmt die Gegenposition ein: Es gehört einer Schweizer Firma (Natron Tech AG) und läuft auf eigener Hardware in Schweizer Rechenzentren, zertifiziert nach ISO 27001 und ISO 9001, ohne Hyperscaler darunter. Deine Daten unterstehen allein Schweizer Recht. Eine Schweizer Region einer US-Cloud gibt dir das nicht; die Betreiberfirma bleibt amerikanisch.
Dynos gegen gemessene Nutzung
Die grösste Umstellung ist die Abrechnung. Heroku verrechnet pro Dyno: Du wählst einen Dyno-Typ und zahlst ihn rund um die Uhr, ob er arbeitet oder nicht. Grösser skalieren heisst, einen grösseren Dyno wählen und ab sofort den neuen Fixpreis zahlen.
klickops kennt keine Dyno-Typen. CPU und Speicher dimensionieren sich automatisch, und abgerechnet wird stundengenau, was deine Workloads wirklich verbrauchen. Bezahlt wird aus einem monatlichen Nutzungsguthaben, das zu deinem Plan gehört und mehr wert ist als der Planpreis (Hobby kostet CHF 9 und enthält CHF 10 Guthaben, Pro kostet CHF 79 und enthält CHF 100). Liegt der Verbrauch darüber, kommt die Differenz aus einem Prepaid-Guthaben, das du bewusst auflädst, nie von einer offenen Kreditkarte. Ein Gratis-Plan deckt einen kleinen Stack ab: eine App und eine Datenbank in einem kleinen Rahmen, ganz ohne Karte.
In der Praxis heisst das: Eine App, die nachts nichts tut, kostet weniger als eine, die den ganzen Tag arbeitet. Und Apps mit Scale-to-zero kosten im Schlaf gar nichts.
Add-ons gegen eingebaute Dienste
Bei Heroku ist fast alles jenseits des Dynos ein Add-on mit eigenem Anbieter, eigener Rechnung und eigenem Datenstandort. Bei klickops gehört das Wesentliche zur Plattform, betrieben vom selben Betreiber, in denselben Schweizer Rechenzentren:
- Verwaltetes hochverfügbares PostgreSQL mit automatischen Backups, Point-in-time-Restore und eingebauter Query-Konsole.
- S3-kompatibler Objektspeicher mit Versionierung und Lifecycle-Regeln.
- Block- und geteilte (NFS) Volumes, die du im laufenden Betrieb vergrössern kannst.
- Eigene Domains mit automatischen TLS-Zertifikaten.
- Geplante Backups mit Ein-Klick-Restore, dazu Live-Metriken, Logs und Alarme.
Schritt 1: Container bauen, oder einfach das Repo verbinden
Heroku baut deine App mit Buildpacks. klickops beginnt beim Container-Image, und du hast zwei Wege hinein. Der einfachste: Verbinde dein GitHub- oder GitLab-Repository. klickops baut und deployt bei jedem Push automatisch, auf Wunsch mit Preview-Umgebungen pro Branch.
Wenn du lieber selbst die Kontrolle behältst, füge ein Dockerfile hinzu und pushe das Image in eine Registry, aus der klickops ziehen kann. Ein typischer Node-Web-Prozess übersetzt sich direkt:
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "server.js"]Schritt 2: Config Vars und Secrets umziehen
Exportiere deine Heroku-Konfiguration in einem Schritt und teile sie dann in zwei Stapel: einfache Konfiguration (Log-Level, Feature-Flags, öffentliche URLs) und Secrets (API-Keys, Tokens, Zugangsdaten).
In klickops kommen einfache Werte als Umgebungsvariablen auf die App. Secrets speicherst du separat als verwaltete Secrets, die die Plattform zur Laufzeit injiziert. Das Dashboard zeigt dir einen gespeicherten Secret-Wert nie wieder an, und genau so willst du es. DATABASE_URL kannst du vorerst weglassen; die neue Datenbank liefert ihren eigenen Connection-String in Schritt 3.
heroku config -s --app your-app > heroku.envSchritt 3: die Datenbank umziehen
Erstelle eine verwaltete PostgreSQL-Instanz in deinem klickops-Projekt und ziehe die Daten mit einem normalen Dump und Restore um. Herokus Backup-Werkzeuge liefern bereits ein pg_restore-kompatibles Archiv:
Kopiere den Connection-String von der Datenbank-Seite in klickops, spiele den Dump ein und zeige mit DATABASE_URL deiner App auf die neue Instanz. Bei den meisten Datenbanken unter ein paar Gigabyte dauert der ganze Transfer Minuten. Für einen Wechsel fast ohne Ausfallzeit machst du einen ersten Restore im Voraus, schaltest Heroku für den letzten Abgleich in den Wartungsmodus und wiederholst Dump und Restore für das Delta.
heroku pg:backups:capture --app your-app
heroku pg:backups:download --app your-app
pg_restore --no-owner --no-acl -d "$NEW_DATABASE_URL" latest.dumpSchritt 4: Domain und TLS umstellen
Deploye die App auf klickops und teste sie auf der Plattform-Subdomain, die sie automatisch bekommt, HTTPS funktioniert dort bereits. Wenn alles passt, fügst du im Dashboard deine eigene Domain hinzu: klickops stellt das TLS-Zertifikat aus und erneuert es für dich. Es gibt keinen Zertifikats-Schritt zu skripten.
Senke vor dem Wechsel die TTL deines DNS-Eintrags auf einen kurzen Wert (300 Sekunden sind üblich) und warte, bis die alte TTL abgelaufen ist. Dann zeigst du den Eintrag von Heroku auf klickops um. Der Traffic wandert innert Minuten, beide Seiten liefern während der Überlappung gültiges TLS, und du kannst die Heroku-App noch einen Tag als Fallback laufen lassen, bevor du sie herunterfährst.
Was du behältst, und was du gewinnst
Der Workflow, den du mochtest, überlebt den Umzug: Push to deploy, Rollbacks, Logs, ein aufgeräumtes Dashboard. Was sich darunter ändert: Jede App ist jetzt ein Standard-Kubernetes-Deployment in einem Namespace, ohne eigenen Operator und ohne proprietäre Ressourcen. Du kannst jederzeit alles als sauberes YAML exportieren und auf jedem Cluster betreiben. Die Ausstiegstür, durch die du gerade gehst, bleibt also auch beim nächsten Halt offen.
Und die Compliance-Antwort wird einfach: App, Datenbank, Backups und Objektspeicher liegen auf Hardware in Schweizer Besitz, in Schweizer Rechenzentren, unter Schweizer Recht. Das ist ein Satz im nächsten Vendor-Review statt zehn Seiten.
Bereit für Schweizer Infrastruktur?
Private Beta, Gratis-Plan für einen kleinen Stack, keine Karte nötig.