Self-hosted service
wsydxiangwang/Mood avatar
wsydxiangwang/Mood

Mood: a self-hosted blog system on Nuxt, Node and MongoDB

Vue的Nuxt.js服务端渲染框架,NodeJS为后端的全栈项目,Docker一键部署,面向小白的完美博客系统

782 stars152 forksVueLicense varies

At a glance

What is it?
Mood is a Chinese full stack blog project with a Nuxt front end for readers, a Vue and Element UI administration panel, a Node API backed by MongoDB, and an nginx front for both, all wired together in a Docker Compose file. The author wrote it for people who want their own site and describes it as aimed at beginners.
Who is it for?
Mood suits someone who wants their own small blog with a reader site, an admin panel and Docker based deployment without assembling a stack themselves, since the three services, the nginx configuration and the upload volume are already arranged.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 154 days ago.
What is it written in?
Mainly Vue, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What the project is

The repository description calls Mood a Vue server side rendering framework based on Nuxt.js, a full stack project with a NodeJS backend, one click Docker deployment, aimed at beginners who want a complete blog system.

The README is warmer in tone than that, which is part of the project's character. It opens by welcoming the stranger who found a treasure, and explains that you can write articles, take notes, share moods and write a personal introduction here. The author says people usually call this kind of site a blog, but prefers to call it a mood town, and links to the live site.

The stack badges give the versions the project was built against: Nuxt 2.0.0, the Vue command line tooling at 4.3.1, Vuex at 3.4.0, Element UI at 2.13.0, Node at 12.16.1 and MongoDB at 4.2.4.

Those version numbers are the most important fact in the README for a technical reader, because they date the project precisely. Nuxt 2 and the Vue 2 era of Element UI are both long past their support, and Node 12 reached the end of its life long ago. The code is a snapshot of an approach that was current at the time, and the author is candid about that, noting in the project description that the code was written several months earlier and would be refactored if there were time.

The overall style is described as minimal, on the reasoning that as a person's mind reaches a certain stage it leans toward simplicity.

Three services and one reverse proxy

The Docker Compose file is the clearest description of the architecture, and it has four services rather than three.

Nginx is the front. It exposes ports 80 and 443, mounts the nginx configuration file from the config directory into the container, and links to the two application services so it can route to them by name.

yaml
  mongodb:
    image: mongo:latest
    container_name: mongodb
    ports: 
      - 27017:27017
    volumes: 
      - ~/data/db:/data/db

MongoDB is a service in its own right, with its data directory mounted from the host so the database survives a container rebuild. Note that the database port is published to the host, which is convenient in development and a problem in production.

The API server is built from the server directory, restarts always, publishes port 3000, links to the MongoDB service and mounts an uploads directory so that uploaded files survive restarts.

yaml
  server:
    build: ./server
    container_name: server
    restart: always
    ports:
      - 3000:3000
    external_links:
      - "mongodb:mongodb"
    volumes:
      - ./server/uploads:/server/uploads

The web service is built from the web directory, restarts always, publishes port 8000 and links to both the API server and MongoDB.

So there are three application processes behind nginx: the reader facing site, the administration panel, and the API, plus the database.

Deployment, and the one step that catches everyone

The deployment section is written for someone who does not write code, and the promise is that following the tutorial gives you a working site.

The steps are: pull the three folders, web, server and config, plus the compose file from the repository; edit the nginx configuration file inside the config folder to put in your own domain, which the file explains in comments; create a data folder on the server and upload the three folders and the file into it; install Docker on the server; enter the data directory and run docker-compose up -d; and then check with docker-compose ps or docker ps -a whether everything is running.

The front end is then at the domain and the administration panel is at the admin path under it.

The bolded warning that follows is the step people miss. You have to enter the administration area first and set the basic information, and only then does the front end work normally. Without it the site reports an error, which is an unpleasant first impression for a project whose selling point is that a beginner can deploy it in an afternoon.

There is a small honesty in the note about the compose command possibly not existing, where the author says they would have to install docker-compose if the command is not found and declines to spend time on it. It is a minor blemish on an otherwise unusually well organised set of instructions.

The reader side and the open commenting model

The front end is the Nuxt server side rendered site, with hand written styles, and the README says the design borrowed somewhat from the Diaspora open source project.

The page list is given as a short block.

code
# 首页
# 文章详情
# 文章列表
# 短语列表
# 个人介绍
# 心情订阅
# 游客留言
# 下雨天页

So a home page, an article detail page, an article list, a list of short phrases, a personal introduction, a mood subscription, a guest message board and a rainy day page.

The access model is the interesting decision. The site is open to everyone, and the README says it is aimed at passers by, visitors and the public, that no account registration is needed to comment or to read, and asks rhetorically whether a visitor is expected to register an account just to leave a comment.

That is a deliberate product choice rather than an oversight. A personal site that wants readers to comment without a sign up wall is making a different bet from one that wants accounts, and every piece of the front end, from the comment form to the local storage caching of the commenter's details, follows from it.

The feature the README singles out is the background music on the article page, where each article can have its own music chosen to match the mood of the post, with the observation that mood writing tends towards quiet, gentle and calm choices.

The README also records what is not finished: the article page is listed as still being worked on, the dark theme is an ongoing task, and a guest message page is still to be added.

The admin panel and the PASS code

Only the administrator can enter the back office, and the account model is unusual enough to explain.

The account can only be registered once. A PASS code is required and must correspond to the email address, and the README explains where it comes from: it is found in the settings of the email account and is used for the email notifications, including comment notifications and password recovery.

In other words, the PASS code is a second factor that only the owner of the mailbox has, and the system uses it to authorise sending mail on the site's behalf and to reset the password.

The rest of the panel is a conventional blog administration. Articles are written in Markdown, with a background image and background music per post, either by link or uploaded locally, with the upload target configurable in the settings and an option to use Aliyun object storage. The README advises compressing images and using the prescribed upload dimensions for performance, and notes that articles can be hidden.

Comments can be deleted and replied to, and the README is firm that they cannot be edited.

The settings page is the longest list in the project, and it is where the shape of the site is actually defined: backend information such as nickname and avatar, which are shared between the front and back ends, site information including the name, description and search engine settings, front page settings for the home information, page music and the footer registration details, the first screen effect with the home page image, the personal introduction page, the uploaded files with a choice of upload location, the email provider, which currently supports only QQ and 163 mailboxes but is extensible, the comment features, the administrator marker, comment notifications to people who are replied to, whether new article notifications are on, whether the guest message page is enabled, the PASS code used for notifications, and the password change field.

Local development, logos and the state of the project

The local development section assumes you can run MongoDB yourself.

The steps are to install the database and run the service, then add entries to the hosts file so the three host names resolve locally, which the README explains is for compatibility with the Docker deployment.

code
127.0.0.1 web
127.0.0.1 server
127.0.0.1 mongodb

Then each directory needs an install, and the scripts differ by role: the development script for the web project and the serve script for the admin and server projects.

code
npm install    ## 每个目录必须
npm run dev    ## web
npm run serve  ## admin & server

The troubleshooting note is the most useful sentence in the section: if the server console reports errors or connection timeouts, it is because MongoDB is not running. The README also gives the port to check, the default MongoDB port on the local machine, and says that a string of English text there means the database started.

The logo instructions are equally specific, because they are the first thing every user does. Four images go in the static image logo directory of the web project: two home page logos at 456 by 200, one white and one black and transparent, a sub page logo at 200 by 200, and a tab icon of any kind.

The repository holds the admin, config and server directories, the web directory, the compose file and a project code explanation document. The last push was on 2026-05-23 and there are no tagged releases, so the project is distributed as a branch rather than as versions. The licence field is not classified, and the README says the project is open source, but a licence file is what you need before you redistribute it.

The author's own summary is that this is a full stack project shared with the hope of suggestions, bug reports and improvements.

Editorial conclusion

Mood suits someone who wants their own small blog with a reader site, an admin panel and Docker based deployment without assembling a stack themselves, since the three services, the nginx configuration and the upload volume are already arranged. It is the wrong choice for a site that needs a growing team behind it, since the admin area is a single administrator account, and the wrong choice if you need a modern framework baseline, because the pinned versions in the badges are several years old. Verify first that the front end renders only after the first screen information has been filled in, since the README states the site errors otherwise, that your MongoDB data is not published on the host port in production, and that the licence situation is acceptable, since the repository does not state one.

Frequently asked questions

What is the Mood project?

It is a full stack blog system with a Nuxt server side rendered front end for readers, a Vue and Element UI administration panel, a Node API backed by MongoDB, and an nginx front, with a Docker Compose file that wires the four services together.

How is Mood deployed?

You pull the web, server and config folders and the compose file, point the nginx configuration at your own domain, create a data folder on the server, install Docker, and run docker-compose up -d from that folder, checking with docker-compose ps that the services are running.

Why does the front end show an error after deployment?

Because the first screen information has not been filled in yet. The README states that you must enter the administration area and set the basic information first, otherwise the front end reports an error.

How does the administrator account work?

The account can only be registered once and needs a PASS code that must correspond to the email address. The code is taken from the email account settings and is used for notifications such as comment replies and password recovery.

Official sources

  1. Issues
  2. Project website
  3. README
  4. wsydxiangwang/Mood on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/wsydxiangwang-mood.svg)](https://hysenlabs.com/projects/wsydxiangwang-mood)

Was this useful?