In a world where cloud services are everywhere, HexoPress takes a different path — local-first. Your data stays on your computer at all times, never passing through any third-party server. This isn’t a technical compromise; it’s a deliberate design decision.
Why Local-First
Hexo itself is a local tool. Its blog data — Markdown source files, configuration, themes — all lives on the local filesystem. As Hexo’s graphical companion, HexoPress naturally respects this premise.
Keeping data local means:
Complete data ownership. Your posts, drafts, and images are all on your own hard drive. No accounts, no subscriptions, no risk of “terms of service changes.” You can version with Git, back up with any tool, and open files with any editor.
Fully offline capable. No internet connection needed to write, edit, or manage your blog. The only feature requiring network access is the AI writing assistant (since it calls external APIs), and that’s entirely optional.
Zero-configuration startup. Point to a Hexo blog directory and start working. No account registration, no database setup, no backend services to launch.
Hexo as a Library, Not a CLI
A key technical decision behind the local-first approach is embedding Hexo directly as a Node.js library rather than calling it through the command line.
Many similar tools interact with Hexo by executing hexo commands via shell. This approach is straightforward but has clear limitations: each operation spawns a new Node.js process, requires parsing text output, and involves handling various edge cases.
HexoPress chose a deeper integration path. A Hexo instance runs directly within Electron’s main process, giving the app access to Hexo’s in-memory database, query API, and file parsers. This brings several benefits:
- Data is immediately available after startup — no repeated loading
- Query operations complete in memory with near-instant response times
- File operations go through Hexo’s parsers, ensuring format compatibility
- The full Hexo data model enables rich statistics and filtering features
The Filesystem Is the Database
HexoPress has no database of its own. All data comes from files in the Hexo blog directory:
- Post content comes from Markdown files in
source/_posts/andsource/_drafts/ - Category and tag information comes from each post’s Front Matter
- Media assets come from images and files in the
source/directory - Blog configuration comes from
_config.yml
This means any change you make in HexoPress is directly reflected on the filesystem. Open the same file in another editor and you’ll see the same content. No sync issues, no data format conversion, no lock-in.
Compatibility with Existing Workflows
The local-first design lets HexoPress integrate seamlessly into your existing workflow:
- Managing your blog with Git? HexoPress changes are just ordinary file modifications — commit directly
- Prefer writing long posts in VS Code? Switch anytime — HexoPress will detect file changes automatically
- Using CI/CD for deployment? HexoPress won’t interfere with your deployment pipeline
HexoPress doesn’t try to replace your toolchain — it becomes part of it. It focuses on doing visual management well and leaves other choices to you.
Privacy and Security
Local-first also means better privacy protection. Your blog content is never uploaded to any server (unless you actively use the AI feature with an external API configured). The app collects no usage data and requires no network permissions to run its core features.
For writers, this certainty matters — you know where your drafts are, and you know who can see them.