Self-Hosted Metrics

Open-source SDK telemetry, honestly reviewed. Built for the specific problem nobody else is solving.

TL;DR

• What it is: AGPL-3.0 telemetry platform designed for software vendors who ship self-hosted products and want usage data without spying on their users [README].
• Who it’s for: Developers and founders who distribute on-premise software and are flying blind — no idea how many instances are running, which versions are active, or whether features get used [README].
• Cost savings: Comparable commercial telemetry (Mixpanel, Segment, Amplitude) starts at $20–28/month for teams and scales sharply with event volume. SHM self-hosted runs on a $5–10/month VPS with no per-event pricing [README].
• Key strength: Cryptographically signed instance identity via Ed25519 keypairs — each deployment generates a unique ID that can’t be spoofed. Zero-config dashboard baked into a single Go binary [README].
• Key weakness: 148 GitHub stars, no third-party reviews published, AGPL-3.0 license with commercial redistribution restrictions, and the project itself openly admits it is “young and evolving” [README].

---

What is Self-Hosted Metrics

Self-Hosted Metrics (SHM) solves a problem that sounds niche until you’ve actually shipped self-hosted software: you have no idea what’s happening in the wild.

When you distribute a Docker image or a self-hosted application, your users run it on their own servers, behind their own firewalls. You don’t see crashes. You don’t know if anyone is actually using Feature X. You can’t tell if version 1.2 is still the majority deployment or if your migration instructions worked. The normal SaaS telemetry tools — Segment, Mixpanel, PostHog — are designed for web apps where all traffic flows through your servers. They don’t map onto the distributed on-premise model.

SHM’s answer is a lightweight, SDK-based approach. You integrate the SHM client SDK into your software. When a user deploys your software, the SDK sends cryptographically signed payloads to your SHM server (which you run, not them). You see instance counts, version distribution, and any custom business metrics you want to track — like {"active_users": 14, "reports_generated": 203}. The dashboard reads whatever JSON shape you send and automatically renders it as KPI cards and charts [README].

The security model is worth noting. Each instance generates a unique Ed25519 keypair on first run. All payloads are signed with the instance’s private key. Your SHM server verifies the signature before accepting any data. This makes it impossible for someone to spoof an instance or replay another deployment’s telemetry [README].

The server-side stack is Go 1.24+ with a PostgreSQL database for storage. The dashboard is a single Go binary with the frontend embedded — no separate frontend deploy, no npm install in production. The client SDK is Node.js 22+ [README].

This is not a server monitoring tool. It is not Uptime Kuma, Beszel, or Netdata. Those tools tell you whether your own servers are healthy. SHM tells you whether your software, running on other people’s servers, is being used [README].

---

Why people choose it

There are no published third-party reviews of Self-Hosted Metrics — the project has 148 GitHub stars and the README explicitly asks for feedback from early users, noting “SHM is young and evolving” [README]. So this section draws from the problem space rather than collected testimonials.

The commercial monitoring category gives useful price context. Datadog charges $15/host/month and sends every CPU reading to their servers. Grafana Cloud limits free accounts to 10,000 metric series, then charges $8 per 1,000 more [1]. New Relic collects telemetry across your entire stack and bills on data ingestion [1]. These are all cloud-centralized tools designed for teams monitoring their own infrastructure. None of them address the vendor use case where your software is running on 400 different customers’ servers across 12 countries.

The closest open-source analogs in adjacent categories — PostHog for web product analytics, Umami for web traffic — require your users to be sending events through a browser or a web request. A self-hosted application with no web-facing component doesn’t fit that model either.

SHM fills a genuine gap. The README is direct about what problem it solves: “When you distribute self-hosted software (on-premise), you fly blind. You don’t know how many instances are running, which versions are active, or if your features are actually used” [README]. The pitch isn’t “better than Datadog” — it’s “a thing Datadog doesn’t do.”

The privacy framing matters to the audience. If your users chose self-hosted software precisely because they don’t trust cloud vendors with their data, bolting on a Mixpanel integration feels like a betrayal. SHM collects aggregate counters, not user content. The data goes to your server, not a third party. The README is explicit: “Collects aggregate counters, never user content” [README].

---

Features

Based on the README and website description:

Core telemetry engine:

• Instance registration with Ed25519 keypair generation [README]
• Cryptographic signing on every payload — no spoofing possible [README]
• Any JSON payload accepted — the schema is not fixed [README]
• Multi-app support — track multiple products on one SHM server [README]
• Automatic separation of business metrics (custom KPIs) vs system metrics (CPU, RAM, OS) [README]

Dashboard:

• Single Go binary with embedded UI — no separate frontend [README]
• Dynamic rendering: send {"pizzas_eaten": 10} and the dashboard creates a KPI card automatically [README]
• Instance details view, metrics graphs, version distribution [README]
• Dark mode, modern UI (per screenshots in README) [README]
• GitHub Stars integration — auto-fetches and displays star counts for tracked repositories [README]

Public badges (embeddable in READMEs):

• Active instance count badge [README]
• Most-used version badge [README]
• Aggregated metric badges (e.g. total users_count across all instances) [README]
• Combined stats badge [README]
• Query params for custom label and color [README]

Deployment and integration:

• Docker Compose native — single compose.yml to start [README]
• PostgreSQL for storage (bundled in default compose) [README]
• REST API [merged profile]
• SDK for Node.js 22+ [README]
• Kubernetes support noted in canonical features [merged profile]

What it doesn’t do (absent from README and feature list):

• No alerting — there is no notification when an instance goes offline or a metric spikes
• No log collection
• No APM or tracing
• No built-in authentication beyond what you configure at the infrastructure level (not documented)
• No multi-tenant access control

---

Pricing: SaaS vs self-hosted math

SHM has no SaaS offering. It is self-hosted by definition. The pricing comparison is between running SHM yourself and using the commercial tools you’d otherwise reach for.

If you tried to solve this with commercial analytics:

• Mixpanel Growth: $28/month for 100M events/month, but requires browser or server SDK — doesn’t naturally model the “many instances of your distributed software” use case
• Segment Teams: $120/month baseline
• Amplitude Plus: $61/month
• Building a custom solution on top of Datadog or New Relic for per-instance telemetry: $15+/host/month just for the underlying collection [1]

Self-hosting SHM:

• Software license: $0 (AGPL-3.0) [merged profile]
• PostgreSQL: bundled in the default Docker Compose
• VPS to run it: $5–10/month on Hetzner or Contabo
• Your time: 30–60 minutes for initial setup

The math is straightforward for a software vendor with even 50 deployed instances. A $6/month VPS replaces whatever you’d otherwise patch together.

One important note on the AGPL-3.0 license: This is not an MIT or Apache license. AGPL-3.0 requires that if you distribute software that includes or links to SHM code, you must release your software’s source code under AGPL-3.0 as well. If you’re integrating the SHM server into a commercial SaaS product and distributing it to customers, consult a lawyer first. Running SHM as a standalone internal tool for your own telemetry collection does not trigger this restriction [merged profile].

---

Deployment reality check

The README’s Quick Start is Docker Compose. You create a compose.yml, drop in your environment variables (database password, JWT secret), and docker-compose up. The PostgreSQL database is included in the default compose definition. The Go binary with embedded frontend runs as a single container.

What you actually need:

• A VPS with 1–2GB RAM minimum (Go is lean; Postgres is the dominant memory consumer)
• Docker and docker-compose
• A domain and reverse proxy (Caddy recommended for automatic HTTPS, nginx also works)
• Access to expose a port or set up a subdomain so deployed instances can reach your SHM server

SDK integration on the client side: The Node.js SDK registers an instance, generates a keypair, and starts sending periodic payloads to your SHM server. You define what metrics to include. The README shows a {"pizzas_eaten": 10} example — in practice you’d send whatever application-level counters matter to you: active users, features used, document counts, etc.

What can go sideways:

• Network reachability: if your users’ self-hosted deployments are in isolated networks, they won’t be able to reach your SHM server. This isn’t a bug in SHM — it’s a fundamental constraint of any telemetry system collecting from behind firewalls. Plan for graceful degradation when the SHM endpoint is unreachable.
• No SDK documentation beyond Node.js in the README. If your software is Go, Python, or Ruby, you’re either writing your own client or wrapping the HTTP API. The REST API is listed as a canonical feature but documentation depth is unclear [merged profile].
• AGPL-3.0 may require legal review for commercial embedding (see above).
• The project is early. The README’s feedback section is a direct ask for real-world usage reports — the author is still gathering information on what production deployments actually need. This is not a tool with years of battle-hardening behind it.

Realistic time estimate: 30–60 minutes to a running SHM server for someone comfortable with Docker Compose. SDK integration in your application depends entirely on your stack — from a few hours to a day if you need a non-Node.js client.

---

Pros and Cons

Pros

• Solves a real, underserved problem. Telemetry for distributed self-hosted software is a genuine gap that general-purpose analytics platforms don’t fill cleanly [README].
• Cryptographic instance identity. Ed25519 keypair per deployment is a serious security design — you get verifiable, unspoofable instance counts rather than honor-system reporting [README].
• Dynamic schema. Send any JSON; the dashboard adapts. You don’t need to define your metrics schema upfront or run migrations when you add a new counter [README].
• Zero-config dashboard. Single Go binary with embedded UI. No frontend build pipeline, no separate web server to maintain [README].
• Privacy-respecting by design. Collects aggregate application counters, not user content. Correct posture for tools whose users chose self-hosting specifically to avoid surveillance [README].
• Public badges. Embeddable SVG badges for active instance count, version distribution, and custom metrics — useful for open-source projects showing adoption [README].
• Ops/business separation. Automatic classification of system metrics vs business KPIs keeps the dashboard readable [README].

Cons

• 148 GitHub stars. This is a very young project. No track record, no large production deployments publicly documented, no community around common edge cases [merged profile].
• AGPL-3.0, not MIT. Restrictive for commercial software vendors who want to embed or redistribute. MIT would be the cleaner license for this use case [merged profile].
• Node.js SDK only. If your software isn’t Node.js, you’re writing your own client against an undocumented-ish REST API [merged profile].
• No alerting. Knowing an instance went offline is table stakes for operations. SHM has no notification system [README — absent].
• No authentication documentation. It’s unclear how access to the dashboard is secured by default, or what the recommended auth setup is for a publicly-reachable SHM server.
• “Young and evolving” — the README’s own words. Missing metrics, integration friction, and production-readiness gaps are expected and acknowledged by the author [README].
• No third-party validation. Zero published reviews, no production case studies, no community forum with troubleshooting threads. When something breaks, you’re reading source code [README].

---

Who should use this / who shouldn’t

Use Self-Hosted Metrics if:

• You distribute self-hosted software (Docker images, on-premise deployments) and have no idea how many active instances exist in the wild.
• Your users chose self-hosted precisely because they distrust cloud analytics — you need telemetry that respects that choice.
• You’re a Node.js shop and can integrate the SDK directly.
• You’re comfortable with early-stage tools and willing to contribute feedback or read source when documentation falls short.
• Your use case is simple: instance counts, version distribution, a handful of custom business counters.

Skip it if:

• You need a battle-tested tool for a production system where telemetry gaps have real consequences.
• Your software stack isn’t Node.js and you’re not willing to write a custom SDK client.
• You need alerting, log collection, or APM alongside usage metrics.
• AGPL-3.0 is a licensing problem for your commercial product.
• You need a tool with community support, Stack Overflow threads, and documented upgrade paths.

Consider a different approach if:

• You’re monitoring your own servers (not your software on other people’s servers). For that use case, Beszel, Netdata, or Uptime Kuma are more mature choices [1][2][3].
• You’re building a SaaS product with a web frontend. PostHog self-hosted handles that use case with 5+ years of production history.

---

Alternatives worth considering

The landscape here is thin because SHM’s use case is specific. The comparison depends on what exactly you need:

For monitoring your own server infrastructure (not the SHM use case, but commonly confused with it):

• Beszel — lightweight Go binary, per-container Docker stats, MIT license, minimal RAM. Best default for homelab/VPS fleet monitoring [1].
• Netdata — 2,000+ metrics at one-second resolution, 200–500MB RAM per agent, serious overkill for most setups [1].
• Uptime Kuma — availability monitoring (is the service responding?), 90+ notification channels, ~30–50MB RAM. Not metric collection, but pairs well with Beszel [1][2].

For product analytics in web applications:

• PostHog — open-source, self-hostable, fully-featured product analytics platform. 5+ years old, large community, MIT/proprietary dual license. Overkill for the on-premise telemetry use case but much more mature.
• Plausible — privacy-first web analytics. Narrower scope than PostHog, simpler.
• Umami — minimal self-hosted web analytics.

For SHM’s specific use case (telemetry for distributed software): Data not available — no direct open-source competitors with meaningful adoption were found. Commercial options in this space (LaunchDarkly for feature flags, Mixpanel for events) require your deployed instances to reach their cloud endpoints, which defeats the purpose if your users are in isolated environments.

---

Bottom line

Self-Hosted Metrics is a narrow, early-stage tool solving a real problem that most analytics platforms ignore: how do you collect telemetry from software you’ve distributed to hundreds of servers you don’t control, without becoming the surveillance layer your users were trying to escape? The cryptographic signing design is thoughtful, the zero-config Go binary approach is pragmatic, and the dynamic schema model is genuinely useful for instrumenting evolving applications.

The honest constraint is that this is a 148-star project with no published production case studies, a Node.js-only SDK, and AGPL-3.0 licensing that warrants review before commercial embedding. The README itself tells you it’s early and asks for your feedback. If you distribute self-hosted software and the “flying blind” problem is acute, SHM is worth an afternoon evaluation. If you need something proven, you’ll need to either wait for the project to mature or build your own collection layer on top of a more established stack.

---

Sources

1. QSM — “Best Self-Hosted Monitoring Tools in 2026 (No Cloud Required)”. https://quizandsurveymaster.com/best-self-hosted-monitoring-tools-in-2026-no-cloud-required/
2. Jeff Butts, XDA Developers — “I monitor all of my self-hosted services using this free tool on my Raspberry Pi” (May 25, 2025). https://www.xda-developers.com/monitor-self-hosted-services-uptime-kuma-raspberry-pi/
3. Timothy Shim, HostScore — “6 Self-Hosted Server Monitoring Tools to Safeguard Your Web Hosting Uptime” (Updated Apr 22, 2025). https://hostscore.net/learn/server-monitoring-tools/

Primary sources:

• GitHub repository and README: https://github.com/kolapsis/shm (148 stars, AGPL-3.0 license)
• Official website and meta description: https://self-hosted-metrics.com