Leistungen
01Webflow-EntwicklungWebsites, die Ihr Team selbst pflegt.02Shopify-EntwicklungShops, die verkaufen.03WordPress-EntwicklungFlexible Websites, bereit für Plugins.04Individuelle Web-App-EntwicklungDashboards, Portale, KI-Tools.05AutomatisierungenCRM, Outreach und Abläufe auf Autopilot.06Website-MigrationPlattform wechseln, Rankings behalten.Alle LeistungenBranchen
01B2B-StartupsWebsites, die mit dem Produkt Schritt halten.02Lokale DienstleisterLokal gefunden werden. Den Anruf bekommen.03E-Commerce-UnternehmenShops, die das Kaufen leicht machen.Alle BranchenUnternehmen
Case StudiesPreiseWhite LabelÜber unsCase Study · Infrastruktur / Platform Engineering
Das App-Portfolio von Greater Change Health von einem einzelnen geteilten VPS auf das Edge-Netzwerk von Cloudflare und von Supabase zu Neon Postgres bringen - eine App nach der anderen.
Projektüberblick
Die Abrechnungsplattform von Greater Change Health und Nora waren zwei von rund acht Kundenanwendungen, die wir ursprünglich auf einem einzigen geteilten VPS ausgeliefert hatten. Als das Portfolio wuchs, haben wir es samt Nachbar-Apps auf das Edge-Netzwerk von Cloudflare und von Supabase zu Neon Postgres migriert - jede Anwendung als eigenes, geordnetes Migrationsprojekt.
Die Herausforderung
Rund acht Kundenanwendungen, darunter die Abrechnungsplattform von Greater Change Health und Nora sowie mehrere interne Dashboards, liefen alle auf einem Ubuntu-VPS. Der kostenlose Supabase-Tarif begrenzt auf zwei aktive Datenbanken pro Konto, ein wachsendes Portfolio bedeutete also, mehrere Supabase-Konten zu jonglieren, nur um jede App im kostenlosen Tarif zu halten.
Was wir getan haben
Wir haben jede Anwendung als eigenes Migrationsprojekt behandelt: jede Next.js-App von 14 auf 15 (React 18 auf 19) über OpenNext portiert, damit sie als Cloudflare Worker läuft, und jede Postgres-Datenbank zu Neon gebracht, dessen kostenloser Tarif bis zu 100 Projekte pro Konto erlaubt statt zwei bei Supabase. Die Daten zogen über idempotente, rein lesende Skripte um, die jede Zeile aus der REST-API von Supabase holten und die Zeilenzahlen vor der Umstellung prüften, und jede Domain lief zunächst nur über DNS und bestand einen Login- und Daten-Smoke-Test, bevor der Cloudflare-Proxy aktiviert wurde - der ursprüngliche VPS blieb die ganze Zeit als Rückfall aktiv.
Was die Migration wirklich bedeutete
Workers können kein natives bcrypt ausführen, daher wechselte das Passwort-Hashing je nach App zu bcryptjs oder Web Crypto.
Apps, die Daten in lokalen JSON-Dateien speicherten oder einen dauerhaften Postgres-Pool brauchten, benötigten echte Änderungen am Datenspeicher: Cloudflare D1 für Nora, Neons Serverless-Treiber für den Rest.
Neons Treiber liefert native JS-Datumswerte, wo die REST-API von Supabase Strings lieferte, und alte Supabase-Auth-Cookies waren so groß, dass sie Nginx zum Absturz brachten. Beides musste gefunden und behoben werden, statt es wegzudefinieren.
Zuerst zogen die Mail-Einträge um, dann wechselte jede App erst nach bestandenem eigenem Smoke-Test von reinem DNS auf den Proxy - mit dem ursprünglichen VPS als aktivem Rückfall.
Die Ergebnisse
Das Ergebnis: das Postgres eines ganzen Kundenportfolios gebündelt in einem Neon-Konto statt in mehreren Supabase-Konten, die nur zur Einhaltung der Gratis-Limits getrennt waren, und rund acht Anwendungen von einem geteilten VPS auf das Edge-Netzwerk von Cloudflare umgezogen - die meisten mit neu gebauter Identitätsschicht, da Neon keinen Auth-Dienst mitbringt wie Supabase. Jede App behielt ihren eigenen Rückfallweg, bis ihre Umstellung geprüft war.
Mit den Gründern sprechenBringen Sie Ziele, Einschränkungen und die chaotischen Teile mit. Wir machen daraus einen klaren nächsten Schritt.
