Komari Glassmorphism: a Vue 3 theme that turns Komari Monitor into an ops cockpit

What Komari Glassmorphism actually is, and who it is for

The README is blunt about the packaging: this is a Komari Monitor theme distributed as an importable zip, not a normal web app deployment package. That single sentence decides the audience. If you do not already run Komari Monitor, this project has nothing to offer you, because it has no data source of its own. It reads what the Komari core and its agents report.

The visual layer is glassmorphism cards, an animated background, and light, dark or Beijing-time automatic day/night modes. The README treats that as the shell and says the real point of v3 is assembling metrics, ping, traffic, cost, health analysis and operations tooling into a panel you actually open during the day. That is a fair self-assessment. The five headline tools are topology analysis, value-for-money ranking, health summary, snapshot export and visitor security audit.

The intended user is someone running a fleet of VPS instances on Komari who wants per-node detail without leaving the dashboard. The v3.3.0 notes describe search across node name, region, IPv4/IPv6 and CPU model, favorites, and side-by-side comparison of up to four nodes. Those are fleet-operator features, not features for a single-server hobbyist.

The v3 service layer: how data reaches the cards

The architecture visible in the release notes is a layered one. A metric layer prefers the Metric Store and falls back to older interfaces, which the README states keeps compatibility with Komari 1.2.x. Above that sits a service layer that owns ping tasks, traffic totals, cost estimation and health scoring. The UI never talks to the core directly; it asks the service layer, which is why the v3.3.5 fix could pin ping task ordering in one place and have the detail cards, the legend and the chart colors all follow.

Aggregation differs per metric, and this is where the design gets interesting. The v3.3.7 notes say cumulative upload and download traffic now display the last value in each time bucket, preserving counter semantics, while ordinary load metrics keep average aggregation. That is the correct split: averaging a monotonic counter understates it, and the earlier behaviour was a real bug.

Startup was also restructured. The v3.1.2 notes describe the old flow where a single timed-out rpc.ping() blocked public settings, user info, node data and the WebSocket, and state that these calls are now independent and parallel. The README includes a small diagram showing health check, public settings, user info and node data initializing in parallel, then WebSocket or HTTP polling recovering. For a dashboard, that change matters more than any visual tweak.

One cost note worth flagging: the v3.1.9 notes say heavy blur is limited to navigation, sidebar, tables and dialogs specifically to avoid GPU and CPU overhead on dense node pages. That is an admission that the glass effect is expensive, and the project chose to contain it rather than remove it.

Installing the theme and a first real use

The README points to the release page for downloads and names the build artifact pattern komari-theme-Glassmorphism-build-<short-sha>.zip. You import that zip into Komari Monitor as a theme. There is no npm install path for end users, and the README does not document a rollback procedure for a theme import.

If you want to build the zip yourself, the package manifest requires Node ^20.19.0 or >=22.12.0 and Bun >=1.2.0, and pins packageManager to bun@1.3.14. Install dependencies and build:

bun install
bun run build

The build script runs type-check and build-only in parallel through npm-run-all2, so a type error fails the build. To produce the publishable archive, the manifest exposes a publish script:

bun run publish

For local development against a running Komari instance, the dev server is the entry point:

bun run dev

Two other scripts are worth knowing before you touch the admin panel. sync:admin regenerates the embedded admin from the official komari-web radix branch, and test:visual runs a build followed by Playwright. The README states the visual suite uses entirely fictional fixed nodes, IPs, prices and metric data, does not contact a real controller, and is not included in the release zip.

bun run sync:admin
bun run test:visual

Where the theme fails, and where it is the wrong tool

The most concrete limitation is capability gating. The README says the real-time cost fields only appear after upgrading to a core that includes Komari PR #604, and that the theme and embedded admin detect this from returned fields. Visitor audit is the same story: PR #602 is described as merged but not yet in a current Komari stable release, so the theme only enables reporting and visitor filtering after the core exposes visitor_audit_enabled. On an older core, those panels are simply absent. That is graceful degradation, but it means the feature list in the README is not a promise about your installation.

There is a second boundary the README states plainly: the usage-based cost estimator is a front-end helper, not a billing system. Accumulated traffic can reset after a reboot or a network interface change, and manual hours and one-off surcharges only participate in that single estimate. Do not reconcile invoices against it.

Performance is the third. Rendering a large fleet is handled by deferring card mounting when there are more than 30 nodes, mounting by viewport and filling in during idle time, per the v3.3.0 notes. That is a workaround for a real cost, and the glass blur is deliberately restricted for the same reason. If you want a lean text dashboard on a low-power client, this theme is the wrong choice.

Finally, the README does not document a rollback path for a theme import, and there is no separate migration guide. Plan for that before you replace a working theme.

How it differs from a plain Komari theme

The obvious alternative is the stock Komari theme, and the difference is not cosmetic. A plain theme renders node cards and detail pages from the same core endpoints. Komari Glassmorphism adds a service layer on top that reorders ping tasks, distinguishes average aggregation from last-value aggregation for cumulative counters, scores health across CPU, memory, disk, traffic, ping, offline state and disk growth risk, and exports filtered audit records as JSON or CSV.

That service layer is also the source of its fragility. Every one of those behaviours depends on fields the core may or may not return, which is why the release notes read as a chain of compatibility fixes: Metric tags preferred with legacy tag fallback, records and ping fallback retained for Komari 1.2.5, unknown ping tasks appended by numeric ID during backend upgrades. A stock theme does not have this problem because it does not build anything on top.

If you want a standalone monitoring product with its own backend, this is not a comparison at all. Komari Glassmorphism is a presentation and analysis layer for Komari, and the README says so in its positioning table.

Maintenance, upgrade cost and the MIT licence

The last push to the repository was on 2026-09-12, and the most recent release listed is v3.3.7 from 2026-08-19. The repository is not archived. The release cadence visible in the notes, v3.3.5 on 2026-08-11, v3.3.6 on 2026-08-14, v3.3.7 on 2026-08-19, is fast, and each release carries explicit fixes plus regression checks. Fast cadence cuts both ways: you get prompt corrections, and you inherit a moving target.

The upgrade cost is concentrated in the core-version dependency. The v3.1.9 notes describe switching the embedded admin back to the official komari-web radix branch and dropping reliance on unmerged billing fields, which tells you the theme has already paid a price for tracking upstream work in flight. Expect to re-check compatibility after any Komari core upgrade.

The licence is MIT, stated in the README badge and in the package manifest. MIT is permissive and places few obligations on how you redistribute or modify the theme, but it also means no warranty. The README's own note that the cost estimator is an auxiliary front-end tool and not a billing system is the kind of statement you should keep in mind when deciding what to trust it for. This is a description of the licence terms, not legal advice; read the LICENSE file in the repository for the actual text.

Editorial conclusion

Adopt it if you already run Komari Monitor, want a denser daily dashboard, and are willing to build the zip yourself with Bun 1.2 or newer. Skip it if you need a standalone monitoring app, or if your core predates the visitor audit and billing PRs, since several panels stay dormant until those fields appear. Before installing, check your Komari core version against the 1.2.x compatibility note and confirm whether visitor_audit_enabled exists on your backend.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sanrokamlan-prog/komari-theme-Glassmorphism on GitHub