# Netdata builds nightly by default, ships its dashboard under a different license, and disables eBPF in the image

> A GPL-3.0 monitoring agent that claims per-second metrics, edge processing and around half a byte per sample. The container image defaults to the nightly channel, hardcodes eBPF off, excludes every .git directory from its build context, and leaves the license of the cloud component blank in the ecosystem table.

**netdata/netdata** — Netdata turns live system and application metrics into high-resolution dashboards and alerts with little setup.

- Repository: https://github.com/netdata/netdata
- Website: https://www.netdata.cloud
- Stars: 80,726 · Forks: 6,639
- Language: Go
- License: GPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/netdata-netdata

## The default build channel is nightly, and stable takes an explicit argument

The Dockerfile has one build argument that changes what you get.

```dockerfile
FROM netdata/builder:v3 AS builder

# One of 'nightly' or 'stable'
ARG RELEASE_CHANNEL=nightly
```

The default value is nightly, and the stable path is added at the end of the installer invocation.

```dockerfile
    "$([ "$RELEASE_CHANNEL" = stable ] && echo --stable-channel)"
```

So the flag is appended only when the argument string equals stable exactly. Consequence for a reader: `docker build` with no arguments produces a nightly-channel Netdata rather than the latest release, and the two are not the same code even when a release tag exists, which the file makes visible by also linking a separate nightlies repository. Four more arguments, CFLAGS, EXTRA_INSTALL_OPTS, DEBUG_BUILD and BUILD_ARCH, are each promoted from ARG to ENV so they survive into the build steps that follow, which means a build knob set for the compiler is also visible to whatever runs later in the image.

## The image is built with eBPF disabled and the flag is not an argument

The installer call inside the image carries seven flags, and one of them turns a headline capability off.

```dockerfile
    --use-system-protobuf \
    --disable-ebpf \
    --enable-plugin-otel \
    --enable-plugin-netflow \
    --internal-systemd-journal \
```

Read that against the feature table, which claims automatic detection, native horizontal scaling and unsupervised anomaly detection at the edge. The disable flag is written directly into the RUN line rather than being expressed as an ARG, so a user cannot re-enable eBPF by passing a build argument the way they can for EXTRA_INSTALL_OPTS. Two plugins are enabled by the same mechanism, OpenTelemetry and NetFlow, and the system protobuf is reused from the builder image instead of being compiled. Consequence: if you run Netdata in a container and expected kernel-level collection from eBPF, this image does not have it, and the fix requires editing the Dockerfile rather than passing a flag, while the plugins that are enabled are the two you can turn on without a rebuild.

## The dashboard is not under the GPL, and the cloud license cell is empty

The ecosystem table has three rows and one of them is a licensing statement you have to read carefully. The Netdata Agent is GPL v3+, and the repository's own license is GPL-3.0. The dashboard, called Netdata UI, is not. It is under a license called NCUL1, described as free to use, included in standard packages, with the latest version available via CDN. The third row, Netdata Cloud, has nothing in its license cell at all, and that is the row carrying user management, RBAC, horizontal scaling and centralized alerts. Consequence: the parts you would bundle are not all under one license, so redistributing the UI is governed by NCUL1 rather than the GPL, the CDN delivery means the dashboard version can change independently of the agent, and the component holding your user accounts has no terms stated in the table at all. The root does carry a REDISTRIBUTED.md for tracking redistributed components.

## The build context excludes every .git directory, so version data is absent

The source copy into the builder is two exclusions wide.

```dockerfile
COPY --exclude='**/.git' \
     --exclude='**/Dockerfile' \
     . /opt/netdata.git
```

The repository also carries a .gitmodules, so there are submodules in the tree. Excluding .git across the whole context removes the git metadata of the repository and of any submodule, which means a build step that asks git for a version, a commit or a describe falls back to whatever default it has. The build compensates elsewhere rather than by keeping the metadata, writing an install-type file that records INSTALL_TYPE=oci and a PREBUILT_ARCH value, and letting the installer's own version reporting carry the rest. Consequence: anything that stamps a build identity into the image has to come from a build argument or a generated file rather than from the checkout, and a developer reproducing a local build with the full git history present can get a differently labelled binary from the same source.

## Four build entry points sit at the root, and one of them is CMake

The root listing puts a shell installer, an RPM spec template, a Dockerfile and a CMakeLists.txt next to each other, alongside a packaging directory and a src directory. The project's primary language is Go. So a Go codebase is built through a shell script, packaged for RPM through a spec template, containerised through a Dockerfile, and also has a CMake configuration, which is what the presence of a .clang-format file at the root and the Dockerfile's prebuilt-dependency copy step point to. The installer is the shared entry point, since the Dockerfile invokes ./netdata-installer.sh with --dont-wait --dont-start-it and --install-no-prefix /. Consequence: a contributor has four plausible answers to the question of how to build this, and they are not equivalent. The CMake layer is for the bundled native pieces rather than for the Go build, but nothing at the root says so, and picking the wrong one costs a full read of the installer script.

## Lint configuration covers C, Python, YAML and shell, and none is visible for Go

The root carries .clang-format for C and C++, .flake8 for Python, .yamllint.yml for YAML, .shellcheckrc for shell scripts, and a .codacy.yml pointing at a hosted analysis service. There are also editor and agent instruction files, .vscode/, .agents/, .claude/, CLAUDE.md, GEMINI.md and AGENTS.md. Declared as the primary language, though, is Go, and no Go linter configuration appears alongside the other four. That is not necessarily a gap, since the Go toolchain ships its own formatter without needing a config file, but it does mean the repository's lint story is expressed for four languages and silent for the one it is mostly written in. Consequence: a contributor looking for the project's conventions has six configuration files to read and none of them describes the formatting rules for the majority of the code, and the presence of a hosted-service config alongside local ones raises the question of whether a local run is equivalent to what CI enforces.

## The efficiency headline rests on one study scoped to Docker, and the comparison is a blog post

Two claims in the file need their scope read carefully. The first is a section titled Most Energy-Efficient Monitoring Tool, attributed to a University of Amsterdam study linked as an ICSOC 2023 paper, which says Netdata is the most energy-efficient tool for monitoring Docker-based systems and that it excels in CPU usage, RAM usage and execution time compared to other monitoring solutions. The scope is Docker-based systems, measured by one paper, and the file presents no methodology or competing-tool list. The second is a note inviting readers who want to put Netdata to the test against Prometheus to read a full comparison, which is a post on the project's own commercial site. Consequence: an efficiency claim that decides your infrastructure tooling should not rest on a single scoped study, and the head-to-head comparison is published by the vendor, so treat it as marketing. The storage figure in the feature table is stated the same way, as approximately 0.5 bytes per sample with tiered storage for archiving.

## Zero Configuration and Zero production impact are asserted without a scope

Two phrases carry a lot of weight in this README and neither is bounded. The first is Zero Configuration, glossed as automatic detection and discovery and auto-discovers everything on the nodes it runs. The second is a bullet in the agent row of the ecosystem table reading Zero production impact, sitting alongside the claim that you can monitor with minimal resource usage. The file also opens with a warning block whose content is a joke about people getting addicted to Netdata and there being no going back. Consequence for a reader: a monitoring agent is a permanently resident process on every host it watches, and the two phrases that would normally make you uneasy about that are stated as bullet points with no measurement, no baseline host and no conditions. The energy study is offered as evidence for the efficiency claim generally, but it was scoped to Docker-based systems, so it does not settle what an agent costs on a bare metal host.

## Conclusion

Netdata fits if you want per-second visibility on a single host or a small fleet and accept an agent that runs continuously on the machine it watches. Pass RELEASE_CHANNEL=stable explicitly when you build the image, since nightly is the default, and do not expect eBPF collection from the container build. Before you adopt it, read REDISTRIBUTED.md and the two license files the ecosystem table names, because the dashboard is not under the agent's GPL and the cloud component's terms are not stated in the README.

## FAQ

### What exactly is Netdata?

The README calls it an open-source, real-time infrastructure monitoring platform, for monitoring, detecting and acting across your infrastructure, with per-second metrics and visualizations. The core piece is the Netdata Agent, which handles collection, storage, ML, alerts and exports and runs on servers, cloud, K8s and IoT.

### Is Netdata free to use?

The agent is GPL v3+. The Netdata UI is under a separate license called NCUL1, described as free to use and included in standard packages with the latest version via CDN. Netdata Cloud has a free community tier, but its license cell in the ecosystem table is empty, so the README states no terms for it.

### how to install netdata on ubuntu

The visible text links to a Getting Started section but does not include the commands. What the repository provides is a netdata-installer.sh at the root, a netdata.spec.in RPM spec template, a packaging directory and a Dockerfile that invokes the same installer with --dont-wait --dont-start-it and --install-no-prefix /.

### how to access netdata dashboard

The Netdata UI is the dashboard component, described as free to use, included in standard packages, and available as the latest version via CDN. The file does not state a port or a local URL, and the alternative is Netdata Cloud, which adds user management and RBAC, which is where accounts come from.

### how to uninstall netdata

The visible text does not document an uninstall path. The only build and install mechanism named is netdata-installer.sh, which the Dockerfile runs with --install-no-prefix /, so removing an installation means dealing with whatever that script laid down rather than a documented removal command.

## Sources

- [Official documentation](https://www.netdata.cloud)
- [Official README](https://github.com/netdata/netdata#readme)
- [Project repository](https://github.com/netdata/netdata)
- [Release notes](https://github.com/netdata/netdata/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netdata-netdata