DEV Community: NextBlock™ CMS

Engineering a 4-Tier Onboarding Architecture for a Modern Next.js Framework

NextBlock™ CMS — Tue, 07 Jul 2026 17:56:49 +0000

The contemporary web engine landscape forces a hard compromise: you either choose heavy, abstracted graphical page builders with severe runtime performance penalties, or decoupled headless frameworks that fracture your development cycle across multiple code repositories and API endpoints.

When setting up NextBlock CMS—our AI-native full-stack alternative to WordPress built with React Server Components, Supabase, and Tailwind CSS—our engineering milestone was to offer a frictionless setup matrix that honors every developer's staging preference.

Bypassing the Configuration Tax

Traditional headless stacks rely on manual setup scripts or strict environment tables before the initial build can even compile. NextBlock completely flips this paradigm. We shifted configuration checks directly into an application-level Browser Setup Wizard.

Whether the database parameters are auto-injected by orchestration webhooks at the server tier (Vercel) or written dynamically to a local drive via Node's native file system (fs/promises) during a local command boot, the framework handles the schema delivery automatically on boot.

The 4 Installation Spectra Explained

We have just published our optimized onboarding guide outlining the exact mechanics of our 4 tracks:

One-Click Vercel Production: Completely serverless, edge-cached layout running safely on free tiers with auto-applied migrations.
CLI ➔ Docker Local Sandbox: npm create nextblock@latest my-site running on an isolated Docker Desktop volume layout with zero cloud overhead.
CLI ➔ Custom Managed Cloud: Scaffolding a lightweight project pointed directly at your production Supabase database and Cloudflare R2 storage assets.
Raw Nx Monorepo Clone: Advanced git clone architecture running on port 4200 for internal engine customization.

🔗 Read the full blueprint: https://nextblock.dev/article/how-to-setup-nextblock
🔗 Star our repository: github.com/nextblock-cms/nextblock

What does your favorite local staging stack look like? Let’s talk architecture in the comments below! 👇

How We Built a Zero-Config, Auto-Updating Engine for a Serverless Next.js CMS

NextBlock™ CMS — Thu, 02 Jul 2026 14:27:25 +0000

Upstream framework updates are notoriously tricky for open-source self-hosted tools. If a user modifies your base template code, a rogue git pull could easily wipe out their hard work or introduce breaking application bugs.

When designing the update pipeline for NextBlock CMS, we established two strict architectural guidelines:

The user must not need to configure complex GitHub OAuth apps or Personal Access Tokens.

Live production pipelines must never compile code containing active merge conflicts.

Here is the exact engineering blueprint we implemented to achieve an automated, non-destructive update cycle across Vercel and Supabase:

Decentralized Git Orchestration via GitHub Actions
Instead of relying on heavy central authentication handshakes to modify files , we bundle a native workflow routine (.github/workflows/nextblock-sync.yml) straight into our repository template. Every day at midnight, a cron job executes using the built-in repository GITHUB_TOKEN.
Guarding Code Intersections with --no-commit --no-ff
The action safely pulls updates from the core upstream NextBlock tracking branch using explicit restrictions:

git merge upstream/main --no-commit --no-ff

If histories are clean: The modifications merge smoothly and deploy to production.

If lines overlap: Git halts immediately. Because the process fails right before finalizing the commit, Vercel never launches a broken build pipeline.

Webhook Failures Injected Natively to the CMS Layer By leveraging a if: failure() pipeline condition block, the workflow intercepts the terminal conflict. It fires a direct curl transaction utilizing the project's existing database role credentials to update a persistent system_alerts table.

The next time an admin accesses the dashboard, a React Server Component fetches the row and injects a clean, amber layout banner directing the operator directly to their GitHub interface to resolve line mismatches.

Opt-In Gated Schema Migrations Code updates often include structural database changes. We integrated an automated migration evaluation directly into the production compilation hook. The engine reads pending incremental DDL files, wraps them in secure PostgreSQL transactions, and runs them safely against production while cleanly skipping local development hot-reloads and preview environments.

What strategies do you use to manage updates for distributed open-source codebases? Let's talk architecture below!

How We Engineered the First Free, Zero-Config 1-Click CMS Deployment with Next.js 16 and Supabase

NextBlock™ CMS — Fri, 26 Jun 2026 18:46:47 +0000

If you’ve spent any time setting up full-stack frameworks or content management systems over the last few years, you know the onboarding tax. You are given a beautiful repository layout, but you are left to handle the database layer, image bucket permissions, and API orchestration strings yourself.

When we built NextBlock CMS—an open-core (AGPLv3) alternative to headless bloat built on Next.js 16 Server Components and strict PostgreSQL JSONB schemas—we vowed to fix the installation bottleneck.

Today, we are announcing that our recent code commits have officially closed that gap. NextBlock now features a completely free, automated 1-Click Deploy on Vercel that builds your database and object storage natively through Supabase with zero manual environment token configurations required from the user.

Solving the 4-Tier Deployment Spectrum
Every engineering team has a different deployment philosophy. To ensure flexibility without introducing architectural clutter into our Nx Monorepo, we spent this week locking down 4 primary initialization vectors:

The Frictionless Track (Vercel + Supabase Integration): Click a single button. Vercel sets up your edge endpoints and server components while the integrated Supabase webhook provisions your secure tables, auth middleware, and public assets bucket automatically on their free tier.

The Scaffolder Track (npm create nextblock): A streamlined command-line interface that allows developers to interactive-select settings, spin up a local directory layout, and begin instantly via npm run dev.

The Bare-Metal Monorepo Track (Git Clone): Designed for developers who want full control over our architectural engine core, custom Tiptap slash commands, and internal rendering pipelines.

The Isolated Track (npm run docker:setup): A single multi-stage Docker environment that coordinates localized PostgreSQL instances, automatically processes database migrations hidden inside our libraries, and stands up the Next.js standalone container.

The Road to Major Release v1.0.0
We aren't standing still. Next week, our focus shifts entirely to rigorous continuous integration and "breaker testing." We are systematically validating every edge-cache invalidation matrix, layout component tree depth, and database routing rule across these 4 structures.

This brings us to our absolute biggest milestone yet: The official v1.0.0 Major Release of NextBlock CMS is locked in to drop before the end of this summer!

Check out our source code, star the repository, and try the 1-click installer here:
🔗 GitHub Repository: github.com/nextblock-cms/nextblock
🔗 Live Sandbox: cms.nextblock.dev

Implementing Vercel Visual Editing on a Non-Headless Next.js 16 CMS

NextBlock™ CMS — Thu, 28 May 2026 14:41:14 +0000

Visual editing setups usually push you toward a few select headless vendors. But because Nextblock CMS is a full-stack system built natively with Next.js 16 Server Components , we wanted to prove that you can have real-time visual editing without sacrificing architecture or performance.

The Mechanism: Strict JSONB & HTML Tracking
Vercel’s visual editing overlay is actually completely CMS-agnostic. It relies on specific data attributes embedded directly into your rendered DOM nodes to tell the Vercel Toolbar exactly where that content lives inside your administrative backend.

Because Nextblock stores all document structures as strict Tiptap JSONB payloads , we updated our recursive React block rendering component. Now, when draft or preview mode is active, the system injects a dynamic data-vercel-edit-info attribute into the wrapper element of every block. This attribute feeds the exact targeting URL back to the Vercel overlay.

const renderedBlocks = await Promise.all( blocks.map(async (block, blockIndex) => ({ id: block.id, node: await renderBlock({ block, blockIndex, languageId, visualEditing, // Build top-level metadata block attributes visualEditAttributes: buildVisualEditAttributes(visualEditing, { kind: "top-level", blockId: block.id, blockIndex, blockType: block.block_type, }), }), })) );

Zero Bundle Bloat
By conditionally rendering the @vercel/visual-editing package layout component only during draft sessions, production users never download a single extra byte of editing overhead. Your 100/100 Lighthouse score remains completely untouched.

Read the updated /docs to see how to activate Live Draft Mode on your local sandbox environment today!

Why Headless i18n is a Nightmare (And How to Fix It with Integrated Schema Mapping)

NextBlock™ CMS — Tue, 19 May 2026 15:33:28 +0000

Why Headless i18n is a Nightmare (And How to Fix It with Integrated Schema Mapping)
If you have ever been tasked with implementing multi-language support (i18n) across a decoupled, headless CMS and a modern frontend like Next.js, you probably still have the scars to prove it.

On paper, headless i18n sounds straightforward: toggle a button in an admin panel, pull localized text over a REST or GraphQL API, and render it.

In reality? It is an architectural mess of duplicated routing configurations, massive bundle sizes, network waterfalls, and synchronization hell across mismatched systems.

For Day 16 of building NextBlock CMS in public, let's break down exactly why decoupled headless internationalization is historically painful, and explore how an integrated, single-monorepo schema mapping approach solves it cleanly.

The Headless i18n Tax: Why Decoupled Systems Fail
When you decouple your content repository from your delivery framework, internationalization forces you to pay what we call the "Headless i18n Tax" across three core development bottlenecks:

The Async Fetch and Network Waterfall In a classic headless setup, fetching localized data usually looks like this:

The frontend middleware or router detects the locale route (e.g., /fr/blog/post-1).

The frontend triggers an asynchronous fetch request across the internet to the third-party CMS API.

The CMS parses its database, maps the locale ID, and returns a localized JSON payload.

The frontend unpacks the payload, checks for hydration mismatches, and finally paints the page.

Every single language switch incurs a round-trip latency penalty. To circumvent this, developers often install massive, bloated third-party client libraries or store massive static localization dictionaries (en.json, fr.json, de.json) directly inside the frontend repository. You end up maintaining localizations in two separate places.

Schema Drift and Manual Synchronization
When your schemas are split across two separate systems, maintaining content relationships is fragile. If a content block contains an embedded product component or a reference to another post, you must map that relationship distinctly for every single language node over the API. If your frontend components update their parameters, your CMS content schemas must be updated manually via a separate dashboard to match.
Client-Side Bundle Bloat
Many third-party i18n frameworks tax the browser bundle aggressively. They introduce runtime provider wrappers, heavy client-side state parsers, and hydration scripts just to switch a sentence from English to Spanish. In an era dominated by React Server Components (RSC), sending 40KB+ of JavaScript to the client purely for static text translation feels ancient.

The NextBlock Approach: Native, Integrated Schema Mapping
When we architected NextBlock, we discarded the assumption that the CMS backend and frontend delivery layer must live in isolation. Because NextBlock is a unified full-stack alternative built directly within a Next.js monorepo alongside PostgreSQL (via Supabase), we handle internationalization right at the source layer.

Instead of treating locales as detached objects fetched over a third-party API grid, NextBlock utilizes an integrated JSONB schema mapping system that pairs natively with Next.js edge routing.

The Under-the-Hood Data Structure
Instead of making separate API requests or maintaining flat nested text files, localized content blocks reside cleanly inside structured PostgreSQL jsonb columns.

Take a look at how a localized text layout is stored within NextBlock's database schema:

JSON
{
"block_id": "block_9081723",
"type": "hero_section",
"locales": {
"en": {
"title": "Build the future of the web",
"subtitle": "A high-performance CMS for Next.js"
},
"fr": {
"title": "Bâtissez l'avenir du web",
"subtitle": "Un CMS haute performance pour Next.js"
},
"de": {
"title": "Bauen Sie die Zukunft des Webs",
"subtitle": "Ein Hochleistungs-CMS für Next.js"
}
},
"components": [
{
"id": "cta_button_1",
"props": { "link": "/get-started" }
}
]
}
Why This Architecture Wins:
Zero-Lag Request Routing: Because the content structure is unified, the requested language chunk is isolated right during the core database query layer. There are no secondary network requests to a detached headless server.

Pure React Server Components (RSC): The resolved locale payload is processed completely on the server. Your client browser downloads exactly zero bytes of translation runtime scripts or unused dictionaries.

No Synchronization Mismatches: Content blocks and their parent application logic always share the exact same structural boundary. If a layout changes, the relational nodes inside the JSONB structure apply across all language keys instantly.

Edge Negotiation with Next.js 16
To bridge the database schema seamlessly to the user, NextBlock handles language routing at the absolute nearest boundary line: the Vercel Edge runtime via custom middleware handling (proxy.ts).

When a request arrives, the edge middleware intercepts it, evaluates cookie states or the browser's accept-language header, adjusts the routing parameters, and redirects the request cleanly down to the Server Component tree.

TypeScript
// proxy.ts (Next.js 16 Native Edge Route Resolution)
import { NextRequest, NextResponse } from 'next/server'

const SUPPORTED_LOCALES = ['en', 'fr', 'de']

export function proxy(req: NextRequest) {
const { pathname } = req.nextUrl

// 1. Skip if the path already includes a supported locale
const hasLocale = SUPPORTED_LOCALES.some(
(loc) => pathname.startsWith(/${loc}/) || pathname === /${loc}
)
if (hasLocale) return

// 2. Negotiate locale via incoming request headers
const acceptLang = req.headers.get('accept-language') || 'en'
const matchedLocale = SUPPORTED_LOCALES.find((l) => acceptLang.startsWith(l)) || 'en'

// 3. Rewrite internal pathname transparently to feed down into RSC
req.nextUrl.pathname = /${matchedLocale}${pathname}
return NextResponse.redirect(req.nextUrl)
}

export const config = {
matcher: ['/((?!_next|api|assets).*)']
}
By resolving the user's intent at the Edge, the database query receives the correct locale context instantly. The app renders exactly what is needed without layout shifts, flash of untranslated content, or client-side overhead.

Simpler DevX, Smarter Content
Internationalization shouldn't feel like a patch that you bolt onto an application while crossing your fingers. By bringing your database schemas, server environments, and layout renderers under a unified monorepo framework, i18n shifts from an architectural headache to a core performance advantage.

NextBlock is currently in open beta throughout the month of May, and our public sandbox has all premium packages completely unlocked for evaluation.

If you are tired of building convoluted network chains for simple localized setups, check us out, test the sandbox, and inspect our full database migration layers.

🛠️ GitHub: nextblock-cms/nextblock

⚡️ Sandbox Terminal: cms.nextblock.dev

What is your biggest pain point when managing translation pipelines in production? Let's discuss in the comments below! 👇

Why We Chose JSONB for AI: How NextBlock CMS Bypassed the "HTML Wall" for Next.js 16

NextBlock™ CMS — Fri, 01 May 2026 16:27:59 +0000

If you’ve ever tried to pipe Generative AI directly into a production-grade CMS, you’ve likely hit the "HTML Wall."

Traditional rich-text editors treat documents as unstructured strings. When you ask an LLM to generate a blog post, it usually hands back a blob of HTML. In a modern Next.js 16 environment, that blob is a performance ticking time bomb. You have to sanitize it, parse it, and hope it doesn't break your React Server Components (RSC) or trigger a massive re-render that tanks your Core Web Vitals.

When we built NextBlock Cortex, we made a fundamental engineering decision: AI never touches raw HTML. We store everything as strict, node-based JSONB.

Here is why that decision is the backbone of our performance.

The Problem: The "Sanitization Tax"
The "Old Way" of handling AI content looks like this:

AI generates a string of HTML.

Server receives the string and runs it through a heavy sanitizer like DOMPurify to prevent XSS.

Database stores the string.

Client fetches the string and has to parse it again to render it within a React tree.

Every step in this process adds latency. Worse, if the AI generates an unsupported tag or a broken

, your editor engine (like Tiptap or ProseMirror) will aggressively strip it out, leading to data loss and a disjointed user experience.

The NextBlock Solution: The Zero-Validation Pipeline
In NextBlock, we treat AI as a structured data constructor, not a writer. We use constrained decoding to force the LLM to output content that follows a strict Zod-backed JSON schema.

By doing this, we create what we call the Zero-Validation Pipeline:

Direct-to-DB: Because the AI's output is algorithmically guaranteed to be valid JSON that matches our database schema, we skip the parsing and cleaning phase entirely.

Atomic Transactions: The JSONB payload is inserted directly into the PostgreSQL column. If a token doesn't fit the schema, the inference fails before it ever touches our disk.

The Code: Mapping the Schema
By defining our content as a tree of nodes rather than a string, we ensure 1:1 compatibility between the AI, the DB, and the Editor.

TypeScript
// A simplified look at our content schema
const NextBlockNodeSchema = z.object({
type: z.enum(['heading', 'paragraph', 'image', 'codeBlock']),
attrs: z.record(z.any()).optional(),
content: z.array(z.lazy(() => NextBlockNodeSchema)).optional(),
text: z.string().optional(),
});

type ContentBlock = z.infer;
Why Next.js 16 Loves JSONB
The move to JSONB wasn't just about data integrity; it was a pure performance play for the Next.js 16 ecosystem:

Native RSC Rendering: Since the content is already a JSON object, we map it directly to React components. No dangerouslySetInnerHTML, no hydration mismatches, and no intermediate parsing overhead.

Turbopack & use cache: Standardized JSON allows for highly predictable caching. Using the new Next.js 16 use cache directive, we can cache AI-generated blocks at the edge with surgical precision.

Perfect Lighthouse Scores: By eliminating the "sanitization tax" and parsing lag, NextBlock maintains its 100/100 performance guarantee, even on pages heavily populated by AI-generated modules.

Conclusion: The Schema is the Product
In the era of AI-native applications, "the schema is the product." By moving away from legacy HTML and embracing strict JSONB, we’ve ensured that NextBlock isn't just faster—it’s smarter. Our data is readable by humans, renderable by React, and queryable by future AI agents without the mess of regex or tag-stripping.

NextBlock is currently in early access. If you're tired of "Frankenstein" WordPress architectures and want a CMS built for the 2026 tech stack, check us out on GitHub.

Finally, a Modern CMS for Developers: Introducing NextBlock (Open Source)

NextBlock™ CMS — Mon, 26 Jan 2026 20:51:07 +0000

How we are breaking the cycle of bloated legacy platforms and complex headless configs with Next.js 16 and Supabase.

Every web developer knows the pain of choosing a Content Management System (CMS). It often feels like you are stuck between a rock and a hard place.

On one side, you have the “old guard” (like WordPress). It’s familiar, sure. But it is often bloated, slow, and — thanks to a reliance on endless plugins — a potential security minefield. On the other side, you have modern headless systems. They offer raw speed, but they can be a headache to set up, a nightmare for content editors to use, and often bury you in configuration files.

We decided to break that cycle.

Enter NextBlock, an open-source, developer-first CMS built to be the refreshing alternative we’ve been waiting for. In this article, I’m going to break down exactly what we’ve built so far, our tech stack, and our vision for a sustainable open-source ecosystem.

The Tech Stack

At its core, NextBlock is built on a modern foundation designed for the future of the web:

• Frontend: Next.js 16 for blazing-fast performance and Server Components.

• Backend: Supabase for handling data, auth, and storage.

• Styling: Tailwind CSS for a lean, utility-first design system.

But the tech is just the vehicle. The mission of NextBlock boils down to three core pillars: Speed, Experience, and Extensibility.

Pillar 1: Built for Speed

When we say “built for speed,” we aren’t talking about vague marketing promises. We are talking about concrete engineering wins that are baked into the core platform.

Edge Caching & ISR: We’ve set up caching at the edge, utilizing Next.js Incremental Static Regeneration (ISR). This ensures your site feels instantaneous regardless of where your users are located.
Critical Code Loading: We are obsessive about shipping only the code that is absolutely necessary. This includes using Tailwind CSS to purge unused styles, making the final production build incredibly lean.
Next-Gen Image Optimization: Images are usually the #1 culprit for slow websites. NextBlock solves this by baking in the Next.js component, enabling modern formats like AVIF (which are significantly smaller than JPEGs), and using blur-up placeholders so pages feel snappy even while assets load.

Pillar 2: A Superior Experience (For Everyone)

Speed matters, but what is the point of a fast site if it is a pain to manage? We focused heavily on the experience for both the Content Creator and the Developer.

For the Content Creator: We wanted an editing experience that feels modern — not like a form from 2005.

• Notion-Style Editor: We upgraded the block editor (powered by Tiptap) to be intuitive and drag-and-drop friendly.

• Organized Media: No more chaotic file dumps. The media library supports folders and tagging.

• Revision History: We added one-click revision history, a game-changer for content teams who need safety when editing live pages.

For the Developer: We moved the project structure into an Nx Monorepo. This makes it significantly easier to manage dependencies and scale the codebase as you add new features. We also built a CLI tool (create-nextblock) that spins up a new project in seconds, and a documented Block SDK that allows you to build custom components—unlocking the real power of the platform.

What’s Next: Phase 3 and the “Open Core” Model

We have built a fast, user-friendly foundation. Now, we are moving into Phase 3, where the vision expands from “just a tool” to a full ecosystem.

The focus right now is the development of a Premium E-commerce Module. This will be a full-blown commerce solution built to plug directly into NextBlock.

“Wait, premium? I thought this was Open Source?” This is a critical part of our vision for sustainability. We are adopting an Open Core model:

The Core CMS: Always free, always open-source (AGPL license). This is the foundation.
Premium Modules: High-value, complex features (like E-commerce or Enterprise SSO) will be offered as paid add-ons.
The Marketplace: This fuels a future community marketplace where developers can share and sell their own blocks and themes.

Join the Ecosystem

As we say on our site: “More than a CMS, an ecosystem”. The goal isn’t just to ship code; it’s to build a platform where we can create amazing web experiences together.

NextBlock is being built in the open. If the idea of a faster, better, developer-first CMS sounds exciting to you, we want you involved.

• Star the Repo: [https://github.com/nextblock-cms/nextblock]

• Join the Community: [https://github.com/nextblock-cms/nextblock/discussions]

The question isn’t just what’s next for the web — it’s whether you are ready to help build it.

Architecting Open-Core: How We Use Nx to Split Free vs. Premium Code

NextBlock™ CMS — Mon, 19 Jan 2026 14:19:00 +0000

The "WordPress Killer" needs a business model. When building NextBlock CMS, I knew I wanted the core to be free and open-source forever. But I also plan to offer premium capabilities—starting with our upcoming E-commerce library—to sustain the project. This presents a technical challenge: How do you manage open-source code and closed-source premium modules in the same ecosystem?

The Nx Solution This is why we spent Phase 2 migrating to an Nx Monorepo. It allows us to keep distinct boundaries between our core libraries and our future premium libraries.

The "Empty Package" Strategy We are taking a unique approach to distribution.

NPM Placeholders: We will publish "empty" or "shell" packages to the public NPM registry for our premium libraries. This reserves the namespace and prevents confusion.

Private Registry via GitHub: The actual source code for the Premium E-commerce library will live in a private GitHub repository.

The Handshake: Once a user purchases a license, they are invited to the private repo. Their package.json will point to the private instance, seamlessly pulling the premium code into their monorepo workflow.

Why this matters This setup ensures that we can maintain a single, cohesive developer experience. You don't have to hack together two different CMS versions. You simply "unlock" the premium libs when you're ready.

Phase 3 is all about executing this vision. The E-commerce library is coming, and it’s going to be fast.

NextBlock CMS: The Great Migration & The Road to E-commerce (Phase 3)

NextBlock™ CMS — Wed, 14 Jan 2026 20:16:04 +0000

I’m Back. It’s been quiet on the social front since New Year's, but the code commits have been loud. I am thrilled to announce that we have officially completed the groundwork for NextBlock CMS. Phase 1 (Performance) and Phase 2 (Architecture) are done.

We Moved! First things first: update your remotes. The project has been transferred to its permanent home: https://github.com/nextblock-cms/nextblock. Unfortunately, we lost our old discussions in the move, so I’ve created 6 new discussion types (Announcements, Ideas, Q&A, etc.). I invite you all to jump back in and repopulate the board!

Why the Silence? The Monorepo Split. We didn't just move files; we completely restructured the application using Nx. We successfully split the codebase into apps (the core CMS) and libs (reusable packages). This was a massive undertaking, but it was necessary for what comes next.

Phase 3: The E-commerce Library We are now entering Phase 3. Our goal is ambitious: to create the best-performing E-commerce library in the world. We are targeting big corporations and solving the performance bottlenecks that have plagued standard CMS e-commerce plugins for years.

The foundation is set. The repo is ready. Let’s build.

NextBlock 2026: The Year of the Ecosystem (Phase 3 Roadmap)

NextBlock™ CMS — Thu, 01 Jan 2026 14:00:00 +0000

Moving from "Building a CMS" to "Building a Community".

Happy New Year! 🎆

2025 was the year of the Core. We built a Type-Safe, Next.js 15 powered, Supabase-backed CMS that smokes WordPress in performance benchmarks (100/100 Lighthouse).

2026 is the year of the Ecosystem.

We are entering Phase 3 of our roadmap. Here is what we are building this year:

🛍️ The E-commerce Module: A lightweight, headless commerce engine. No bloat, just products and checkout.

🧩 The Marketplace: A space for developers to share (and eventually sell) their custom Blocks and Themes.

🤝 Community: We are moving development discussions to the open.

This is an open-source project. No venture capital, no walled gardens. Just developers building the tools we actually want to use.

If you're tired of fighting with legacy PHP platforms, come help us build the future.

Star the repo to follow the journey: https://github.com/Webman-Dev/nextblock-monorepo

Documentation is a Feature: Why I’m Obsessing Over "Time-to-Hello-World"

NextBlock™ CMS — Sun, 28 Dec 2025 14:00:00 +0000

Great code with bad docs is just legacy code waiting to happen.

We just finished the "Holiday Sprint" for NextBlock, hitting 100% Lighthouse scores and shipping a robust Plugin SDK. But the code is only half the battle.

I’m spending the days between Christmas and New Year's doing the unglamorous work: Writing Docs. ✍️

My Goal for Jan 1st: A developer should be able to run npx create-nextblock-app and have a running, deployed CMS in under 5 minutes.

If you have to read a 10-page manual to start a server, I’ve failed.

I’m looking for beta testers to try the installation flow next week. If it takes you longer than 5 minutes, I want to hear about it.

Who is up for the challenge?

The read me in the repo: https://github.com/Webman-Dev/nextblock-monorepo

Building Git-like Version Control for a Headless CMS (Next.js + Supabase)

NextBlock™ CMS — Tue, 23 Dec 2025 14:44:50 +0000

How we implemented “Time Travel” for content editors without exploding our database.

I just merged one of the most requested features for NextBlock: Content Revision History.

We all know the pain of a client deleting a paragraph and then asking, “Can we get that back?” 😅

The Challenge: Most CMS solutions either don’t track history or bloat the database by duplicating entire rows for every save. We wanted something faster and smarter.

The Stack:

Next.js 15: For the reactive admin UI.
Supabase (PostgreSQL): Storing JSONB deltas.
Zod: Validating the schema integrity of past versions (so restoring an old version doesn’t break the new UI).
How it works: We are diffing the JSON content blocks and storing snapshots only when significant changes are detected. This keeps our storage footprint low while giving editors the confidence to “Save” without fear.

It’s live in the repo now. Go break it and let me know what you think! 👇
https://github.com/Webman-Dev/nextblock-monorepo

Sneak peak here: https://x.com/NextBlockCMS/status/2003474634340290704?s=20