I have built an ultimate blogging workspace and open sourced it.

I always thought that using our own custom solutions over the ready ones is not necessary but genuine idea because we face with an unknown in other words real challenge. I used to write my articles using Obsidian and manually update the DB so far.

It turns out actively using this app to write and manage my technical articles. Just like this one 😅

Check out the Github repo for the source code.

The open-source Ultimate Blog Editor App brings together the Markdown editing experience of Obsidian and the publishing flexibility of Substack in a single workspace.

The stack doesn't cost a penny. Supabase and Netlify free plans are suitable. It won't let you down halfway through even at scale.

That said, it comes with amazing features listed down below:

• Rich-Text Editing
• Blazing Fast Editing
• Markdown Editing Mode
• MDX Content Viewer
• Dynamic Error Display for Compiled MDX Source
• Media Library
• Image Optimization (converting primary formats to .webp)
• Extensive Autocomplete In English
• Custom Content Components (including charts from recharts)
• Command Center
• 50+ Predefined Eye Soothing Backgrounds
• Draft & Post Management
• Document Serialization and Compression
• URL-Based Document State
• Comprehensive Keyboard Shortcuts With Full Accessibility Support
• Dialogs, Sheets, Shared Controls
• Feedback and Cloud Syncing
• Backend Integration

This project is primarily tailored for my personal use, but it is also intended to serve as a reference for others interested in the editor architecture and development of editor features. It's so easy to change the serialized custom components and allowing you to curate them as you wish.

It serve as a starting point for building custom editor applications with its highly modular architecture and extensibility. Just like a puzzle box, it can be customized to fit your needs.

Of course, those who rely on others' solutions rather than coming up with their own in 2026 are not fools or timid. What I mean is that whatever Substack or Obsidian provides is maybe convenient enough for you.

Therefore you might not end up with going further, it's totally up to you.

As far as I am concerned, these techs don't meet my expectations on their own, but would meet them if they were combined, if you're the one looking from the same window like me then you've come to the right place.

The app follows a modular architecture that separates editing, document previews, and content management into dedicated feature areas. Shared UI components, an extensible Lexical editor, and centralized server actions keep the code organized and make it easier to maintain and expand. Respected to DRY principles heavily.

• Admin entry point(mainland): app/(admin)/admin/page.tsx provides the admin route, with access-control logic organized in proxy.ts and lib/auth.ts.
• Feature modules: features/ separates the editor, document viewer, and management tools for drafts, posts, and the media library.
• Extensible editor: components/editor/ organizes Lexical nodes, plugins, extensions, toolbars, and Markdown transformers. Charts and Contents have dedicated modules for editing, rendering, and conversion.
• MDX rendering: components/mdx/ defines content components and processing plugins, while lib/mdx/ handles serialization and related error handling.
• Server and DB layer: app/actions/ groups content operations, supported by the server database client in lib/db/ and generated database types in types/.
• State and validation: store/document.store.ts holds document state, providers/tools-provider.tsx supplies shared tool context, and schema/ defines draft validation.
• Shared interface: components/ui/, reusable modals, and hooks/ provide consistent controls, dialogs, keyboard shortcuts, and URL parameter handling.

The working tree is pretty straightforward and scalable with it's modular design:

1src/
2├── app/
3│   ├── (admin)/admin/    # Entry point
4│   └── actions/         # Server-side content operations
5├── features/
6│   ├── editor/          # Editor workspace
7│   ├── document-viewer/ # Content preview
8│   └── tools/           # Drafts, posts, and media management
9├── components/
10│   ├── editor/          # Lexical nodes, plugins, and extensions
11│   ├── mdx/             # MDX rendering components
12│   └── ui/              # Shared interface components
13├── lib/                 # Auth, database, and serialization
14├── store/               # Document state
15├── providers/           # Shared tool context
16├── hooks/               # Reusable React hooks
17├── hoc/                 # Content and metadata wrappers
18├── schema/              # Validation schemas
19├── types/               # Application and database types
20├── constants/           # Tool and editor configuration
21├── utils/               # Supporting utilities
22└── proxy.ts             # Request interception  

You will need:

• Node.js >= 22
• npm

Clone the repository:

1git clone https://github.com/Masculinn/blog-editor.git
2cd blog-editor

Install dependencies:

1npm install

⚠️ CAUTION: Before continuing further you must configure the DB layer. Do not attempt running the dev server unless all the database environments and tables are configured properly. See instructions below to be able to start the dev server.

Visit Supabase auth page to signup or if you have already an account simply login. Create a new organization and choose your own namespace. After that, create a table called blog_posts and paste the given PostgreSQL snippet below into the SQL Editor section placed in the sidebar of your dashboard.

This will create our very first table for our articles.

1create table public.blog_posts (
2  id serial not null,
3  title text not null default 'title'::text,
4  content text not null,
5  tags text[] not null,
6  published_at timestamp with time zone null default now(),
7  description text not null default 'I AM JOHN DOE BUT CANT PROVE IT'::text,
8  banner_image text not null default 'MY_DEFAULT_IMAGE_URL'::text,
9  level numeric not null default '1'::numeric,
10  constraint blog_posts_pkey primary key (id),
11  constraint blog_posts_level_check check ((level > (0)::numeric))
12) TABLESPACE pg_default;

After configuring the DB and ensuring everything is stable, you can curate the predefined tables however you want.

Next, we need the secondary table for our article candidates that isn't actually ready to be considered under the category of posts. I call it draft.

Paste the given snippet below to create draft table into the SQL Editor as well.

1create table public.drafts (
2  id serial not null,
3  title text not null default 'title'::text,
4  content text null default 'The quick brown fox jumps over the lazy dog.'::text,
5  tags text[] null,
6  published_at timestamp with time zone null default now(),
7  description text null,
8  banner_image text null,
9  level numeric not null default '1'::numeric,
10  constraint drafts_pkey primary key (id),
11  constraint drafts_level_check check ((level > (0)::numeric))
12) TABLESPACE pg_default;

These tables are almost identical. The only difference is the partially defined columns, which are in response to the separation of concerns principle.

Finally, we're one step away to be done on DB configuration which is creating a bucket called banner. To do that, move into the storage page via dashboard > sidebar and create a new bucket called banner.

I'm currently using my bucket publicly because I treat my bucket as an external CDN point for my media elements in my site — idc how unsafe it is so if you think that things in it must remain private then you can leave the toggle state as-is like the one showed above.

Create a brand new env file called .env at the root of your project and get the corresponding values of your env keys from project settings of your Supabase organization.

1SUPABASE_URL=YOUR_PROJECT_URI
2SUPABASE_SERVICE_ROLE_KEY=YOUR_SERVICE_ROLE_KEY
3BUCKET_NAME=banner
4
5APP_ENCRYPT_TOKEN=YOUR_APP_BASE64_PSW
6
7MY_IP=YOUR_IP
8MY_USER_AGENT=TRIMMED_VERSION_OF_YOUR_USER_DEVICE_INFO
9
10
11ADMIN_KEY=YOUR_BASE64_ADMIN_KEY   	

At first glance to the project, you might find yourself skeptical for all those weird things. As I mentioned earlier, current architecture that are in the repo is considered to personal use. So for demo purposes, everything under the root page is removable because I've created all those extensions to demonstrate and test for you folks.

That said, some of the env keys other than what's belong to the Supabase is used to authenticate the user with a particular rate limiter based on digital footprint of the user as I haven't implemented a proper auth for the user cause I found myself in boredom while doing so and YES — I reinvented the wheel 🫠

The values broken down below are presented for the demo page so after configuration you can remove those keys and pretty much every piece of the code where it's being used BUT FOR LOCAL DEVELOPMENT!

• APP_ENCRYPT_TOKEN
• MY_IP
• MY_USER_AGENT
• ADMIN_KEY

If you do like to self-host via Netlify or Vercel on free plan, leave everything as-is.

The app uses the typegen for DB types for in particular for React actions. Everything in the package.json file is configured for you to invoke codegen but before doing so, you must login to your Supabase account via CLI

Run the CLI command to login your account in your IDE.

1npx supabase login 

This is going to open up a new window inside of your browser to SSO. Follow the instructions given in the CLI to login then run the following command to fetch the DB types

1npm run db:types

Start the development server:

1npm run dev

The current development script starts Next.js on port 36805:

1http://localhost:36805/admin

That's pretty much everything so far to run the app on locally, it takes max 5 minutes from scratch, I think it's fair.

The app root http://localhost:36805/ might be a junk for you so in order to keep things fresh for your personal use not mine, you can always remove imported components/files.

I've added a specific npm command to wipe the staffs out.

Go the the file under /src/app/page.tsx and replace it's content with plain function export:

1export default function Page() {
2	return <div>Everything clean</div>
3}

As well as src/proxy.ts with:

1import { NextResponse, type NextRequest } from "next/server";
2
3export async function proxy(_: NextRequest): Promise<NextResponse> {
4  return NextResponse.next();
5}
6
7export const config = {
8  matcher: [
9    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp|ico)$).*)",
10  ],
11};

Afterwards run the command:

1npm run check 

This will break down unused functions that you can easily delete later on depending on your needing.

It's worth to mention that the Unix-based users like mac or linux OS, a bit differs in particular scenarios such as key bindings. If you're the one, you may want to configure the app shortcuts in a way that the modifier key meta handles the shortcut over Control because initially it's defined to Control

Simply find the components in your IDE search with a match for the hook imported as:

1import { useKeyboardShortcut } from "@/hooks/use-keyboard-shortcut";

And configure like:

1  useKeyboardShortcut(
2    ["Meta", "/"],
3    () => {
4     /* INTERNAL CALLBACK */
5    },
6  ); 

Consider Ctrl as Meta please don't make me write this.

Press Ctrl + K to toggle the Command Center, even while editing. Search for a tool, navigate with ↑ / ↓, and press Enter to open its modal. Selecting a tool automatically closes the Command Center.

If you'd like to publish the posts powered by SSG render power in Next.js Pages router that maximizes your SEO by god knows how many times, you can take a look at my blog app's Github Repo to inspire by.

Contributions are welcome! Open an issue to report a bug, suggest a feature, or discuss a significant change before starting.

1. Fork the repository and create a branch for your changes.
2. Install dependencies with npm install.
3. Start the development server with npm run dev.
4. Make your changes, keeping them focused and consistent with the existing architecture.
5. Run npm run check and npm run build before submitting.
6. Open a pull request describing the changes, any related issues, and how you tested
7. them. Include screenshots for UI updates.

Keep credentials and environment files out of your commits.

Huge thanks to this repo and its hard-working contributors for allowing me to curate their Shadcn Editor! Lovely set of backgrounds are also scraped from patterns craft definitely worth to add in your checklist.