Kurzfassung
Branchly Cloud (branchly.cloud) ist die serverless PostgreSQL-Plattform von DevStudio.it, mit Git-ähnlichem Branching (bis zu fünf parallelen Branches), Operations-Konsole (CRM, Billing, Helpdesk, Automations) und EU-Datenresidenz. In DevStudio-Projekten ist der Standard Prisma + PostgreSQL: Migrationen in CI, DATABASE_URL im Next.js-Runtime. Branchly ergänzt DevStudioIT Cloud (App-Hosting), auf devstudioit.com zeigt InfrastructureSplit beide Produkte als reale Schichtentrennung. Trial: 1 Projekt, 0,5 GB und 20 CU-h/Monat. Mit Deployment und Betreuungspaket erhalten Sie Backups, Monitoring und Support nach dem Start.
Für wen ist das
- Unternehmen und Softwarehäuser, die Next.js-Web-Apps bauen und eine relationale Datenbank mit planbaren Kosten und Support brauchen
- Inhaber von Firmenwebsites nach einem DevStudio.it-Launch, die wissen wollen, wo Daten liegen (Formulare, Nutzer, Inhalte) und wer verantwortlich ist
- Entwickler, die Dev/Staging-Umgebungen suchen, ohne Produktion manuell zu klonen, ein Branchly-Branch statt „zweite DB auf dem VPS“
- Teams mit Prisma, die Migrationen, Connection Strings und Backups in einem Ökosystem mit Hosting wollen
- Personen, die generische Cloud-Datenbanken mit einer Lösung für den DevStudio-Stack vergleichen, Limits, EU, ein Ansprechpartner
Keyword (SEO)
branchly cloud, datenbank webanwendung, postgresql nextjs, prisma migrationen produktion, serverless postgresql eu, datenbank branch dev staging, database_url nextjs, branchly devstudioit cloud, postgresql backup monitoring
Was Branchly Cloud ist, und was nicht
Branchly ist die Datenschicht im DevStudio.it-Ökosystem, kein Ersatz für App-Hosting und kein weiterer „Website-Baukasten“. Unter branchly.cloud erhalten Sie managed PostgreSQL im Serverless-Modell: nutzungsbasierte Skalierung statt eines festen Servers, der halb leer steht oder im Peak ohne RAM ist.
In einer Konsole verbinden Sie, was typische B2B-Projekte auf fünf Tools verteilen:
| Bereich | In Branchly | Praxisnutzen |
|---|---|---|
| Datenbank | Serverless PostgreSQL | Nutzer, Bestellungen, Leads, CMS |
| Branching | Bis zu 5 parallele Branches | Dev, Staging, Preview ohne manuelles Kopieren |
| CRM | Integriertes Modul | Kundenkontext neben dem Technikprojekt |
| Billing | Abrechnung in der Konsole | Klare Pläne, keine Rechnungsüberraschungen |
| Helpdesk | Tickets und Support | Ein Kanal statt E-Mail „an irgendwen beim Hosting“ |
| Automations | Regeln und Workflows | Wiederholbare Datenoperationen und Benachrichtigungen |
EU-Datenresidenz ist rechtliches und geschäftliches Argument, DSGVO, Verträge mit Konzernkunden, „Daten bleiben in Europa“ ohne eigenes Cluster. Branchly ersetzt nicht DevStudioIT Cloud: Cloud hält Next.js-Runtime (SSR, Server Actions, Deploy), Branchly hält Persistenz. Auf der DevStudio-Startseite erscheinen beide Systeme in InfrastructureSplit, Architektur, die wir bei Kunden nutzen, kein Verkaufsslide.
Wann PostgreSQL, und wann etwas anderes
Die DB-Wahl am ersten Tag bestimmt Migrationskosten ein Jahr später. Für die meisten Firmen-Web-Apps und B2B-SaaS, die wir bei DevStudio bauen, ist die Antwort einheitlich: PostgreSQL.
PostgreSQL passt, wenn:
- Sie Relationen haben, Nutzer hat Bestellungen, Bestellung hat Positionen, Firma hat viele Kontakte
- Sie ACID-Transaktionen brauchen, Zahlungen, Buchungen, Lager; partieller Schreibvorgang ist Bug, kein Feature
- Sie komplexe Queries und Reports fahren, Aggregationen, JOINs, Zeitfenster; SQL in PostgreSQL ist seit Jahrzehnten ausgereift
- Sie JSON neben Relationen wollen,
jsonbfür flexible Felder ohne Schema-Verzicht - Ihr Stack Next.js + Prisma ist, Generator, Migrationen und TypeScript-Typen sind Standard in unseren Repos
Wann andere Ansätze
| Bedarf | Alternative | Hinweis |
|---|---|---|
| CMS ohne Custom-Logik | WordPress + MySQL | Eigenes Produkt |
| Nur Dokumente | Document Store | Selten nach Anforderungsreview |
| Petabyte-Analytics | Columnar Warehouse | Neben operativem PostgreSQL |
| Cache / Sessions | Redis | Ergänzung, kein DB-Ersatz |
MySQL passt zu WordPress; bei Custom Node + Prisma gewinnt PostgreSQL. MongoDB mit Relationen endet meist in SQL-Migration, teurer als Start mit Branchly PostgreSQL.
Git-ähnliches Branching, Dev, Staging und Preview
Der größte operative Schmerz bei Datenbanken sind Umgebungen. Klassisch: Entwickler testet lokal in Docker, Staging läuft „irgendwie“ mit Kopie von vor einem Monat, Produktion hat anderes Schema, Deploy endet mit relation does not exist.
Branchly führt Git-inspiriertes Branching ein: bis zu fünf parallele Branches pro Projekt. Jeder Branch ist eine eigene logische PostgreSQL-Instanz, main (Produktion), staging, feature-registrierung und Preview für einen PR, ohne manuelles pg_dump am Freitagabend.
| Branch | Typische Nutzung | Connection String |
|---|---|---|
main |
Produktion | DATABASE_URL in DevStudioIT Cloud |
staging |
Kundenabnahme | Separater URL im Staging-Projekt-Env |
dev |
Internes Team | Lokal oder CI-Preview |
feature-* |
Isoliertes Feature | Temporär, nach Merge gelöscht |
preview-pr-123 |
CI für Pull Request | Kurzlebig, an PR gebunden |
Workflow: Migration auf feature-x → Test → Merge nach main → prisma migrate deploy auf Produktion; Staging bekommt Migrationen früher. In CI/CD mit GitHub Actions ist Branch pro PR das Muster für größere Teams; kleinere Projekte halten staging + main.
Prisma + PostgreSQL, Standard in DevStudio-Projekten
In Kunden-Repos sitzt Prisma zwischen TypeScript und PostgreSQL: schema.prisma definiert Modelle, prisma migrate versioniert Schema, prisma generate liefert Typen für Server Actions und Route Handler.
Typisches Layout:
// schema.prisma-Ausschnitt, Illustration
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Lead {
id String @id @default(cuid())
email String
message String
createdAt DateTime @default(now())
}Migrationen in CI, nicht bequem vom Entwickler-Laptop:
| Schritt | Wo | Befehl / Aktion |
|---|---|---|
| PR | GitHub Actions | prisma migrate diff / Test auf Branch-DB |
| Build | Actions | prisma generate + next build |
| Deploy main | Actions oder Betreuung | prisma migrate deploy auf Produktions-Branch |
| Rollback | Betreuungsprozedur | Backup-Restore + Migrations-Revert in Git |
Branchly liefert Connection String pro Branch. Bei DevStudio committen wir keine URLs mit Passwörtern, DATABASE_URL liegt in GitHub Secrets (Build/Migrate) und im DevStudioIT-Cloud-Panel (App-Runtime). Passwort-Rotation = Änderung in Branchly + Env-Update in Cloud + optional Redeploy, keine Secrets im git log.
Next.js-Anbindung, DATABASE_URL und Server Actions
Next.js 15 mit App Router führt Logik serverseitig aus: Server Actions, Route Handler, gecachtes fetch. Alles verbindet sich über eine Variable DATABASE_URL, Standard-PostgreSQL, kompatibel mit Prisma Client.
Konfigurationskette:
- In Branchly Projekt und Branch anlegen (
mainfür Produktion). - Connection String aus der Konsole kopieren.
- In DevStudioIT Cloud als Env
DATABASE_URLfür das Next.js-Projekt eintragen. - In GitHub Secrets dieselbe URL (oder separate für Migrationen) für
prisma migrate deployin der Pipeline.
Beispiel Server Action mit Prisma (vereinfacht):
'use server';
import { prisma } from '@/lib/prisma';
export async function submitContact(formData: FormData) {
await prisma.lead.create({
data: {
email: String(formData.get('email')),
message: String(formData.get('message')),
},
});
}Bei serverless PostgreSQL konfigurieren wir Prisma mit begrenztem Connection Pool, Details beim Go-Live in der Betreuung. NEXT_PUBLIC_* ist Frontend; DATABASE_URL ist nie öffentlich.
Operations-Konsole, CRM, Billing, Helpdesk
Branchly verbindet Technik und Betrieb: CRM (Kundenkontext), Billing (CU-h, Storage), Helpdesk (ein Support-Kanal), Automations (Benachrichtigungen ohne VPS-Cron). Mit DevStudioIT Cloud ein Ökosystem statt fünf getrennter Tools.
Backups, Monitoring und EU-Residenz
Eine DB ohne Backup ist Katastrophenlizenz. Projekte mit Betreuungspaket umfassen:
- PostgreSQL-Backups in Branchly, Zeitplan und Retention nach Vertrag
- Monitoring von Verfügbarkeit und Metriken, Alert bevor der Kunde anruft
- Restore-Test, ein Backup, das niemand restored hat, ist nur ein Download-Link
- EU-Residenz, operative Daten in europäischer Rechtsordnung
| Risiko | Ohne Prozedur | Mit Branchly + Betreuung |
|---|---|---|
| Tabellen-Löschung durch fehlerhafte Migration | Panik und manueller Restore | Backup + Point-in-Time |
| Connection-String-Leak | Rotation über mehrere Panels | Branchly + Cloud-Env, ein Prozess |
| DB-Wachstum | Kostenüberraschung | Limits, Alerts, Upgrade-Plan |
| DSGVO-Audit | „Wo liegt das?“ | EU, Vertrag, ein Datenanbieter |
Cloud überwacht Runtime, Branchly PostgreSQL, Betreuung verbindet beide Schichten.
Branchly + DevStudioIT Cloud, vollständiger Produktions-Stack
Architektur in InfrastructureSplit auf devstudioit.com:
| Schicht | Produkt | Verantwortung |
|---|---|---|
| Anwendung | DevStudioIT Cloud | Next.js 15, Node 22, Deploy, Domain, Env |
| Datenbank | Branchly | PostgreSQL, Branches, Migrationen, DB-Backups |
| CI/CD | GitHub Actions | Lint, Build, Migrate, Deploy |
| Betrieb | Betreuungspaket | Monitoring, Incidents, Updates |
Typische Deployment-Kette:
- Next.js-Repo mit Prisma → Branchly-Projekt (
main+staging). - Staging-
DATABASE_URLim Staging-Projekt-Env in Cloud; Produktion analog. - Pipeline: PR baut und testet; Merge auf
main→ Migrate + Deploy auf Cloud. - Übergabe: Zugänge zu beiden Panels, Branch-Doku, Restore-Prozedur in Betreuung.
Cloud + Branchly im DevStudio-Ökosystem: ein Team, ein Vertrag; Hosting woanders + Branchly ist möglich, Env-Integration bleibt bei Ihnen.
Branchly vs generische Cloud-Datenbanken
Die Tabelle zeigt, warum Branchly DevStudio-Standard ist, kein Ranking externer Anbieter.
| Kriterium | Generisches Managed Postgres | Branchly Cloud |
|---|---|---|
| Dev/Staging-Branching | Oft fehlend oder separates Produkt | Bis zu 5 Branches, Git-Modell |
| Business-Konsole (CRM, Billing) | Nur Infrastruktur | Integrierte Module |
| EU-Residenz | Regionabhängig, Sie müssen aufpassen | Standard-Betriebskontext |
| DevStudioIT-Cloud-Integration | Manuell | Standard-Workflow |
| Support nach Launch | Anonymer Provider-Ticket | Helpdesk + DevStudio-Betreuung |
| Trial / Start | Verschiedene Modelle, oft Kreditkarte | 1 Projekt: 0,5 GB + 20 CU-h/Monat |
| Prisma + Next.js-Stack | DIY | Muster in jedem Agenturprojekt |
Keine Kundenproduktion auf zufälligem Free Tier mit späterer Migration bei DSGVO und SLA, Branchly ist bewusste Wahl für diesen Stack.
Trial-Plan und Limits
Trial: 1 Projekt, 0,5 GB, 20 CU-h/Monat, reicht für Formular-PoC, Staging + Feature-Branch und Prisma-Tests. Vor Go-Live Plan nach Traffic und Backups; Serverless = Nutzungszahlung, daher Monitoring in der Betreuung.
Checkliste vor Produktions-Anbindung
- Produktions-Branch (
main) getrennt vonstaging, verschiedeneDATABASE_URL - Prisma-Migrationen in CI,
migrate deploybeim Merge, nicht manuell vom Laptop -
DATABASE_URLnur in Secrets und Cloud-Panel, nichts im Repo -
prisma generateim Build-Schritt, Typen wie Produktion - Formular-/Schreibtest auf Staging mit Staging-Domain, nicht localhost
- Backup und Restore-Prozedur in Betreuung vereinbart
- DB-Passwort-Rotation, klar, wer Branchly und Cloud aktualisiert
- Residenz und Auftragsverarbeitung, für Endkunden bestätigt
FAQ
Ersetzt Branchly DevStudioIT Cloud?
Nein. Branchly ist PostgreSQL und Datenoperationen; DevStudioIT Cloud ist Next.js-App-Hosting. Im Standardprojekt nutzen Sie beides: App auf Cloud, DATABASE_URL aus Branchly im Projekt-Env.
Wie viele Branches parallel?
Bis zu fünf parallele Branches pro Projekt, z. B. Produktion, Staging, Dev und zwei Feature-Previews. Nach Merge temporäre Branches löschen, um Kosten und Connection-String-Chaos zu vermeiden.
Branchly ohne Prisma?
Ja, es ist normales PostgreSQL. Bei DevStudio ist Prisma jedoch Standard: Migrationen, Typen und Server Actions in einer Toolchain. Anderes ORM oder Raw SQL funktioniert, wenn Migrationen im Repo bleiben.
Was bei Überschreitung der Trial-Limits (0,5 GB / 20 CU-h)?
Der Trial validiert den Stack. Vor Kunden-Go-Live wechseln Sie auf einen Produktionsplan passend zu Traffic und DB-Größe, besprechen wir beim Deployment, oft zusammen mit Cloud-Hosting-Plan und Betreuung.
Liegen Daten in der EU?
Ja, EU-Datenresidenz ist Teil von Branchlys Positionierung und Voraussetzung vieler B2B-Verträge. Beim DSGVO-Audit haben Sie einen Datenanbieter im europäischen Kontext statt Default-Region „US East“ bei globalem Provider.
Was bei DB-Ausfall in der Nacht?
Mit Betreuungspaket umfassen Monitoring und Incident-Prozeduren DB- und App-Schicht. Ohne Betreuung haben Sie Tools (Branchly, Cloud), aber Reaktion liegt bei Ihnen, deshalb empfehlen wir für Kundenprojekte das volle Ökosystem mit Wartung.
Zusammenfassung
Branchly Cloud ist serverless PostgreSQL von DevStudio.it mit Git-ähnlichem Branching, CRM/Billing/Helpdesk-Konsole und EU-Daten, die Persistenzschicht für Next.js, Prisma und DevStudioIT Cloud. Statt zufälligem Managed Postgres erhalten Sie Dev/Staging-Umgebungen, CI-Migrationen, DATABASE_URL im Hosting-Panel und Support nach Launch. Trial (1 Projekt, 0,5 GB, 20 CU-h/Monat) validiert den Stack vor Produktion. Wenn Sie eine Web-App bauen und fragen „welche Datenbank?“, im DevStudio-Ökosystem lautet die Antwort: PostgreSQL auf Branchly, App-Delivery auf Cloud.
Datenbank für Ihr Next.js-Projekt?
- Branchly Cloud öffnen, PostgreSQL, Branches und Operations-Konsole
- Kontakt, wir passen Branchly, DevStudioIT Cloud und Ihre Prisma-Pipeline an
- Betreuungspaket, Backups, Monitoring und Support nach dem Deployment
Über den Autor
Wir bauen schnelle Websites, Web/Mobile-Apps, KI-Chatbots und Hosting — mit Fokus auf SEO und Conversion.
Empfohlene Links
Von Theorie zu Produktion — Branchly, Hosting-Stack und Referenzen.
