XHBlogs splits a Next.js blog into a local console and a Vercel deployment

Two folders, one console, one front end

XHBlogs is a personal blog system built with Next.js in a glassmorphism style, and it ships with a complete front end plus an independent local backend console. The console is the interesting half, because it is not an admin page hosted alongside the site. It runs on your own machine, and it supports immersive Markdown writing, draft management and convenient image host configuration. The repository layout reflects the split, with a my-blog-manager/ directory for the console, an XHBlogs/ directory for the front end, a scripts/ directory, and update.bat and update.py at the root as the updater. The environment requirements are ordinary for a Next.js project: Node.js with v18.x or newer recommended, npm as the package manager, Git for pulling the code, and Python 3.10 or newer, which the documentation says the system was tested on. A cloud storage or image host service is optional at this stage. The console folder carries a warning that it must not be renamed, because the path resolution breaks if you do, which is a small thing that tells you the console locates the front end by directory name rather than by configuration.

The updater exists so your posts survive a pull

The update flow is one of the more thoughtful parts of the setup, and the reason is stated plainly. Using the updater means you do not have to compare code by hand, you do not have to worry about a pull causing conflicts, and you do not have to fear that the articles and configuration files you wrote get overwritten. The mechanism is a pair of scripts. You download update.bat and update.py from the project root, move them into the outermost directory of your local blog project, next to the my-blog-manager and XHBlogs folders, and then run the batch file by double-clicking it, or run the Python file from a command prompt if the batch file closes immediately. That design tells you how the project expects to be used. It is a desktop workflow on Windows, with a batch file and a Python script, the latter run from a command prompt if the batch file closes immediately, and the guarantee that a pull will not clobber your writing is the reason the updater exists at all rather than a plain git pull.

Publishing to Vercel runs through Git, and the key needs write access

The deployment path is a two track Git workflow, and the documentation is unusually emphatic at each step. You configure git locally first, setting your user name and an email that is the one bound to your GitHub account. Then you initialise the repository in the front end folder and commit:

git init
git add .
git commit -m "first commit"

The console then needs the physical path of the front end directory, and the documentation insists you click the path test button to verify connectivity before saving the two track configuration. You create a private repository on GitHub to hold the blog source, paste its SSH address into the B line configuration with main as the source branch, and then use a button in the console to fetch a dedicated key. That key goes into the repository settings under Deploy keys, and here the documentation carries a serious warning: the Allow write access option must be ticked, because the console pushes source code itself. A deploy key with write access is a meaningful privilege to hand to a local tool, and it is the one step in this flow that deserves a second look from a security perspective. After that, the console initialises the two track environment, syncs the source only, and GitHub Actions or Vercel pick up the change. In Vercel you import the repository, choose Next.js as the framework preset, and deploy.

A staged queue before anything reaches the site

The console uses an operation staging area to protect your data, and the rule it teaches is worth internalising. Many settings must be actively pushed to the local copy to be saved, and the interface usually highlights when that is needed. The flow for a change such as editing your profile is a three step path. You stage the change to the operation queue with the stage button, you can then undo it, clearing everything in the queue, or apply it with the update to local button, and only then does it actually land in the local console environment. But updating locally is not publishing. For the change to appear on the front end blog you must also sync the blog, and only after that do you go to the console's sync deployment page, confirm the B line address, and sync the source only. The documentation compresses the rule into a golden rule, stage to the queue, update to local, sync the blog, and it applies to everything, articles, short posts and everything else. For a solo blogger this is a sensible guard against a half-applied change reaching the public site, and the cost is a three step habit to learn.

Image hosting, an AI assistant and comments on GitHub Issues

Three integrations round out the feature set. The console integrates image host uploads directly, with the guide recommending a specific service, and it also supports plain external image URLs, and other hosts with a standard API are welcome to try. Once you fill in the API token you can send a probe test to check the host is reachable in real time. The AI assistant is a built in cat character that talks to the Gemini model by default, and the documentation notes you can point it at another large language model by editing the source. You supply a Gemini API key, set the personality in the system prompt locally, and then also have to give the online deployment the ability to call it, which means adding a GEMINI_API_KEY environment variable in the Vercel project settings with the scope covering the online environment, and the assistant wakes up on the next deploy. Comments are based on GitHub Issues, in the style of Gitalk, so you create a public repository to hold visitor messages and configure your GitHub username and that repository name in the console, then set up OAuth so guests can log in to post. The public repository requirement is worth noting, since it means the comment data lives in a GitHub issue tracker rather than in your database.

What the project is, and where its edges are

The recent update notes, covering versions 0.3.1 to 0.3.2, give a good sense of the project's direction. The additions include a personal about feed with attention given to contribution levels and log display, a level and ranking system in the spirit of a creative workshop feature that can be turned off in the settings under the personal card settings, and a fix for a NetEase Cloud Music display bug that involved changing the API. There was also a pass fixing rich text editor bugs, where hyperlinks would not display and quotes would not display. The licence is a custom one that GitHub cannot classify, with the LICENSE file at the root as the authority, and the repository has no GitHub releases, so the last push on 2026-07-19 is the only version marker. The edges are obvious from the architecture. The publishing loop assumes a Windows machine running a local console that holds write credentials to your source repository, a private GitHub repository and a Vercel project. That is a workable and reasonably pleasant setup for one person, and it is a poor fit for a team that wants a hosted editor or for anyone who would rather push commits from a normal development environment. The two track design, the staged queue and the physical path configuration all point to the same conclusion, that this is a personal workstation tool for one blogger, not a platform for many.

Editorial conclusion

Adopt XHBlogs if you want a personal blog with an offline local console, Markdown writing, draft management and a glassmorphism front end, and you are comfortable running a Node project on Windows and deploying to Vercel. Do not adopt it if you want a hosted content management system with no local tooling, or a static site generator you can build anywhere. Verify first that the console and the front end are kept in the two expected folders, that the deploy key has write access as the setup requires, and that you are comfortable with the three step publish cycle, because nothing appears on the site until you run it.

Frequently asked questions

Official sources

1. heiehiehi/XinghuisamaBlogs on GitHub
2. Issues
3. README