The whole cluster at a glance
Health as a single ratio, the problems happening right now beside it, then workload, storage and networking summaries.
Kubernetes, Docker and your servers in one console.
Installs and manages Kubernetes. Manages Docker. Monitors the servers underneath. Tells your team when something goes wrong.
One product, one install: every team can monitor and manage its own applications.
Kubernetes
// install · manage
prod-cluster12 pods
staging6 pods
edge-eu3 pods
Docker & servers
// manage · monitor
web-01cpu 24%docker
db-01cpu 12%
Uptime
// 8 checks
api.example182 ms
app.example94 ms
auth.example210 ms
▼ observe
DFZ
operations console
▼ route
Slack
Teams
Email
Telegram
158
screens across six application areas
170
audit rules, each with a remediation note
7
notification channel types
3
operating systems monitored, agentless
// In action
The product itself, from a running system.
Real screens from a running cluster. Switch the theme in the header — the screenshots follow.
Everything a workload is attached to
Open a deployment: its ConfigMap, Secret, volume claim, disruption budget, services and network policies in one diagram — with risk findings, revisions and event history beside it.
Six hours of processor and memory
Open a pod: processor and memory over the range you pick, with average and peak. Under the chart sit metadata, conditions, event history, containers and volumes.
Findings, ranked
Every rule that fired, scored and sorted, with the namespace, the object and what to do about it.
Reserved and unused
Requested CPU and memory against what is actually consumed, per workload — the list that has a line on your bill.
Which part talks to which
A live map of service-to-service calls with request rate and latency on every edge; failing paths are drawn in red.
Rules you fill in, not code you write
Pick a resource type, a metric, a threshold and a severity, then choose the channels. Ready-made rules ship switched off.
Servers without Kubernetes
Container state, image, ports, CPU and memory, uptime — and a terminal into the container without leaving the page.
Every server in one list
Which server is up, which one stopped answering, which one is under pressure — Windows, Linux and macOS, agentless.
Is it answering, and how fast?
HTTP, TCP, ping, DNS and keyword checks, with response-time history and a record of every check. A failing check enters the same alert lifecycle.
A new cluster, in five steps
Distribution method, node selection, configuration, preflight and confirm. Air-gapped installs run from prepared artifacts and your own registry, with no internet at any step.
Connect once, it stays connected
Kubernetes contexts, servers, Git repositories and credentials in one place. Each profile carries its agent state and version, so you can see what is reachable before you need it.
Ask instead of hunting
The assistant answers from the live data of the page you are on, using the AI provider and key you configured.
// Features
The whole operation, on a single platform.
Not a Kubernetes admin panel — an operations console for mixed infrastructure.
One terminal, every pod's logs
Stream logs from every pod under a workload in a single terminal. Per-pod colour coding, search across pods, container selection, pause and resume, live stream statistics.
Alert rules and seven notification channels
Build rules for Kubernetes, Docker, servers and uptime checks with a form — no query language. Route them to email, Slack, Microsoft Teams, Discord, Telegram, a generic webhook, or any chat tool that accepts an incoming webhook. Active alerts, history, silences and announcements sit in one place.
An assistant that reads your own systems
Ask about the page you are on. The assistant reads live cluster, pod, event, log and alert data — with your permissions and read-only. The model comes from the provider you choose, on your own key, so nothing is sent to us. Deep investigations and scheduled reports live in the same layer.
Risk, waste and incident analysis
170 audit rules score findings by severity and write a remediation note next to each one. Waste detection lists workloads holding more CPU and memory than they use. Pod incident history keeps OOMKilled, CrashLoop and Evicted events after the pod is gone.
Service traffic, drawn
See which service calls which, at what request rate and latency, with failing paths highlighted. Full Istio management sits behind it — gateways, virtual services, authorization policies and a configuration analyser.
Servers and the addresses they serve
CPU, memory, disk, network and process metrics from Windows, Linux and macOS servers — physical or virtual, without installing an agent. Alongside them, HTTP and HTTPS uptime checks with response time and TLS certificate expiry — wired into the same alert lifecycle.
GitOps, Helm and cluster installs
Dashboards for ArgoCD applications and FluxCD reconciliation. A Helm catalogue with Artifact Hub discovery, air-gapped installs, smart upgrade and rollback. Multi-node RKE2 installs over SSH, online or fully offline.
Connect once, manage everything
Kubernetes contexts, SSH hosts, Git repositories and credentials in a single hub. Credentials are encrypted at rest and never rendered back to the screen. Role-based access decides who sees which page.
// Coverage
Whatever is in your infrastructure, it is covered.
Operations first, then the cluster and server categories underneath.
Multi-pod logs
Alert lifecycle · 7 channels
AI assistant · your own key
Investigations · scheduled reports
Risk audit · 170 rules
Waste detection
Pod incident history
Cluster topology
Service mesh · Istio
Traffic graph · latency
Uptime checks · certificate expiry
Server monitoring · agentless
Windows · Linux · macOS
RKE2 installer
Air-gapped install · offline bundle
Helm catalogue · Artifact Hub
GitOps · ArgoCD · FluxCD
Compose launcher · Git
Multi-cluster contexts
Workloads · networking · storage
RBAC · SSO · admission webhooks
Autoscaling · HPA · VPA · KEDA
cert-manager · MetalLB · Velero
Docker · Compose · registries
// Install
Up in under a minute.
One command pulls the images and starts the stack.
~/projects
# Clone and bring the stack up
$ git clone https://github.com/devopsfromzero/dfz.git
$ cd dfz
$ docker compose pull
$ docker compose up -d
✓ dfz-postgres healthy
✓ dfz-redis healthy
✓ dfz-backend healthy on :8000
✓ dfz-terminal healthy on :8001
✓ dfz-ui ready on :3080
# Open the dashboard — create your account on first run
$ open http://localhost:3080
Note: backend feature flags and pool sizes are overridden inside
docker-compose.yml — there is no separate .env file.
// Air-gapped
No internet? It still installs.
Images, stack and installer in one tarball. Download once, carry it in, run one script.
air-gapped host
# Nothing is downloaded during installation
$ curl -LO https://github.com/devopsfromzero/dfz/releases/latest/download/dfz-offline-amd64.tar.gz
$ curl -LO https://github.com/devopsfromzero/dfz/releases/latest/download/dfz-offline-amd64.tar.gz.sha256
$ sha256sum -c dfz-offline-amd64.tar.gz.sha256
$ tar xzf dfz-offline-amd64.tar.gz && cd dfz-offline-amd64
$ cp config.env.example config.env
$ ./install.sh
✓ images loaded
✓ mirrored to your registry
✓ dfz-ui ready on :3080
Two modes: point
Upgrades use the same command. It shows what will change, backs the database up first, then verifies that what is running is what you installed —
config.env at your own private registry and the installer mirrors everything to it — or run ./install.sh --no-registry straight off the loaded images. Every release ships amd64 and arm64 bundles.
Upgrades use the same command. It shows what will change, backs the database up first, then verifies that what is running is what you installed —
--rollback takes you back to the previous version.
// Questions
Common questions, answered plainly.
Is DFZ open source?
No. DFZ is a product you install on your own servers; the source is not published. The container images are hosted on ghcr.io and free to pull.
Does it install Kubernetes, Docker and servers?
It installs Kubernetes. The RKE2 installer builds a multi-node cluster over SSH, online or fully offline.
Docker and servers are connected, not installed. Docker is then managed — containers, images, networks, logs, terminal. Servers are monitored: processor, memory, disk, network and reachability. Monitoring runs through the operating system, so whether a server is physical or virtual makes no difference.
Does it need internet access?
No. An offline bundle carries the images, the stack and the installer in a single tarball. Nothing is downloaded during installation, so DFZ runs in networks with no route out.
Does our data leave the network?
No. DFZ runs on your server and keeps logs, metrics and credentials there. Credentials are encrypted at rest and are never rendered back to the screen. Role-based access decides who can see which page.
Which AI provider does the assistant use?
Yours. You add the provider and the API key, and you can switch between them. The assistant reads live system data with your permissions, read-only, and the product tells you plainly that its answers should be verified before you act on them.
What does it need to run?
A host with Docker Compose. Images are published for amd64 and arm64. The stack is Postgres, Redis, the backend, a terminal service and the interface; you reach it on port 3080.
Try it.
Container images are free on ghcr.io. Read the docs, open an issue.