serviceradar
ServiceRadar is an open-source network monitoring and ITOM platform built in Elixir, designed for distributed deployments in constrained or edge environments. It provides real-time monitoring, topology visualization, causal root-cause analysis, and extensibility through WebAssembly plugins.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | carverauto/serviceradar |
| Owner | carverauto |
| Primary language | Elixir |
| License | Apache-2.0 — OSI-approved |
| Stars | 882 |
| Forks | 70 |
| Open issues | 114 |
| Latest release | Unknown |
| Last updated | 2026-07-08 |
| Source | https://github.com/carverauto/serviceradar |
What serviceradar is
Elixir-based distributed system with multi-component architecture (Agent, Gateway, Core), CloudNativePG/TimescaleDB/PGVector unified data layer, WASM plugin runtime (wazero), GPU-native topology rendering (deck.gl/Apache Arrow), and SRQL query language. Integrates OTEL, GELF, SNMP, NetFlow, and Ansible automation.
Get the serviceradar source
Clone the repository and explore it locally.
git clone https://github.com/carverauto/serviceradar.gitcd serviceradar# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Requires Linux kernel with eBPF support for network scanning; validate kernel versions in target environment.
- Unified data layer depends on PostgreSQL extensions (TimescaleDB, PGVector, AGE); plan for extension installation and version alignment.
- WASM plugin development requires Go or Rust SDK; team must be comfortable with WASM toolchain and capability-based security model.
- Distributed architecture (Agent/Gateway/Core) adds deployment complexity; start with Docker Compose for eval, move to Helm for production.
- No stable release tag in GitHub; pin to commit SHAs or monitor code.carverauto.dev for version promotions.
When to avoid it — and what to weigh
- No Stable Release Cycle Required — Project has no tagged releases; latest code lives in external repo (code.carverauto.dev). Active development signals ongoing instability and no semantic versioning guarantees.
- Windows-Only or SaaS-Only Mandates — Elixir/BEAM stack targets Linux/Unix. If your infrastructure is Windows-centric or SaaS-only is required, this is not a fit.
- Turnkey Deployment without Operational Overhead — Requires PostgreSQL variants (CloudNativePG, TimescaleDB, PGVector, AGE), NATS, eBPF kernel support, and multi-component orchestration. Kubernetes Helm chart provided but operationalization is non-trivial.
- Mature Enterprise SLA/Support Guarantees — Young project (created Jan 2025); no commercial support roadmap or SLA clarity stated in data. Source development active but support model unknown.
License & commercial use
Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license granting broad rights to use, modify, and distribute.
Apache 2.0 permits commercial use without license restrictions. However, no commercial support vendor, SaaS offering roadmap, or dual-licensing model is evident from the data. Evaluate support and maintenance commitment independently before production deployment.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | High |
| DEV.co fit | Good |
| Assessment confidence | Medium |
WASM plugin system with hardware-level sandboxing and zero local filesystem/socket access is a security advancement over traditional script-based plugins. mTLS, RBAC, and SSO integration mentioned. Cosign image signing with public key verification in repo supports supply-chain integrity. However, young project maturity, no public security audit mentioned, and no vulnerability disclosure policy evident. Evaluate threat model alignment and perform security review before critical deployments.
Alternatives to consider
Zabbix / Nagios
Mature, stable, wide platform support. Lacks WASM sandboxing and modern distributed architecture; script-based plugins run as OS processes with full privileges.
Grafana + Loki + Prometheus
Established observability stack with broad integrations and community. Requires separate component orchestration; no built-in causal root-cause engine or unified ITOM focus.
SolarWinds Orion
Enterprise ITOM platform with commercial support and SLA guarantees. Proprietary, Windows-centric, high TCO. Lacks open-source transparency and WASM-based extensibility model.
Build on serviceradar with DEV.co software developers
Start with the Docker Compose quickstart, explore the WASM plugin SDK, and review deployment architecture. Assess early-stage maturity and support model before production commitment.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
serviceradar FAQ
Is ServiceRadar production-ready?
What is the difference between the GitHub repo and code.carverauto.dev?
Can I write custom monitoring plugins without learning Rust/Go?
What commercial support options exist?
Software developers & web developers for hire
From first prototype to production, DEV.co delivers software development services around tools like serviceradar. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source observability and beyond.
Evaluate ServiceRadar for Your Distributed Monitoring Needs
Start with the Docker Compose quickstart, explore the WASM plugin SDK, and review deployment architecture. Assess early-stage maturity and support model before production commitment.