View as Markdown

#Pricing

How much does Glassmkr cost?

Nothing, in both deployment forms.

Self-hosted: free forever, with no node limits. That is not a promise you have to take on trust; the license makes it true. The dashboard monorepo is AGPL-3.0-only and the Crucible agent is MIT, so the whole stack is yours to run.

Hosted (app.glassmkr.com): free, with a 10-node per-account cap. The cap is capacity protection for a service we operate, not a tiering lever. Hosted is intended to stay free.

Is Glassmkr open source?

Yes, entirely. The dashboard monorepo is AGPL-3.0-only at github.com/glassmkr/crucible; the Crucible agent is MIT at github.com/glassmkr/crucible. One Docker Compose file runs the whole stack on your own hardware: see /docs/self-hosting.

What happened to the paid Pro tier?

Retired in August 2026, when the entire stack went open source. Everything Pro used to gate is now included for every account: 90-day retention, AI analysis, and up to 10 hosted nodes (self-hosted has no node limits). Nothing is billed; any historical charges were settled through Stripe. See the billing policy.

#The agent

Which operating systems does Crucible support?

Crucible runs on Linux. Tested distributions: Ubuntu 20.04 / 22.04 / 24.04, Debian 11 / 12, RHEL 8 / 9, Rocky Linux 8 / 9, AlmaLinux 8 / 9, Arch (rolling), Amazon Linux 2 and 2023. systemd plus kernel 4.18 or newer. x86_64 and aarch64.

Windows and macOS are not supported. For non-Linux hosts, push to the API directly with a custom collector.

How much CPU and memory does Crucible use?

Lightweight by design: under 1% of host RAM on every host we tested. Measured on Crucible 0.13.6 across all 10 validation hosts at steady state: median 108 MB RSS (range 81 to 116 MB, varies with the bundled Node version), near-zero CPU, and an fio delta under 1.5 percent. The binary is about 12 MB; logs rotate at 50 MB by default. Each push is 2 to 5 KB of compressed JSON; at the default five-minute interval, that is about 5 MB/day.

Does Crucible need root access?

Crucible runs as the non-root glassmkr user. The install script provisions udev rules and group memberships that grant the user the necessary read access to /dev/ipmi0, raw block devices for SMART, and /proc / /sys. If you disable IPMI, SMART, and ECC monitoring, the agent works without those rules.

Do I need to open any inbound ports?

No. The agent initiates all connections outbound over HTTPS (port 443). Your firewall does not need to change.

Does the agent work without IPMI?

Yes. If ipmitool is not installed, or the host simply has no BMC, the IPMI module is silently skipped and the snapshot emits null for the IPMI fields. The dashboard renders that as "no signal (BMC not probed)". All other monitoring continues normally. See /docs/troubleshooting/ipmi.

The case that is not silent is a BMC that is present but stops answering. When the kernel exposes an IPMI device and the agent still gets nothing back from it, the dashboard raises ipmi_monitoring_unavailable, because fan, PSU, and SEL alerts would otherwise read healthy on a machine whose hardware is no longer being watched at all. This one requires agent 0.14.9 or newer, which is the version that began reporting the two facts the check needs; on an older agent the condition is still silently skipped. Remote power control and console access are usually gone at the same time, so it is worth knowing promptly.

A low ipmitool version from your distribution's package does not stop monitoring. Agent versions 0.14.6 through 0.14.8 refused to run ipmitool below 1.8.19 because of CVE-2020-5208, which switched off BMC monitoring on stock Ubuntu 20.04 and 22.04 and RHEL-family 9. Those distributions ship the security fix inside a 1.8.18 package without changing the version number, so the check could not tell a patched build from an unpatched one and was disabling monitoring on hosts that were never exposed. From 0.14.9 the agent collects normally and records the version instead, and from 0.14.10 it also records the package version so you can see the release suffix that carries the fix. A build below 1.8.19 that no distribution package owns, such as one compiled from source, is still refused: nothing backported a fix into it, and Crucible runs ipmitool as root. Note that /usr/local/bin precedes /usr/bin in sudo's secure_path, so a local build shadows the packaged one; command -v ipmitool shows which one wins. To refuse every below-floor build regardless of origin, set collection.enforce_ipmitool_min_version: true in /etc/glassmkr/crucible.yaml.

How do I update Crucible?
sudo npm install -g @glassmkr/crucible@latest
sudo systemctl restart glassmkr-crucible

Pin a specific version with @glassmkr/crucible@0.13.5. Configuration in /etc/glassmkr/crucible.yaml is preserved across upgrades. (Pre-0.13.5 installs have the file at the legacy /etc/glassmkr/collector.yaml path; the agent reads either, and glassmkr-crucible init migrates the file in place on next run.)

How do I uninstall Crucible?
# Stop and disable
sudo systemctl stop glassmkr-crucible
sudo systemctl disable glassmkr-crucible

# Remove the unit
sudo rm /etc/systemd/system/glassmkr-crucible.service
sudo systemctl daemon-reload

# Remove the package
sudo npm uninstall -g @glassmkr/crucible

# Remove configuration (contains the collector key)
sudo rm -rf /etc/glassmkr

Optionally delete the server from the dashboard to remove its stored metrics and, on hosted accounts, free up a slot under the 10-node cap.

#Data & retention

Where is my data stored?

Metric data is stored on Glassmkr infrastructure in the EU. The operating company is a Czech sole-trader; all dedicated servers (including the database and the AI GPU) sit in EU data centers, so the deployment inherits GDPR posture from the underlying provider. Data is encrypted at rest using AES-256 and in transit using TLS 1.3.

Glassmkr does not store raw system logs, process lists, or file contents. The collected data is numerical metrics (CPU, memory, disk, network counters) and hardware status identifiers (SMART, RAID, sensor readings).

How long is metric data retained?

Hosted: 90 days for every account. Data older than 7 days is downsampled to 5-minute resolution; data older than 30 days is downsampled to 1-hour resolution.

Self-hosted: the same 90-day default, because the same migrations run. It is a ClickHouse table TTL, so you can change the window on your own instance.

What happens if connectivity is lost?

The server_unreachable rule fires after the server misses 2 consecutive check-ins (about 2 minutes at the default five-minute interval). Crucible buffers up to 60 snapshots in memory (about 1 hour at the default interval) and pushes the queue in order when connectivity is restored. If the buffer fills, the oldest snapshots are dropped first.

Can I export my data?

Yes. Pull metric data via the health history API. The response is JSON and can be piped into any analytics tool. For bulk exports, contact support for a CSV or Parquet dump of your account's data.

Can I self-host the dashboard?

Yes. The entire stack is open source: the dashboard monorepo (including the alert evaluation engine) is AGPL-3.0-only at github.com/glassmkr/crucible, and the Crucible agent is MIT at github.com/glassmkr/crucible. One Docker Compose file brings it up: see /docs/self-hosting. On your own instance, your data never leaves your hardware.

#Alerts & AI

How many alert rules ship out of the box?

70 rules across 9 categories: storage, ZFS, filesystem, memory and CPU, network, hardware (BMC / IPMI), GPU, time and services, security and patching. Every rule ships with deep FIX content (safe-mode, validation, rollback, impact); 30+ are verified end-to-end on real hardware. Browse at /docs/rules.

What do the P1-P4 priority levels mean?

Every alert has a priority from P1 (critical, immediate action required) to P4 (informational). Priority drives the badge color on alert cards and the emoji prefix in Telegram / Slack notifications. P1 indicates data loss or service outage; P2 indicates significant degradation; P3 is an early warning; P4 is a proactive recommendation.

How does alert muting work?

Mute specific alert rules on a per-server basis from the server detail page or via the configuration file. Muted rules are not evaluated and do not fire notifications. Useful during maintenance windows, RAID rebuilds, or known-condition periods. Unmuting takes effect on the next ingest cycle. Alerts do not fire retroactively for conditions that occurred while muted.

How does AI analysis work?

Glassmkr uses a self-hosted Gemma 4 model (running on a dedicated GPU server in the EU; no commercial LLM APIs) to analyze server health when alerts fire. AI analysis is enabled on hosted accounts; a self-hosted instance enables it by pointing LLM_API_URL at any OpenAI-compatible endpoint. The model reviews current metrics (including per-core CPU when available), recent trends, and the alert context to produce a one-sentence summary of the likely cause. The model is tuned to be conservative, to hedge, and to say "I don't know" when the signal is ambiguous. AI analysis is shown on the alert card and included in Telegram / Slack notifications.

What is per-core CPU monitoring?

When collectors.cpu.per_core: true (Crucible 0.3.0+), Crucible reports individual CPU core utilization in addition to aggregate metrics. Enables the per-core CPU chart in the expanded view and gives the AI analyzer per-core awareness. Useful for spotting single-threaded bottlenecks, core pinning issues, and uneven load. Increases data volume proportionally to core count.

#Operations

Can I monitor Docker containers or Kubernetes pods?

Crucible monitors the host system, not individual containers. Container CPU and memory are visible in the host metrics as part of the total. Dedicated container and Kubernetes monitoring is on the roadmap.

Crucible itself installs natively on the host (systemd or npm); there is no containerized deployment of the agent, since a bare-metal hardware agent needs direct host access (IPMI, SMART, /proc, /sys) that a container cannot provide without running fully privileged.

What sign-in methods does Glassmkr support?

Email + password, Google OAuth, and GitHub OAuth. Connect or disconnect OAuth providers under Settings → Account. There is no built-in TOTP today; rely on your OAuth provider's two-factor configuration if you sign in via Google or GitHub.

Is there an API rate limit?

Yes. Token-bucket limiter with per-IP / per-key / per-account tiers plus per-endpoint sub-limits for write actions. Per-IP is 100 burst at 10/sec; per-key is 1000 burst at 100/sec; per-account is 5000 burst at 500/sec. Server registration, deletion, and key rotation each have their own hourly sub-limits. Ingest is rate-limited to one push per server per 55 seconds. See the API reference for the full table.

#Support

How do I contact support?

Email [email protected] with your account email and server ID. Include the output of sudo journalctl -u glassmkr-crucible --since "1 hour ago" --no-pager if the issue is agent-side.

Last verified: 2026-05-22 against Crucible v0.13.3.