# VanBlog: a self-hosted blog with the admin dashboard built in

> VanBlog bundles a public blog, an admin dashboard, analytics, image hosting and comments into one Docker deployment. It suits writers who want a single server and are willing to accept a Chinese-first interface.

**Mereithhh/vanblog** — A self-hosted blogging system with Markdown editing, a full admin dashboard, analytics, image hosting, comments, and automatic HTTPS.

- Repository: https://github.com/Mereithhh/vanblog
- Website: https://vanblog.mereith.com
- Stars: 3,584 · Forks: 503
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/mereithhh-vanblog

## What VanBlog actually replaces

A typical personal blog is assembled from parts: a static site generator, a separate CMS or a Git-based editor, a comment service, an image host, and an analytics script. VanBlog folds those into one application. The README describes it as a self-hosted personal blogging system with a complete admin dashboard, Markdown editing, built-in analytics, image hosting and comments. The audience is the individual writer or small team that would rather run one service than five, and that is willing to run MongoDB to get it.

The trade-off is visible in the same paragraph. The documentation and application interface are currently primarily in Chinese, and internationalization is on the roadmap. So the product is aimed first at Chinese-speaking self-hosters. If you are not one, you are adopting a tool whose reference material you will read through translation, and whose admin labels you will learn by position rather than by name. That is a real cost, not a footnote.

## How the pieces fit: Next.js frontend, NestJS API, MongoDB

The repository is a pnpm workspace, and the README names the three parts: a Next.js/React frontend, a NestJS backend using MongoDB, and a Umi/Ant Design admin dashboard. The packages are split accordingly, and the root package.json builds them by filter: @vanblog/server, @vanblog/theme-default and @vanblog/admin.

The interesting mechanism is on the public side. The README states the Next.js frontend uses static generation (SSG) and incremental static regeneration (ISR), so content changes do not require rebuilding every page. That is the design decision worth noting: publishing a post does not trigger a full site build, and pages stay CDN-friendly. Images are lazy-loaded, article URLs are customizable, and the README claims SEO and accessibility support.

The Dockerfile confirms the all-in-one image is assembled from three builder stages: ADMIN_BUILDER, SERVER_BUILDER and WEBSITE_BUILDER. The website stage pins sharp 0.32.6 with an official musl prebuild and installs vips as a compile fallback, because the file comments note that sharp 0.31 fails on Alpine with an invalid version error. That is a concrete constraint of the Alpine base image, not a preference.

## Installing VanBlog with the setup script

The README gives a one-line installer. It downloads the script, makes it executable and runs it:

```bash
curl -L https://vanblog.mereith.com/vanblog.sh -o vanblog.sh && chmod +x vanblog.sh && ./vanblog.sh
```

If the documentation site is unreachable, the README offers a GitHub raw mirror of the same script:

```bash
curl -L https://raw.githubusercontent.com/Mereithhh/vanblog/master/scripts/vanblog.sh -o vanblog.sh && chmod +x vanblog.sh && ./vanblog.sh
```

The README notes that you can run the script again later with `./vanblog.sh`, which is how the guided installer is re-entered. According to the README, the default Docker Compose setup runs VanBlog and MongoDB as separate services, so expect two containers rather than one.

For the first real use, the README points to a live demo at blog-demo.mereith.com where the admin username and password are both `demo`. Logging into that demo before you deploy is the cheapest way to see the dashboard, the ByteMD editor and the analytics views, since the README does not walk through post creation step by step. For other deployment options the README defers to the getting started guide, and reverse proxy configuration to a separate reference page.

## Analytics, images and comments are the bundled services

Three features account for most of the value over a plain static generator. First, built-in analytics: the README describes visitor statistics and dashboards, plus optional Google Analytics and Baidu Analytics. Second, image hosting: built-in storage plus external storage through PicGo, including object storage and GitHub, with compression and watermarking on upload. Third, comments through Waline, with email notifications and webhooks.

The image hosting detail matters for self-hosters because it removes the usual split between a Markdown file and a separate asset pipeline. The README also states that images can be uploaded from the editor, either local files or the clipboard, and that Markdown files can be imported. Editor-level features include Mermaid diagrams, mathematical formulas, custom highlight blocks, an emoji picker and a shortcut for the `more` marker.

Reader-side tools are listed too: tables of contents, code copying, categories, tags, search, password-protected articles and categories, friend links, donation links, custom navigation and RSS feeds. Treat that list as the feature surface, not as a claim about quality; the README does not document how search is indexed or how password protection is enforced.

## Where VanBlog is the wrong choice

The clearest limitation is stated by the project itself: a full theme system and a plugin system remain planned work, and the roadmap repeats that themes are a long-standing goal. The README is explicit that roadmap items are planned and are not a list of currently available features. Customization today means layout settings and custom CSS, HTML and JavaScript, not swapping a renderer.

The second limitation is the release cadence. The most recent release listed is v0.54.0 from 2023-06-27, and the repository's last push was on 2026-09-17. The README explains the gap: an automated AI maintenance workflow reproduces reported code issues, adds regression tests and opens pull requests, while the maintainer merges into master and creates release tags. It also warns that the live demo and documentation site stay on their latest tagged versions, so they may not reflect master. If you need a feature that only exists on master, you are running untagged code.

Third, the language barrier and the MongoDB dependency are both real. If you want a single static binary with no database, or an interface you can read without translation, VanBlog is the wrong tool regardless of its feature list.

## VanBlog against a static site generator plus a headless CMS

The obvious alternative approach is a static site generator such as Hugo or Astro paired with a separate headless CMS and a hosted comment service. The difference is where the state lives. In that stack, content is files in a repository and the build is the deployment; you get portability and you can rebuild the site with any tool. VanBlog stores content in MongoDB and serves it through a NestJS API with a Next.js frontend using SSG and ISR.

That inversion buys you the admin dashboard, the analytics, the image pipeline and the comment integration without wiring them together. It costs you the ability to treat your posts as plain files you can move. The README does mention import and export in the admin dashboard, and links a backup and migration page, so the exit path exists, but it is a migration procedure rather than a `git clone`.

A second alternative is a hosted blog platform. The difference there is operational: VanBlog runs on your server, with Caddy handling automatic on-demand HTTPS certificate issuance and renewal, and Docker images published for AMD64 and ARM64. You own the uptime.

## Maintenance, upgrades and the GPL-3.0 licence

Upgrades are tag-driven. The README states that product releases and deployments are triggered by `v*` tags and documentation deployments by `doc*` tags. The admin dashboard provides import/export, version and update notices, and access to login and Caddy logs. The README's first advice when something breaks is to check whether the problem is fixed in the latest published release.

The README links dedicated pages for upgrading and rolling back, and separately for admin errors or continuous loading after an update. It does not reproduce those steps inline, so an upgrade plan that depends on reading them at the moment of failure is a weak plan. The same applies to backups: there is a linked backup and migration page, and the README does not inline a backup command.

On licensing, the repository is GPL-3.0. That is a copyleft licence, which matters if you plan to modify VanBlog and distribute the result, including as a hosted service for others. This is not legal advice; if you intend to redistribute a modified version, read the licence text in the repository and take your own counsel.

Development is a pnpm workspace with Node 18 in the Dockerfile, pnpm 8.11.0 pinned through corepack, and a build split across the server, default theme and admin packages. The root scripts include `pnpm build`, `pnpm dev` and per-package variants such as `pnpm build:server` and `pnpm build:admin`.

## Conclusion

Adopt VanBlog if you want one Docker host to serve both the writing interface and the public site, and you are comfortable with a documentation set that is primarily in Chinese. Do not adopt it if you need a theme system today (the roadmap lists a custom theme and frontend renderer as planned, not available) or if you cannot run MongoDB alongside it. Before committing, check the latest published release rather than master, confirm the Caddy automatic HTTPS path works on your host, and read the backup and rollback pages linked from the README, because those are the two operations you will need when an upgrade goes wrong.

## FAQ

### How do I install VanBlog?

The README gives a setup script you download and run with curl and chmod, and notes that running ./vanblog.sh again later re-enters the guided installer. The default Docker Compose setup runs VanBlog and MongoDB as separate services. A GitHub raw mirror of the script is provided in case the documentation site is unavailable.

### Does VanBlog require MongoDB?

Yes. The README describes the backend as a NestJS application using MongoDB, and states that the default Docker Compose setup runs VanBlog and MongoDB as separate services. The repository also links a page about accessing the database externally.

### Is VanBlog available in English?

Not fully. The README states that the documentation and application interface are currently primarily in Chinese, and that internationalization is on the roadmap. The README itself has an English version alongside README.zh-CN.md.

### Does VanBlog support custom themes?

Not yet. The README lists a custom theme and frontend renderer system under the roadmap and states that roadmap items are planned and are not currently available features. Today, customization is limited to layout settings and custom CSS, HTML and JavaScript.

### Can I try VanBlog before deploying it?

Yes. The README links a live demo at blog-demo.mereith.com where the admin username and password are both demo. The README also notes that the demo and documentation site stay on the latest tagged versions, so they may not reflect changes on master.

## Sources

- [License: GPL-3.0](https://github.com/Mereithhh/vanblog/blob/master/LICENSE)
- [Mereithhh/vanblog on GitHub](https://github.com/Mereithhh/vanblog)
- [Project website](https://vanblog.mereith.com)
- [README](https://github.com/Mereithhh/vanblog/blob/master/README.md)
- [Releases](https://github.com/Mereithhh/vanblog/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mereithhh-vanblog