Vue Page Builder with GrapesJS

The stock editor with no theme applied. This is what you get before you configure anything — the starting point every builder below was customised from.

A production page builder is far more than a few Vue components. It is a canvas, a drag-and-drop system, a component model, a style engine, responsive editing, undo history, asset handling, storage and export. Here is the whole surface, and who ends up owning each piece.

• GrapesJS core

  Editing canvas

  An isolated document users edit directly, with its own styles and scroll.

• GrapesJS core

  Drag & drop

  Drop targets, insertion points, reordering and nesting rules.

• GrapesJS core

  Component model

  Typed elements with their own settings, constraints and behaviour.

• GrapesJS core

  Selection & toolbars

  Click-to-select, hover outlines, per-element toolbars and badges.

• GrapesJS core

  Style Manager

  Typography, colour, spacing and layout controls bound to selectors.

• GrapesJS core

  Responsive editing

  Device widths and breakpoint-scoped styles in the same canvas.

• GrapesJS core

  Layer Manager

  A tree of the page so deep structures stay navigable.

• GrapesJS core

  Undo & redo

  A command history across every edit, not just text.

• GrapesJS core

  HTML & CSS export

  Clean markup and stylesheet generated from the current document.

• Plugins

  Block library

  The ready-made sections users drag in. Yours, or installed.

• Plugins

  Templates

  Whole starting layouts so nobody meets a blank canvas.

• Plugins

  Asset management

  Uploads, media libraries and image handling.

• Plugins

  Rich text editing

  Inline text formatting beyond the built-in editor.

• Plugins

  Multi-page projects

  More than one page inside a single project.

• Your Vue app

  Storage

  Where project data is written and read. Your API, your database.

• Your Vue app

  Authentication & roles

  Who may open, edit and publish which project.

• Your Vue app

  Multi-tenancy

  Isolating one customer's pages, assets and templates from another's.

• Your Vue app

  Publishing & hosting

  Turning approved output into a live page on your infrastructure.

• Your Vue app

  Plans & billing

  What each customer is entitled to, and what they pay for it.

The middle column is the point of GJS.Market: it is real capability you install rather than schedule. The right-hand column never becomes someone else's problem — that is your product, and this page is explicit about it in every section that touches it.

GrapesJS is not a replacement for your application and not a hosted service. It is an editing engine that mounts into one element of one route. Everything above and below it in this diagram stays yours.

1. 01

   Your Vue / Nuxt application

   Everything that makes the product yours. GrapesJS has no opinion about any of it.

   • Authentication
   • Users
   • Routing
   • Billing
   • Business logic
   • APIs
   ↓
2. 02

   The GrapesJS editor

   One mounted instance, inside one component, on one route. This is the layer you are not building.

   • Canvas
   • Blocks
   • Components
   • Styles
   • Layers
   • Assets
   ↓
3. 03

   Your backend

   The editor hands you two artefacts and one media stream. What happens next is your API's decision.

   • Project JSON
   • HTML + CSS
   • Media
   • Roles
   ↓
4. 04

   Your database

   Ordinary rows in a schema you designed. Nothing here is a GrapesJS format you have to adopt.

   • Projects
   • Versions
   • Tenants
   • Pages

Read it top to bottom: your Vue application authenticates the user and routes them to an editor page; the editor produces project data; your API writes it to your database. The editor never talks to your database, and your database never has to understand the editor.

No. This is the first question most Vue developers ask, and the answer changes how the rest of the page reads. The two layers do not overlap: one runs your application, the other runs an editing surface inside it.

One honest caveat while we are here: the canvas renders plain DOM inside an iframe, not mounted Vue components. Your app is Vue; what your users edit is HTML and CSS that your app then renders however it likes.

The difference between a generic website builder and a builder that belongs in your product is the component set. Do not force your content model into someone else's element types — register your own.

// builder/registerProductBlocks.ts
import type { Editor } from 'grapesjs';

// A plugin is just a function that receives the editor, so everything below
// works identically in Vue, Nuxt, React or a plain HTML page.
export function registerProductBlocks(editor: Editor): void {
  // A custom component type: your own element, with your own settings.
  editor.DomComponents.addType('pricing-table', {
    isComponent: (el) => el.dataset?.gjsType === 'pricing-table',
    model: {
      defaults: {
        droppable: false,
        traits: [
          { name: 'plan', type: 'select', options: ['free', 'pro', 'team'] },
          { name: 'highlight', type: 'checkbox' },
        ],
      },
    },
  });

  // A block: what the user actually drags in from the panel.
  editor.BlockManager.add('pricing-table', {
    label: 'Pricing',
    category: 'Sections',
    content: { type: 'pricing-table' },
  });
}

• A component type defines what an element is: what it accepts, what it refuses, and which settings it exposes.
• A block is what users see in the panel — the same type can back several blocks with different presets.
• Traits become the settings sidebar, so your users configure elements instead of editing markup.
• `droppable: false` and matching constraints are how you keep a designed component from being taken apart.
• Commands let you attach your own actions — publish, duplicate to another tenant, request review.
• None of this is Vue-specific: a plugin is a function that receives the editor, so it also works in Nuxt, React or plain HTML.

Don't force your product into a generic website builder. Customise the editor around your own content model and design system.

An unrestricted canvas produces pages that embarrass the product they live in. The editor is configurable in both directions — the useful setting is not maximum freedom, it is bounded freedom.

Give users creative freedom without letting them break your product's design system.

The single biggest driver of whether a page builder gets used is what is waiting in the block panel on the first visit. Build the sections your product actually needs, or install a library and rename it.

• Hero

  Headline, supporting line and a primary action.

• Feature grid

  A repeating grid of capabilities or benefits.

• Pricing

  Plan columns with features and a call to action.

• Testimonials

  Quotes with attribution, in a row or a carousel.

• FAQ

  Question and answer pairs, expandable or flat.

• Contact

  A form section posting to your own endpoint.

• CTA strip

  A full-width band with one clear action.

• Footer

  Navigation columns, legal links and brand marks.

GrapesJS does not host anything and does not choose a database. You register a storage adapter with two methods — load and store — and both talk to your API. Nothing leaves your infrastructure.

const editor = grapesjs.init({
  container: host.value!,
  storageManager: {
    type: 'app-api',
    autosave: true,
    stepsBeforeSave: 10,
  },
  // Registered as a plugin so the adapter exists before the first load().
  plugins: [
    (ed) => {
      ed.Storage.add('app-api', {
        async load() {
          const res = await fetch(`/api/projects/${props.projectId}`);
          if (!res.ok) throw new Error(`Load failed: ${res.status}`);
          return await res.json();
        },
        async store(project) {
          const res = await fetch(`/api/projects/${props.projectId}`, {
            method: 'PUT',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify(project),
          });
          if (!res.ok) throw new Error(`Save failed: ${res.status}`);
        },
      });
    },
  ],
});

• Register the adapter as a plugin so it exists before the editor performs its first load.
• `autosave` with `stepsBeforeSave` batches writes instead of firing one per keystroke.
• Store the project JSON as the source of truth; it is what the editor reloads.
• Keep versions as ordinary rows — revision history is a schema decision, not an editor feature.
• Authorise every load and store on the server. The project id in the request is a claim, not a permission.
• Surface save state in your own Vue UI by listening to the editor's storage events.

You control your data and your backend. The editor is a client of your API like any other part of your app.

Two artefacts come out of the editor and they are not interchangeable. Storing the wrong one is the mistake that makes pages uneditable six months later.

// The source of truth. Store it; the editor reloads from it.
const projectData = editor.getProjectData();

// The output. Regenerate it every time you publish.
const html = editor.getHtml();
const css = editor.getCss();

await $fetch(`/api/projects/${projectId}/publish`, {
  method: 'POST',
  body: { projectData, html, css },
});

// Authorize the request and sanitize `html` on the server —
// never in the component that produced it.

Store project data for editing. Generate HTML and CSS when you need publishable output.

Authoring and publishing are different jobs. GrapesJS finishes at the moment a user is happy with a page; everything after that is your workflow, on your infrastructure.

Every customer gets their own pages, their own assets, their own templates and their own brand. That isolation is a property of your data model and your API — the editor is simply handed the right project.

Real listings from GJS.Market, grouped by the problem they remove. Every one of them installs into the same editor instance your Vue component creates.

Blocks & templates

The problem: an empty block panel on first run. What they add: ready-made sections, template management and multi-page projects. Who needs them: anyone whose users are not developers.

Browse this category

Plugin Basic Blocks

A starting block set, so the panel is useful before you write your own.

FreeView plugin

Plugin Blocky for Tailwind CSS

Tailwind-based sections for products whose design system is already Tailwind.

$59.00View plugin

Templates Manager

Save, list and apply whole layouts as reusable starting points.

$39.00View plugin

Pages Manager

Multiple pages inside one project, with navigation between them.

$25.00View plugin

Storage & recovery

The problem: lost work and hand-rolled persistence. What they add: project management, autosave, crash recovery and alternative storage back ends. Who needs them: every product with real customers in the editor.

Browse this category

Grapesjs Project Manager

Project listing, creation and switching, instead of one editor per route.

FreeView plugin

Autosave & Restore — Crash Recovery for GrapesJS

Recovers unsaved work after a crash or a closed tab — the failure users never forgive.

$12.00View plugin

IndexedDB Storage

Local persistence in the browser, useful for drafts and offline editing.

FreeView plugin

Directus Storage

Reads and writes projects through a Directus backend rather than a custom API.

FreeView plugin

Assets & export

The problem: image handling and getting output out of the editor. What they add: upload widgets, CDN integrations, image editing and archive export. Who needs them: builders where users bring their own media.

Browse this category

Grapesjs Cloudinary

Uploads and serves editor media through Cloudinary.

FreeView plugin

Grapesjs Uppy

A full upload experience — drag-in, progress, multiple sources.

FreeView plugin

TOAST UI Image Editor

Crop, resize and adjust images inside the editor instead of before it.

FreeView plugin

Export Zip

Downloads the current project as an HTML/CSS archive.

FreeView plugin

Editing & layout

The problem: the editing surface is thinner than your users expect. What they add: richer text editing, forms, breakpoint control and per-component code. Who needs them: teams replacing an existing editor.

Browse this category

Grapesjs RTE Extensions

Extends inline text editing beyond the built-in toolbar.

FreeView plugin

Plugin Forms

Form components with typed fields, for builders that collect input.

FreeView plugin

Responsive Pack — Breakpoint Manager for GrapesJS

Manage breakpoints and device widths beyond the three defaults.

$14.00View plugin

Grapesjs Component Code Editor

Per-component HTML/CSS editing for the users who want it.

FreeView plugin

The same catalogue, cut by the product you are building. Install the stack that matches your case and ignore the rest — an editor with every plugin loaded is slower and harder to use, not better.

Prices shown are the current GJS.Market listing prices; free plugins are marked.

If a stack above does not match your product, start here instead. These are the catalogue sections, roughly in the order a builder grows into them.

• BlocksReady-made sections for the block panel.
• ComponentsNew element types with their own settings.
• PresetsWhole editor configurations, themed and ready.
• StoragesAdapters for persisting project data.
• AssetsUploads, media libraries and image tooling.
• StylesExtra controls for the Style Manager.
• Rich textInline text editing beyond the default toolbar.
• Web pagesPage-level features and complete page kits.
• NewslettersEmail output, MJML and campaign blocks.
• Developer toolsDebugging, inspection and build-time helpers.
• AIGeneration and assistance inside the editor.

Neither column is free. The question is only which one your team should be spending its time in.

No cost or time figures appear in this table on purpose — we do not know your team, and any number here would be invented.

Row by row, what you would be writing yourself and what already exists. "Extensible" means the engine provides the hook and you supply the behaviour — usually a few lines, sometimes a plugin.

Included = ships with the core. Extensible = a documented extension point, plus plugins where they exist.
Verified against GrapesJS 0.23.6 on 2026-09-02.

Five steps, one component. There is no official Vue wrapper and you do not need one: GrapesJS renders into a plain element, so the only Vue-specific question is which lifecycle hook calls `init()`. Install grapesjs 0.23.6, create the component, initialise on mount, pass your plugins, destroy on unmount.

1. 01Install GrapesJS
2. 02Create the editor component
3. 03Initialise on mount
4. 04Configure plugins
5. 05Destroy on unmount

<!-- components/PageBuilder.vue -->
<template>
  <div ref="host" class="page-builder" />
</template>

<script setup lang="ts">
import { onBeforeUnmount, onMounted, ref, shallowRef } from 'vue';
import grapesjs, { type Editor } from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

// shallowRef, not ref: the editor is a large non-reactive instance and
// deep-proxying it costs performance for nothing.
const editor = shallowRef<Editor | null>(null);
const host = ref<HTMLElement | null>(null);

onMounted(() => {
  editor.value = grapesjs.init({
    container: host.value!,
    height: '100%',
    fromElement: false,
    storageManager: false,
    plugins: [],          // GJS.Market plugins go here
    blockManager: { blocks: [] },
  });
});

onBeforeUnmount(() => {
  editor.value?.destroy();
  editor.value = null;
});
</script>

• `shallowRef`, not `ref`: the editor is a large non-reactive object and deep-proxying it costs performance for nothing.
• `onMounted` never runs on the server, which is what makes this safe in Nuxt without any extra machinery.
• `destroy()` on unmount matters — a route change that leaves an editor mounted leaks its listeners and its iframe.
• `storageManager: false` while you are wiring things up, then swap in your adapter when the API is ready.
• Import the editor stylesheet once; it styles the panels, not your application.
• Everything past this point — events, wrappers, the composable form — is on the integration guide.

GrapesJS needs a browser DOM. Under Nuxt's server render there is no `document`, so the editor has to be created on the client — which `onMounted` already guarantees. `<ClientOnly>` is the belt-and-braces version, and it is where the fallback markup lives.

<!-- pages/editor.vue -->
<template>
  <ClientOnly>
    <PageBuilder :project-id="route.params.id" />

    <template #fallback>
      <p class="editor-placeholder">Loading the editor…</p>
    </template>
  </ClientOnly>
</template>

<script setup lang="ts">
const route = useRoute();
</script>

• Use `<ClientOnly>` when you want a server-rendered fallback in place of the editor.
• The `.client.vue` suffix is Nuxt's own way of saying the same thing for a whole component.
• SSR is not the interesting part of this page — it is one boundary, and it is a two-line one.
• Everything outside the editor route renders on the server exactly as it does today.

Each of these is cheap to get right at the start and expensive to fix once customers are in the editor.

• ✕The mistake

  Initialising during SSR

  Calling `init()` anywhere that runs on the server throws, because there is no `document` to render the canvas into.

  ✓What to do instead

  Create the editor in `onMounted` only, and wrap the route in `<ClientOnly>` if you want a server-rendered fallback.

• ✕The mistake

  Saving only the HTML

  The rendered output cannot be turned back into an editable document. Every page saved this way is frozen the moment it is published.

  ✓What to do instead

  Store the project JSON as the source of truth and regenerate HTML and CSS whenever you publish.

• ✕The mistake

  Giving users an unlimited blank canvas

  Total freedom produces pages that break your design system, and a first-run experience with nothing in the panel produces no pages at all.

  ✓What to do instead

  Ship curated blocks and templates, and constrain the style properties users can reach.

• ✕The mistake

  Installing every plugin

  Each plugin adds panels, bundle weight and a surface your users have to understand. A crowded editor is harder to use, not more capable.

  ✓What to do instead

  Start with the stack for your product shape and add a plugin when a real need appears.

The things that separate a working demo from something you can put in front of paying customers.

Different products, one architecture. If you recognise your team here, the rest of this page is written for you.

Use Vue for your application and GrapesJS for the visual editing experience. Add your own components, blocks, templates, storage and publishing workflow — then extend the builder with GJS.Market plugins when you need more.