What makes hearth notable?

1.1K downloads. Trust evidence available

How should hearth be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

hearth

A fast, READ-ONLY health-check sweep across every device in a homelab — ping, uptime/load, memory/disk, services, and app health, in ~14 seconds with output you can scan in 30. Configuration-driven: ~/.hearth/devices.yaml describes the lab; the skill itself is generic and contains no lab-specific knowledge. Use when the user asks about their homelab/estate health — "how is the lab?", "homelab status", "check all my servers", "is <device> up?", "homelab health check", "anything down in the lab?". Supports Linux, macOS, Raspberry Pi, Android (Termux/chroot), and Windows hosts (HTTP-only probe). Honest reporting — devices that can't be probed at a layer are reported as such, never faked green. Read-only by design — never restarts services, never installs anything, never writes to remote hosts.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

0.3.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.3.0release · observed Oct 6, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s1747h3dssx5wbb4xxpn85vtsd83gnax:hearth

Install using `clawhub skill install s1747h3dssx5wbb4xxpn85vtsd83gnax:hearth` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/nj070574-gif/hearth before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-nj070574-gif-hearth/snapshot"

Documentation

CLAWHUB

150,170 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: hearth
version: "0.3.0"
description: >
  A fast, READ-ONLY health-check sweep across every device in a homelab — ping,
  uptime/load, memory/disk, services, and app health, in ~14 seconds with output
  you can scan in 30. Configuration-driven: ~/.hearth/devices.yaml describes the
  lab; the skill itself is generic and contains no lab-specific knowledge. Use
  when the user asks about their homelab/estate health — "how is the lab?",
  "homelab status", "check all my servers", "is <device> up?", "homelab health
  check", "anything down in the lab?". Supports Linux, macOS, Raspberry Pi,
  Android (Termux/chroot), and Windows hosts (HTTP-only probe). Honest reporting
  — devices that can't be probed at a layer are reported as such, never faked
  green. Read-only by design — never restarts services, never installs anything,
  never writes to remote hosts.
author: nj070574-gif
license: MIT
tags: [homelab, monitoring, health-check, read-only, ssh, devops, sysadmin, openclaw]

requires:
  primary_credential: none
  env:
    - name: HEARTH_CONFIG
      description: >
        Optional. Path to the devices.yaml inventory. Defaults to
        ~/.hearth/devices.yaml. This file, not chat, is the sole source of the
        hosts hearth probes.
  optional_env:
    - name: HEARTH_PASS_<DEVICE>
      description: >
        SSH password for a device whose config sets auth: ssh-pass. One env var
        per device (e.g. HEARTH_PASS_FILESERVER). Never stored in the YAML.
    - name: HEARTH_<APP>_TOKEN
      description: >
        Optional bearer token for an L5 HTTP probe that needs auth (e.g. a
        Home Assistant long-lived token). Supplied via env var, never the YAML.
    - name: HEARTH_SSH_STRICT
      description: >
        SSH host-key verification mode — accept-new (default, trust-on-first-use
        + reject changed keys), yes (strictest), or no (disabled, warns). See
        "Host-key verification" below.
    - name: HEARTH_KNOWN_HOSTS
      description: >
        Optional. Path to hearth's dedicated known_hosts file. Defaults to
        ~/.hearth/known_hosts so hearth never touches ~/.ssh/known_hosts.
  binaries:
    - ssh        # remote probes (OpenSSH client)
    - curl       # L5 HTTP app-health probes
    - python3    # YAML + JSON parsing (or yq as an alternative)
    - ping       # L1 reachability
    - awk        # output parsing
    - sed        # output parsing
    - grep       # output parsing
    - sshpass    # OPTIONAL — only if a device uses auth: ssh-pass; never invoked otherwise

security:
  scope: owner-operated
  risk_level: low
  risk_acknowledged: true
  risk_justification: >-
    hearth is read-only. Every probe is a non-mutating query (ping, uptime,
    free, df, systemctl is-active, curl GET). It never restarts a service,
    installs a package, or writes to a remote host. The only local writes are a
    per-run temp file and the user's own hearth known_hosts. Install only on a
    bridgehead you own, pointed at a lab yo

README.md

# 🔥 hearth

> *the heartbeat of your homelab*

**One command. 14 seconds. Every device in your lab. Same format, one screen.** No agent to install on remote hosts, no database, no SaaS, no telemetry — just read-only SSH probes from a single bridgehead. Read-only by design, host-key verification on by default, honest about what it can't see, and small enough to read top-to-bottom in 15 minutes before installing.

```
=== HOMELAB — ESTATE HEALTH SWEEP ===
Timestamp: 2026-05-02T13:24:19+01:00

=== 192.0.2.10 main-server (OpenClaw / agent) === [OK]
  L1 ping:    OK
  L2 uptime:  1 day, 2 hours, load: 0.15 0.18 0.15
  L3 mem:     used 1.6Gi / 7.7Gi, 6.0Gi avail | disk: / 6% used, 814G free
  L4 svc:     openclaw=active nginx=active ollama=active cron=active
  L5 app:     gateway={"ok":true,"status":"live"} | https-front=HTTP 200

=== 192.0.2.20 fileserver (Samba + NFS file server) === [DEGRADED]
  L1 ping:    OK
  L2 uptime:  10 weeks, 3 days, load: 0.22 0.12 0.04
  L3 mem:     used 364M / 2.7G, 2.1G avail | disk: / 92% used ⚠, 11G free
  L4 svc:     ssh=active nginx=active smbd=active nmbd=active nfs-mountd=active
  L5 app:     nginx=HTTP 200 | fileserver-manager=HTTP 302 | ts=connected
  reason:     disk 92% >= 90%

=== 1/2 healthy, 1 degraded — 14s ===
```

Every device resolves to **`[OK]` / `[DEGRADED]` / `[DOWN]`**, the run ends with a one-line summary, and the exit code (`0`/`1`/`2`) means you can drop `sweep.sh` straight into cron or CI. Add `--json` for a machine-readable version an agent or script can reason over.

## What this gets you

**Before hearth:**
```
$ ssh server-1
$ uptime; free -h; df -h; systemctl is-active nginx postgres redis
$ exit
$ ssh server-2
... (repeat 8 more times)
```
Eight minutes of typing. By server 5 you've forgotten what server 1 said. By server 10 you've missed the disk filling up on server 3.

**With hearth:**
```
$ ./scripts/sweep.sh
```
14 seconds. Every device. Same format. One screen. Done.

## Why hearth, specifically

There's no shortage of monitoring tools. hearth is different in four ways that matter:

- **Read-only — guaranteed.** hearth never modifies remote state: no service restarts, no package installs, no writes to remote hosts at all. The only local writes are a per-run temp file and hearth's own `~/.hearth/known_hosts`. You can run it from an LLM agent, from cron, from a colleague's shell — it can't change anything on the hosts it probes. Most monitoring tools can't make that promise.
- **Secure by default.** SSH host-key verification is on out of the box (`StrictHostKeyChecking=accept-new`), pinning each host's key to a dedicated known_hosts file so a changed key aborts the probe rather than leaking a password to an impostor. SSH keys are preferred over passwords. See [Security & privacy](#security--privacy).
- **Honest about what it can't see.** When a layer can't be probed (Windows host with no SSH, chroot with no systemd), hearth says so explicitly — `unmanaged-host (no SSH)`, `no-systemd (

_meta.json

{
  "ownerId": "kn75wmg9n12pjn92x60r99d04983gkgd",
  "slug": "hearth",
  "version": "0.3.0",
  "publishedAt": 1791283698961
}

CHANGELOG.md

# Changelog

All notable changes to hearth will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [0.3.0] — 2026-10-05

### Security
- **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`.
- **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location.
- hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

### Changed
- **SKILL.md restructured with declarative security frontmatter** — added `requires:` (with an explicit `binaries:` allow-list), `security:` (scope, risk level, auth method, host-key verification, credential handling, network access), and `prompt_injection_mitigation:` blocks, plus "Scope & least privilege", "Host-key verification", "Input handling & injection safety", and "Intended use & risk acknowledgement" sections. This declares hearth's read-only, least-privilege boundaries explicitly rather than leaving them implicit.
- **Tightened skill triggers** to homelab-scoped phrasing (e.g. "homelab status", "check all my servers", "is <device> up?") so the skill no longer matches generic, non-homelab questions.
- **Docs clarified**: README's registry-badge section condensed; INSTALL notes that package-manager/`sudo` steps are run by the user (never by hearth) and documents the new SSH host-key env vars; PLATFORMS reframes Tailscale/Docker capability notes (`NET_ADMIN`, `/dev/net/tun`) as third-party-tool caveats that hearth itself never needs.
- Uninstall instructions use `rm -r` (non-forced) instead of `rm -rf`.

### Notes
- Backward-compatible: existing `devices.yaml` files work unchanged; read-only probe behaviour is unchanged. The only behavioural change is that a host whose SSH key has changed since first contact will now abort its probe (the intended MITM guard) until the stale entry is removed from `~/.hearth/known_hosts`.

## [0.2.0] — 2026-10-02

### Added
- **Parallel sweep.** Devices are now probed concurrently (bounded pool, default 8) with output still printed in config order — the full-estate sweep is dramatically faster on larger labs. `--sequential` restores one-at-a-time behaviour; `--parallel <n>` sets the concurrency cap.
- **Health status, summary and exit codes.** Every device resolves to `[OK]` / `[DEGR

CONTRIBUTING.md

# Contributing to hearth

Thanks for considering a contribution. hearth is a small project with a clear scope, so a few notes up front will save us both time.

## Scope

hearth is a **read-only health-check skill for homelab admins**. It is intentionally NOT:

- A monitoring system (use Prometheus/Grafana)
- An alerting system (use Alertmanager / Healthchecks.io)
- An automation system (use Ansible / Salt)
- A configuration management tool

Issues / PRs that move hearth toward any of those are likely to be politely declined. Issues / PRs that improve the core read-only sweep, add new device archetypes, fix bugs, or improve docs are very welcome.

## Before opening an issue

1. Check the [TROUBLESHOOTING.md](docs/TROUBLESHOOTING.md) — most issues are documented there
2. Check existing issues — your problem might already be tracked
3. Include in your issue:
- What platform you're running hearth on (Linux distro / macOS version / WSL version / Termux version)
- What platform the device you're probing is
- Sanitised excerpt of your `devices.yaml` (REDACT real IPs, hostnames, and tokens before pasting)
- The exact output you got
- The output you expected

## Before opening a PR

1. **Privacy first** — never include real IPs, real hostnames, real tokens, or real domain names in code, examples, or commit messages. Use the `192.0.2.0/24` documentation block (RFC 5737) and `example.com` for any sample data.
2. **Read-only invariant** — every probe must be read-only. No `systemctl restart`, no `apt-get install`, no `rm`, no writes to remote hosts beyond `/tmp/.hearth_*` files which are immediately cleaned up.
3. **Honest reporting** — if a layer cannot be probed for a given device type, the output must say so (e.g. "no-systemd (chroot — N/A)"), never silently fake a green result.
4. **Test it** — show that your change works against at least one real device before opening the PR.
5. **Document it** — if you add a new feature or device archetype, update the docs.

## Adding a new device archetype

If your homelab has a device type not covered by the existing six archetypes, a new archetype is a great contribution. The pattern:

1. Pick a generic name — `freebsd-host`, `truenas-server`, `proxmox-node` etc.
2. Add `examples/archetypes/<name>.md` describing the archetype and its probe specifics
3. Add a snippet to `examples/devices.example.yaml` showing the YAML for this archetype
4. Update the README archetype list

## Code style

- **Bash** — POSIX-leaning where possible, `bash` features OK if behind `#!/bin/bash`. Use `shellcheck` before submitting.
- **YAML** — 2-space indent, no tabs.
- **Markdown** — wrap at ~100 chars where natural, ATX headings (`#`, `##`, `###`).
- **Commit messages** — imperative mood, ≤72 char subject. Body wrapped at 72.

## License

By contributing, you agree your contributions will be licensed under the MIT License of this project.

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.