Woher wir kommen
Wir sind keine Neulinge. Vor Rebase haben wir FireCMS gebaut — ein open-source CMS für Firebase, im Einsatz in über 10.000 Projekten weltweit, vertraut von Teams bei Microsoft und IKEA. Jahrelang haben wir gelernt, was Entwickler wirklich von einem Admin-Panel brauchen, woran Content-Redakteure scheitern und wo jedes CMS irgendwann an seine Grenzen stößt.
FireCMS hat uns eine Menge gelehrt. Dass Entwickler Flexibilität wollen, kein Lock-in. Dass Endnutzer Schönheit und Einfachheit wollen, keine Formularwüste. Dass die besten Tools unsichtbar werden und Menschen einfach arbeiten lassen.
Aber FireCMS war an Firebase gebunden. Und als sich die Branche klar in Richtung Postgres, offene Standards und Datensouveränität bewegte, wussten wir: Es wird Zeit für etwas Größeres. Etwas, das als Fundament für jedes digitale Projekt taugt — nicht nur für solche auf einem einzigen Cloud-Anbieter.
Das Problem, das uns nicht loslässt
Jedes neue Projekt beginnt gleich. Du brauchst eine Datenbank. Ein Admin-Panel. Auth, eine API-Schicht, Dateispeicher, Berechtigungen. Das alles hast du schon dutzende Male gebaut. Und trotzdem: Jedes Mal fängst du bei null an — oder kettest dich an eine Plattform, der deine Daten und deine Roadmap gehören.
Die Cloud-Plattformen haben es bequem gemacht. Firebase, Supabase, die ganzen Managed-CMS-Tools — du konntest die ganze Basisarbeit überspringen und direkt loslegen. Dass jemand anderes die Infrastruktur betreibt, war nie das Problem; kaum ein Team will einen Postgres-Cluster babysitten. Das Problem ist, was üblicherweise mitkommt: ein Schema, das du nur über deren Konsole lesen kannst, Kosten, die du nicht vorhersagen kannst, und ein Ausstieg, der ein Rewrite bedeutet. Bequemlichkeit sollte eine Rechnung sein, die du kündigen kannst — keine Entscheidung, die du nicht zurücknehmen kannst.
Auf der anderen Seite stehen die Self-Hosted-Tools — aber die fühlen sich oft an, als kämen sie aus einer anderen Ära. Umständlich einzurichten, mühsam anzupassen und gebaut für eine Welt vor KI, vor TypeScript-everywhere, vor der Erwartung, dass Werkzeuge einfach funktionieren.
Woran wir glauben
Autorisierung gehört in die Datenbank
Das ist die Überzeugung, auf die wir die gesamte Architektur gesetzt haben — und die, die am ehesten Streit auslöst. Zugriffsregeln im Anwendungscode sind Regeln, an denen ein vergessener Endpunkt, ein Hintergrund-Job, ein Migrationsskript oder eine direkte SQL-Konsole einfach vorbeilaufen: Sie schützen die Tür, nicht den Raum. In Rebase ist Autorisierung Postgres Row-Level Security: in TypeScript geschrieben, zu echten Policies kompiliert, von der Datenbank selbst bei jeder Anweisung und für jeden Aufrufer durchgesetzt. Eine Tabelle ohne Policy wird gar nicht erst ausgeliefert. Wir scheitern geschlossen, auch wenn das unbequem ist — auch wenn deine allererste Abfrage leer zurückkommt und du erst eine Regel schreiben musst. Jedes andere Modell, das wir ausgeliefert haben, ist irgendwann undicht geworden. Dieses kann es nicht.
Deine Datenbank ist deine Wahrheit
Wir legen keine Schatten-Datenbanken an. Wir verstecken dein Schema nicht hinter einer proprietären Schicht, und wir verlangen nicht, dass du deine Daten zweimal modellierst. Rebase verbindet sich mit deinem Postgres, liest deine Tabellen und baut auf dem auf, was schon da ist — was du in psql siehst, ist das, was die API ausliefert. Und wenn du Rebase morgen löschst, liegen deine Daten genau dort, wo du sie gelassen hast, in einer Form, die du weiter nutzen kannst. Ein Backend, aus dem du nicht herauskommst, ist keine Infrastruktur, sondern eine Geiselnahme.
Agenten sind Nutzer deines Backends, kein aufgesetztes Feature
Ein großer und wachsender Teil des Codes, der gegen dein Backend geschrieben wird, stammt inzwischen von einem Agenten — und Agenten lesen keine Dashboards. Sie lesen Schemata, Typen und Fehlermeldungen. Deshalb liefert Rebase einen MCP-Server, maschinenlesbare Collection-Definitionen, ein generiertes typisiertes SDK und API-Keys mit begrenztem Geltungsbereich. Und wir behandeln eine unklare Fehlermeldung als Bug, egal ob sie ein Mensch oder ein Modell liest. Werkzeuge, die nur für einen Menschen am Klick-Interface gebaut sind, werden heute schon eher umgangen als benutzt.
Open Source ist ein Fundament, kein Feature
Rebase ist MIT — jedes Paket, jede Zeile. Kein Open-Core mit der nützlichen Hälfte hinter einem Lizenzschlüssel. Kein Source-Available mit einer Klausel darüber, wer mit uns konkurrieren darf. Wir haben zu viele Infrastrukturprojekte gesehen, die „Open Source“ als Trichter benutzt und neu lizenziert haben, sobald die Community ihren Teil geleistet hatte — und wir wissen genau, wie sich das von außen anfühlt. Die Lizenz ist das Versprechen, und MIT ist die einzige Fassung dieses Versprechens, die wir später nicht stillschweigend zurücknehmen könnten. Und das gilt bis ganz nach unten: Postgres, Node, Hono, Drizzle — jede Schicht unter Rebase ist ebenfalls Open Source, und keine davon braucht unsere Infrastruktur, um zu laufen. Genau das macht „überall deploybar“ zu einer Tatsache der Architektur und nicht zu einer Zeile auf einer Preisseite. Geld verdienen wollen wir schon — damit, dass wir Rebase für Teams betreiben, die es nicht selbst betreiben wollen. Das ist eine Rechnung, die du kündigen kannst, und übrig bleibt genau derselbe Code, den wir betrieben haben.
Europa sollte seine Infrastruktur selbst besitzen
Wir bauen aus Madrid, und wir halten den aktuellen Zustand — in dem die meisten europäischen Unternehmen ihre Daten auf Infrastruktur betreiben, die anderen gehört und fremdem Recht unterliegt — für einen strategischen Fehler, den es zu korrigieren lohnt. Datensouveränität und DSGVO sind bei uns kein Compliance-Häkchen auf der Roadmap, sondern der Grund, warum mehrere Design-Entscheidungen hier den schwereren Weg genommen haben. Du kannst Rebase überall auf der Welt betreiben, und wir würden uns freuen, wenn du es tust. Aber in diesem Punkt sind wir nicht neutral.
Für wen ist Rebase?
Für alle, die es satthaben, sich zwischen Komfort und Kontrolle entscheiden zu müssen:
- Entwickler, die Firebase-Tempo wollen — ohne Firebase-Lock-in
- Startups, die heute schnell sein müssen und morgen skalieren — ohne Plattformwechsel
- Agenturen, die es leid sind, für jeden Kunden dasselbe Admin-Panel nochmal zu bauen
- Enterprise-Teams, die ihre Daten auf eigener Infrastruktur brauchen — mit lückenlosem Audit-Trail
Rebase ist hochmodular — nimm das Admin-Panel, die API-Schicht, das SDK oder die ganze Plattform. Nur das, was du brauchst. Du bestimmst, wie viel vom Stack du einsetzt — und wo er läuft: dein Laptop, deine eigenen Server oder gehostet bei uns. In allen drei Fällen ist es derselbe MIT-lizenzierte Code, der Wechsel ist also ein Redeploy, keine Migration.
Gebaut für drei Welten
Die meisten Tools haben eine einzige Zielgruppe. Wir bauen für drei — weil die beste Plattform eine ist, auf der alle produktiv arbeiten können:
Endnutzer
Schöne, intuitive Oberflächen, die auch nicht-technische Menschen gerne nutzen.
Entwickler
TypeScript-nativ, React-erweiterbar, mit APIs und SDKs, die sich anfühlen, als wären sie für dich gemacht.
KI-Agenten
MCP-Server, strukturierte APIs und maschinenlesbare Schemas — damit auch Agenten mit Rebase bauen können.
Unser Versprechen
Wir bauen Rebase nicht zum Verkaufen und nicht, um dich einzusperren. Wir bauen es, weil wir seit Jahren Developer-Tools machen und genau wissen, was fehlt: eine offene, durchdachte, Postgres-native Plattform, die deine Daten, deine Zeit und deine Intelligenz respektiert.
Wir shippen schnell, und wir shippen öffentlich — das Changelog und der Issue-Tracker sind der Beleg. Rebase ist früh dran. Früh genug, dass die Überzeugungen oben noch das ganze Produkt sind, und früh genug, dass ein Argument von dir eine davon noch ändern kann. Das ist der beste Moment, um dazuzukommen.
Wenn dich das anspricht — wenn du dieselbe Frustration kennst, wenn du an dasselbe glaubst — dann bau mit uns.
Das Rebase-Team
Madrid · Open-Source-Entwicklerwerkzeuge seit 2020
