Hysen Labs
Open-source project
tkzt/boring-days avatar
tkzt

boring-days

A tool to record every boring day.

26 stars2 forksVueLicense varies
DEEP OPEN-SOURCE ANALYSIS

Boring Days is a self hosted calendar built with Nuxt and PostgreSQL

Boring Days is a Nuxt 4 and PostgreSQL calendar application that tracks task states and shows them as colored entries on a month view.

What the app does

Boring Days is a calendar application built with Nuxt 4 and PostgreSQL. The README, written in Chinese, describes it as a calendar app where schedules can be marked as not started, in progress, completed, overdue, or decided not to do, and those states appear in the month calendar as yellow, blue, green, red, and gray respectively. The color mapping gives an at a glance view of which tasks are moving and which are stuck or dropped. The app is meant to be run locally or self hosted, and the README focuses on how to start it rather than on feature lists or screenshots. There is no description of sharing, team features, or integrations, so the tool reads as a personal scheduling surface rather than a collaborative planner. The README also does not mention recurring events, reminders, or notifications, and it does not present any benchmark or scale claim. The framing of the project as a record of every boring day suggests a lightweight daily log of intentions and outcomes. Because the state model is explicit and small, the mental model for a user is simple: each entry has one of five statuses, and the month view communicates progress through color. The application depends on a relational database for storage, which keeps the data in a form that an operator can back up or inspect directly through PostgreSQL.

Running with Docker Compose

The README gives a Docker Compose path as the primary way to run the app. The operator exports two environment variables before starting: NUXT_AUTH_SECRET, which must be a long random secret of at least 32 characters, and NUXT_USER_PASSWORD, which sets the admin password. Then docker compose up with the build flag starts the stack and opens on http://localhost:3000. PostgreSQL data is kept in a named volume called postgres_data, and the README notes that the schedule tables are created automatically on the first request to the schedule API. This means the database schema is initialized lazily by the application rather than through a separate migration step that the user runs by hand. When not logged in, schedules cannot be read or modified, so the app enforces authentication before exposing data. On startup the app creates or updates an account with the username admin whose password comes from NUXT_USER_PASSWORD, and the README explains that changing that environment variable and restarting rotates the password. The production note is explicit: a strong NUXT_AUTH_SECRET must be set because it signs the login session cookie. The Docker path is the simplest supported install and keeps the database in a volume that survives container recreation. It avoids a separate migration step for the schedule tables because the schema is built on first use.

Local development and build

For local development the README describes a pnpm based flow. The developer runs pnpm install, then docker compose up with the db service in the background, and finally pnpm dev to start the Nuxt dev server. It states that a .env file can be created locally or the default connection string can be used, and that Nuxt reads NUXT_DATABASE_URL, NUXT_AUTH_SECRET, and NUXT_USER_PASSWORD at runtime. Example values in the README repeat the long random secret and a strong admin password as placeholders. A production build uses pnpm build. Beyond these commands the README does not describe the project structure, the API endpoints, or the front end components, so a new contributor gets only enough to run the app, not a map of the code. The README also does not mention tests, linting, or a contribution guide, which marks the project as a small personal tool rather than a large maintained library. With 26 stars in the metadata, Boring Days is an early stage project. The absence of a stated license in the metadata means the default copyright applies until the author adds one, and anyone planning to reuse the code should confirm the licensing terms with the repository. The practical takeaway is a simple, self hosted calendar that runs from Docker Compose and uses PostgreSQL for durable storage.

Editorial conclusion

The project is published without a stated license and its most recent commit was on 2026-08-26.

DEEP OPEN-SOURCE ANALYSIS

Official sources

Community notes

Community notes