Seiten ausliefern statt Tickets
Klick in diesen Text und schreib ihn um.
PageKit — der selbst gehostete GrapesJS-Website-Builder, als Quellcode. Early Access sichern
Gib deinen Nutzern einen visuellen Editor, mit dem sie Webseiten aus Drag-and-drop-Komponenten, wiederverwendbaren Blöcken und responsiven Styles bauen – ohne dass du die Editor-Infrastruktur von Grund auf schreibst.
26k+
GitHub-Sterne
1.4M+
npm-Downloads pro Monat
100+
Plugins auf GJS.Market
BSD-3-Clause
Lizenz des Cores
Zieh einen Block aus der Palette auf die Arbeitsfläche – oder tippe erst den Block an, dann die Fläche. Bearbeite den Text direkt, verändere Abstand und Radius und wechsle den Viewport, um zu sehen, wie sich das Layout anpasst. Das hier ist ein Modell der Interaktion; der echte GrapesJS-Editor kommt einen Abschnitt weiter unten.
Blöcke
Zieh einen Block herein – oder tippe erst den Block an, dann die Fläche.
Klick in diesen Text und schreib ihn um.
Drei Spalten auf dem Desktop, eine auf dem Handy.
Styles
Akzent
Drei öffentliche GrapesJS-Builds, die erst laden, wenn du es willst – vorher wird nichts angefordert.
Die Standard-Demo von GrapesJS: Blockpalette rechts, Arbeitsfläche in der Mitte, Style-Manager und Ebenenbaum. Alles, was du hier siehst, steckt im Open-Source-Core.
Lädt eine Drittanbieter-Demo in einem iframe. Vor deinem Klick wird nichts angefordert.
Eine Seite, von Anfang bis Ende
Sechs Teilsysteme, die mit dem Core kommen – und die deine Nutzer als eine einzige Geste erleben.
Ziehe Blöcke und Komponenten direkt auf die Arbeitsfläche und sortiere sie dort neu.
Bearbeite Inhalte und Styles auf der Seite selbst – Typografie, Abstände, Farbe und Hintergrund, ganz ohne Stylesheet.
Passe Layouts über den Device-Manager und Breakpoints des Editors an verschiedene Bildschirmgrößen an.
Baue Abschnitte einmal und nutze sie auf mehreren Seiten – eine Änderung wirkt überall.
Verwalte Bilder und andere Medien über den Asset-Manager, angebunden an den Speicher, den du ohnehin nutzt.
Binde den Editor an deinen eigenen Publishing-Workflow – GrapesJS gibt dir HTML und CSS, was danach passiert, entscheidest du.
Jeder dieser Punkte ist ein Teilsystem, das du sonst selbst entwerfen, bauen und dauerhaft pflegen müsstest.
GrapesJS ist ein selbst gehostetes Open-Source-Editor-Framework und kein gehostetes Builder-Produkt. Genau dieser Unterschied macht es tauglich für den Einsatz in fremden Anwendungen.
Starte auf einem offenen Editor-Fundament. Der Core erscheint unter BSD-3-Clause, der offizielle React-Wrapper unter MIT – beide erlauben kommerzielle Nutzung, ohne Lizenzgebühr.
Der Editor läuft in deiner eigenen Infrastruktur. Zwischen dir und deinen Nutzern steht kein Editor-Anbieter, und nichts verlässt deinen Stack, außer du schickst es weg.
Erstelle eigene Blöcke, Komponententypen, Befehle und Panels. Die Plugin-API ist dieselbe, gegen die auch die Plugins des Ökosystems geschrieben sind.
Tausche Panels aus, gestalte die Hülle neu oder steuere den Editor vollständig aus deiner eigenen Oberfläche. Die UI ist nicht festgelegt – die Demos oben zeigen es.
Der Storage-Manager spricht mit deinen Endpunkten. Projekte, Seiten, Assets und Nutzer bleiben in deiner Datenbank, hinter deiner Authentifizierung.
Erweitere den Editor mit Plugins von GJS.Market und npm, statt jede Fähigkeit selbst zu schreiben.
Darunter derselbe Editor-Kern, jedes Mal für eine andere Aufgabe konfiguriert.
Lass Nutzer aus einem kuratierten Blockset Landingpages bauen, die auf Conversion ausgelegt sind.
Landingpage-BuilderBaue vollständige mehrseitige Websites mit wiederverwendbaren Layouts und gemeinsamer Navigation.
WYSIWYG-Website-BuilderGib Kunden visuelles Seitenerstellen als Funktion direkt in deiner Anwendung.
SaaS-Page-BuilderErgänze einen bestehenden Content-Workflow um eine visuelle Ebene, statt ihn zu ersetzen.
Headless-CMS-EditorLass Marketing-Teams Seiten bauen und aktualisieren, ohne einen Pull Request zu öffnen.
No-Code für EntwicklerGib Kunden kontrolliertes Seitenbauen – die Blöcke, die du erlaubst, im Rahmen, den du festlegst.
White-Label-Page-BuilderUnterschiedliche Gründe, aber darunter immer dasselbe Problem: Seiten zu erstellen sollte nicht jedes Mal eine Entwicklerin kosten.
Mach das Erstellen von Seiten zur Produktfunktion, ohne dass Kunden deine App verlassen.
Bau dein eigenes visuelles Editing-Erlebnis, statt das eines anderen weiterzuverkaufen.
Setz eine visuelle Ebene auf das Content-Modell, das du bereits hast.
Baue wiederverwendbare Seitensysteme, die Kunden auch zwischen zwei Projekten selbst bedienen können.
Verkleinere die Warteschlange aus Routine-Layout- und Textänderungen, die heute bei der Entwicklung landet.
Starte mit einem erweiterbaren Editor-Kern statt mit einer leeren Fläche und einer Drag-and-drop-Bibliothek.
Ein Page-Builder ist keine Funktion, sondern ein Dutzend Teilsysteme, die zueinander passen müssen – und weiter zueinander passen müssen, während das Produkt wächst.
Was in einem Page-Builder tatsächlich steckt
Arbeitsfläche, Ablagebereiche, Auswahl, Style-Panel, Breakpoints, Asset-Bibliothek, mehrseitiger Zustand, Persistenz, ein Undo-Stack, der das alles überlebt, Export, Veröffentlichung – und die dauerhafte Pflege des Ganzen.
Visueller Editor, Drag & Drop, Blöcke, Komponenten, Style-Manager, Assets, Seiten, Storage-APIs und das Plugin-System kommen mit dem Core. Du ergänzt den Teil, der für dein Produkt spezifisch ist.
Bau dein Produkt – nicht noch einen Page-Builder von Grund auf.
Keine der beiden Spalten ist umsonst. Der Unterschied liegt darin, welche Arbeit dir gehört.
| Teilsystem | Von Grund auf | Mit GrapesJS |
|---|---|---|
| Editor-Arbeitsfläche | Selbst entwerfen und bauen | Im Core enthalten |
| Drag & Drop | Ablagebereiche, Indikatoren, Verschachtelungsregeln | Im Core enthalten |
| Blöcke | Format und Palettenoberfläche definieren | Block-Manager, dazu fertige Block-Plugins |
| Komponenten | Eigenes Komponentenmodell samt Traits | Komponententypen mit Traits und eigenem Verhalten |
| Style-Manager | Visuellen CSS-Editor bauen | Im Core, Sektoren konfigurierbar |
| Responsive-Steuerung | Breakpoint-Zustand durch den ganzen Editor | Device-Manager, per Plugin erweiterbar |
| Assets | Bibliothek, Upload-Flow, Auswahldialog | Asset-Manager, angebunden an deinen Speicher |
| Seiten | Mehrseitiger Zustand und Navigation | Page-Manager |
| Speicherung | Serialisierungsformat und Endpunkte | Storage-Manager gegen deine API |
| Rückgängig / Wiederholen | Ein Command-Stack über jede Änderung | Im Core enthalten |
| Export | HTML/CSS selbst erzeugen | getHtml() / getCss(), dazu Export-Plugins |
| Veröffentlichen | Deine Aufgabe | Deine Aufgabe – bewusst so |
| Wartung des Editors | Deine Aufgabe | Geteilt mit einem Open-Source-Projekt und seinem Ökosystem |
Das Veröffentlichen bleibt bewusst in deiner Spalte: Es ist der Teil, der zu deinen Domains, deinem CDN und deinem Release-Prozess passen muss.
GrapesJS ist eine Schicht in deiner Anwendung, keine Plattform, an die du deine Nutzer übergibst. Nutzer, Inhalte und die Entscheidung zu veröffentlichen bleiben bei dir.
Deine Anwendung
Die Oberfläche gehört dir
Eingebettete Schicht
GrapesJS-Editor
Mit Plugins erweiternPersistenz
Deine API
Daten
Deine Datenbank
Auslieferung
Dein Publishing
Zur Mechanik, den Editor in eine bestehende App zu hängen – iframes, Routing, Auth-Übergabe – siehe den Leitfaden zum einbettbaren Page-Builder
Der Device-Manager des Editors schaltet die Arbeitsfläche zwischen Breakpoints um, und Styles, die bei aktivem Gerät gesetzt werden, gelten nur für diese Breite.
Was sich pro Breakpoint ändern lässt
Lass Nutzer Layout, Abstände, Typografie und Sichtbarkeit für verschiedene Bildschirmgrößen anpassen. Wie eine veröffentlichte Seite auf einem bestimmten Gerät am Ende aussieht, hängt weiterhin vom ausgelieferten HTML und CSS ab – der Editor steuert die Regeln, nicht den Browser.
Ein Block ist der Ausgangspunkt, den ein Nutzer hereinzieht. Das sind die Abschnittstypen, die die meisten Page-Builder am ersten Tag brauchen – baue sie selbst gegen die Block-Manager-API oder installiere ein Block-Plugin und starte mit einer vollen Palette.
Überschrift, Begleittext und eine Hauptaktion.
Logo und Navigation, auf kleinen Bildschirmen als Menü.
Ein Spaltensatz für Vorteile, mit Icon, Titel und Text.
Tarifkarten, eine davon als Empfehlung hervorgehoben.
Zitate mit Namensnennung und Avatar.
Ein Bildraster, gefüllt aus dem Asset-Manager.
Eine einzelne, zentrierte Handlungsaufforderung.
Ein Formular, angebunden an den Endpunkt deiner Wahl.
Linkspalten, Rechtliches und sekundäre Navigation.
Das sind Blocktypen, keine Produkte. Die tatsächlich erhältlichen Block-Plugins stehen weiter unten auf dieser Seite.
An dieser Unterscheidung entscheidet sich, ob GrapesJS für dich ein Website-Baukasten-Spielzeug ist oder ein Editor-Kern, auf dem du ein Produkt bauen kannst.
Block
Ein Eintrag in der Palette. Ihn auf die Fläche zu ziehen fügt Inhalt ein – der Block selbst ist nicht das, was auf der Seite bleibt.
Komponente
Das, was aus dem Block nach dem Ablegen wird. Komponenten haben einen eigenen Typ, Traits und Regeln dazu, was verschachtelt, gezogen oder entfernt werden darf.
Eigene Komponente
Registriere deinen eigenen Komponententyp, und der Editor behandelt ihn als vollwertiges Element: deine Traits, deine Toolbar, deine Einschränkungen, gestützt auf deine Daten.
Weil eigene Komponenten auf deinem Code beruhen, kann ein GrapesJS-Editor Dinge bearbeiten, für die ein generischer Website-Baukasten gar keinen Begriff hat – eine Preistabelle an deinen Tarifen, ein Produktraster aus deinem Katalog, ein Formular an deiner API.
Die wenigsten Nutzer wollen eine leere Seite. Liefere einen Satz Startlayouts und lass sie eigene speichern – Presets konfigurieren den ganzen Editor, Vorlagen geben eine Seite zum Weiterarbeiten.
Die Layouts, nach denen Nutzer typischerweise fragen
Das sind Layout-Kategorien, keine Katalogeinträge – also das, was du für deine eigenen Nutzer bauen oder kuratieren würdest. Die tatsächlich installierbaren Presets und Vorlagenmanager stehen im Plugin-Abschnitt unten.
Der Storage-Manager ist ein Client deiner API, kein Dienst. Richte ihn auf deine Endpunkte, und der Editor lädt und speichert darüber.
Wohin die Daten gehen
const editor = grapesjs.init({
container: '#editor',
// Each page is a row in your database, behind your own auth.
storageManager: {
type: 'remote',
autosave: true,
options: {
remote: {
urlStore: `/api/pages/${pageId}`,
urlLoad: `/api/pages/${pageId}`,
fetchOptions: { credentials: 'include' },
},
},
},
});
// Publishing stays on your side — your domains, your CDN, your workflow.
async function publish() {
await fetch(`/api/pages/${pageId}/publish`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ html: editor.getHtml(), css: editor.getCss() }),
});
}Verbinde GrapesJS mit deinem eigenen Backend und entscheide, wie Projekte, Seiten, Assets und Nutzer gespeichert werden. GJS.Market verkauft Plugins – es hostet deine Daten nicht.
Der Nutzer baut die Seite
Ziehen, ablegen, bearbeiten und gestalten auf der Arbeitsfläche. Autosave hält angefangene Arbeit wiederherstellbar.
Über deine API sichern
Der Storage-Manager schickt das Projekt an deinen Endpunkt. Veröffentlicht ist damit noch nichts.
So rendern, wie Besucher es sehen
Exportiere HTML und CSS und zeige die Vorschau auf einer Route, die nur die Autorin erreicht.
Dein Workflow, deine Regeln
Freigaben, Terminierung, Versionierung – was dein Produkt ohnehin tut. GrapesJS ist an diesem Schritt nicht beteiligt.
Aus deiner Infrastruktur ausgeliefert
Deine Domains, dein CDN, dein Caching. Die Seite ist ganz normales HTML und CSS.
GrapesJS kümmert sich um das Bearbeitungserlebnis. Deine Anwendung steuert den Publishing-Workflow.
Jede Karte hier unten ist ein echter Eintrag – Namen, Preise und Vorschaubilder kommen live aus dem Katalog, damit nichts auf dieser Seite von dem abweichen kann, was tatsächlich verkauft wird.
Der Grundstock an Layout-Bausteinen – Spalten, Text, Bilder, Links – damit die Palette am ersten Tag nicht leer ist.
Eine Blockbibliothek auf Tailwind-Basis, für Teams, deren Designsystem ohnehin in Utility-Klassen denkt.
Ein deutlicherer Ablage-Indikator, damit man vor dem Loslassen genau sieht, wo der Block landet.
Ziehbare Griffe für Außen- und Innenabstand, sodass Abstände auf der Fläche statt in einem Zahlenfeld gesetzt werden.
Abschnitte einmal bauen und auf mehreren Seiten nutzen.
Diese Kategorie ansehenVier Startkonfigurationen. Jede ist ein echter Warenkorb aus Einträgen, kein Bundle – installiere, was du brauchst, und lass den Rest weg.
Für Marketingseiten, die konvertieren müssen
Für mehrseitige Sites mit gemeinsamen Layouts
WYSIWYG-BuilderFür das Erstellen von Seiten in deinem Produkt
Für eine visuelle Ebene über bestehenden Inhalten
Preise kommen live aus dem Katalog.
Zwei Dateien, und der Editor steht auf dem Bildschirm. Alles danach ist Konfiguration.
npm install grapesjsimport grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
// The editor core. Mount it on any container in your app.
const editor = grapesjs.init({
container: '#editor',
});Dann legst du fest, was Nutzer ziehen können – und was daraus wird, wenn sie es ablegen:
// A block is what the user drags. A component is what it becomes
// on the canvas once dropped — and what your app can then control.
editor.BlockManager.add('pricing-table', {
label: 'Pricing',
category: 'Sections',
content: { type: 'pricing-table' },
});
editor.DomComponents.addType('pricing-table', {
model: {
defaults: {
// Lock the frame, let the user edit only what you allow.
draggable: 'main, section',
traits: ['plan', 'currency'],
},
},
});Ab hier ist die Arbeit produktspezifisch: welche Blöcke deine Nutzer bekommen, welche Komponententypen du registrierst und wo Projekte gespeichert werden.
Der Core ist framework-agnostisch – er wird auf einen DOM-Container gehängt. Diese Seiten behandeln die Verdrahtung im Einzelnen.
Ganz ohne Framework: Core importieren, auf einen Container hängen, fertig.
HTML-Drag-and-drop-BuilderDer offizielle @grapesjs/react-Wrapper (MIT) übernimmt Mounten und Aufräumen.
GrapesJS mit ReactNur clientseitig mounten, dynamisch importieren – und die SSR-Fallen, die man umgehen sollte.
Next.js-Page-BuilderIn einer Komponente mounten und beim Unmount sauber aufräumen.
GrapesJS mit VueDen Editor in eine Komponente packen und aus der Change Detection heraushalten.
GrapesJS mit AngularNur Eigenschaften, die sich gegen das veröffentlichte Paket und die Dokumentation des jeweiligen Projekts prüfen lassen. Die Fähigkeiten unterscheiden sich schon durch das Designziel – Craft.js ist bewusst headless, Puck ist React-first, Builder.io ist eine gehostete Plattform.
| Eigenschaft | GrapesJS | Puck | Craft.js | Builder.io |
|---|---|---|---|---|
| Open Source | Ja – BSD-3-Clause | Ja – MIT | Ja – MIT | SDKs MIT; Plattform proprietär |
| Selbst gehostet | Ja | Ja | Ja | Gehosteter Dienst |
| Framework | Framework-agnostisch; React-Wrapper verfügbar | React | React | SDKs für mehrere Frameworks |
| Eigene Blöcke | Ja – Block-Manager | Ja – Komponentenkonfiguration | Ja – User Components | Ja – registrierte Komponenten |
| Eigene Komponenten | Ja – Komponententypen mit Traits | Ja – React-Komponenten mit Feldern | Ja – React-Komponenten mit Settings | Ja – mit Inputs |
| Eigene Editor-Oberfläche | Ja – Panels austauschbar, oder headless steuerbar | Mitgelieferte UI, thembar | Selbst mitbringen – keine UI enthalten | UI des Anbieters |
| Eigenes Storage-Backend | Ja – Storage-Manager gegen deine API | Ja – Persistenz liegt bei dir | Ja – Zustand persistierst du | Inhalte liegen bei Builder.io |
| Eigenes Publishing | Ja | Ja | Ja | Über die Builder.io-APIs |
| Plugin-Ökosystem | Ja – GJS.Market und npm | Wachsend | Klein | Integrationen des Anbieters |
Lizenzen am 2026-09-03 gegen die npm-Registry geprüft: grapesjs 0.23.6 erscheint unter BSD-3-Clause; @measured/puck, @craftjs/core und @builder.io/react erscheinen unter MIT. Die Fähigkeiten geben die öffentliche Dokumentation der Projekte wieder – prüfe sie vor einer Entscheidung selbst.
Derselbe Editor-Kern, eine andere Frage. Wenn eine davon deine Lage genauer trifft, fang dort an.
Der geschäftliche Fall für einen Builder im SaaS – was Kunden davon haben und wie man es verpackt.
SaaS-Page-BuilderDer technische Durchgang, den Editor in eine bestehende Anwendung zu hängen.
Einbettbarer Page-BuilderBranding, Theming und Mandantenfähigkeit, wenn der Editor nach dir aussehen muss.
White-Label-Page-BuilderDas vollständige Bild zu Lizenzen und Selbst-Hosting.
Open-Source-Page-BuilderStarte mit GrapesJS, passe das Bearbeitungserlebnis an und erweitere es um die Plugins, die dein Produkt braucht.
Blöcke, Vorlagen, Speicherung, Assets, Export und KI – echte Einträge mit echten Preisen.
Page-Builder-Plugins ansehenCore installieren, Editor mounten, ersten Block registrieren. Ganz ohne Anmeldung.
LoslegenEigene Komponenten, Editor-Oberfläche, Anbindung an dein Backend – sag uns, was der Builder können muss.
Individuelle Entwicklung nötig?