See what's idle first
A team that works 10 hours a day, five days a week, uses staging 50 of 168 hours. That leaves 118 hours, 70% of the week, idle. kubectl napwake scan shows what's idle in your cluster now, and what it costs.
brew install napwake/tap/kubectl-napwake
kubectl napwake scan
It only reads, with your kubeconfig, and installs nothing in the cluster. It never reads Secrets, and its report stays on your machine.
Install
You need Kubernetes 1.30 or later, Helm 3.8 or later, and metrics-server. GKE and AKS run metrics-server already. On EKS, kind and minikube, add it first.
Change Europe/London to your users' time zone. It defaults to UTC, which puts the forecast an hour off their mornings for a while after each daylight-saving change.
printf '\ntimezone: Europe/London\n' >> napwake-values.yaml
helm install napwake oci://ghcr.io/napwake/charts/napwake --version 0.2.0 \
--namespace napwake-system --create-namespace -f napwake-values.yaml
kubectl get pods -n napwake-system
The chart installs the operator and the doorman, as the Deployments napwake and napwake-doorman, and the ManagedWorkload CRD. Keep the values file, and upgrade with it (Keeping your settings).
Installation also has install.yaml, Kustomize, Argo CD and Flux.
With krew:
kubectl krew install --manifest-url \
https://github.com/napwake/napwake/releases/download/v0.2.0/krew-napwake.yaml
Or download it for Linux, macOS or Windows.
From 0.2.0-rc.9, helm upgrade works in place. From 0.1.x or 0.2.0-rc.1 to rc.7, uninstall, then install fresh, as Moving to Napwake says.
Your first pause
Opt one workload in, in dry-run. Napwake measures it and pauses nothing.
kubectl annotate deployment my-api -n staging napwake.dev/dry-run=true
kubectl label deployment my-api -n staging napwake.dev/managed=true
kubectl napwake status -n staging
The annotation goes first, so it starts in dry-run. status shows its state as running (dry-run), with its last activity and when it would pause. When you trust what it measured, end dry-run:
kubectl napwake enable my-api -n staging
After idleAfter with no activity, an hour by default, Napwake pauses my-api. Its replicas go to zero. The next request to its Service wakes it. So does kubectl napwake wake my-api -n staging, which waits until it's Running.
If Argo CD or Flux applies the workload, first have it leave the replicas to Napwake. Otherwise it undoes every pause. The Quickstart runs the whole loop on a sample app.
On a bad day, pausing.enabled: false stops every pause at once and wakes what's paused (Stop all pausing now).
How it works
- You label a Deployment, StatefulSet or namespace
napwake.dev/managed=true.
- Napwake keeps an activity clock for each workload. CPU above
cpuThreshold (10% of the pods' CPU request by default) resets it. So do deploys, activity annotations from your tools, and Prometheus queries you give it.
- After
idleAfter with no activity, Napwake pauses the workload. Its replicas go to zero, and its Services and PVCs stay.
- While it's paused, the doorman holds the first connection until a pod is Ready. That works for any TCP, such as HTTP, gRPC, Postgres and Redis. Your Ingress doesn't change.
- A forecast learns each workload's daily and weekly pattern. Once confident, it holds off pauses in hours it expects to be busy. With
autoResume, it also wakes the workload 15 minutes before them.
Behind a VPN, SSO or an allowlist, the first request wakes a paused workload. Public ones can ask first, with napwake.dev/wake: ask. A browser then gets a Wake it button, and crawlers, scanners and API calls wake nothing (Public preview environments).
On GKE, behind an Ingress or Gateway that uses container-native load balancing (NEGs), set doorman.negForwarder.enabled. Without it, the load balancer answers 502 and the request wakes nothing (Wake on request).
What it won't do
- Delete anything. A pause sets replicas to zero, and a wake restores them. What lives only in the pods, such as an
emptyDir or memory, goes with them.
- Pause on a timetable. It pauses on idleness.
- Pause anything but Deployments and StatefulSets.
- Replace your autoscaler. While a workload runs, its HPA or KEDA ScaledObject sets the replicas.
It's for non-production. Pausing frees the CPU and memory a workload requested. That's money once your node autoscaler removes nodes, so Napwake reports freed and saved apart.
Napwake can't see requests to an awake workload. One in steady light use, under its cpuThreshold, can look idle and be paused while people use it. The next request wakes it, with a cold start. To stop that, give Napwake a Prometheus query for its traffic, such as your ingress's request rate. Then every request keeps it awake.
- The operator and the doorman talk to the API server. The operator talks to Prometheus only if you set one.
- Nothing leaves the cluster.
- It never reads your Secrets. The doorman reads one of its own, by name, the key it signs the Wake it button with.
- With
watchNamespaces, the operator and the doorman get a Role in each listed namespace in place of a ClusterRole. What stays cluster-wide only reads namespaces, nodes and Karpenter NodePools.
- Kubernetes' and platforms' own namespaces (
kube-*, openshift-*, cattle-*, gke-*, gmp-*), and a namespace labelled napwake.dev/protected=true, are never managed, unless also labelled napwake.dev/allow-protected=true.
- It writes only a workload's replicas, through the scale subresource, its
napwake.dev/paused-from annotation, and its own ManagedWorkloads and EndpointSlices.
Security and Data and access have the exact RBAC, and how to verify a release.
Docs
The full docs are at docs.napwake.dev. Start here:
| Command | What it does | Needs the operator |
|---|
scan | Shows what's idle, what it costs, and what pausing could free | No |
nodes | Shows why what pausing frees isn't coming off the bill | No |
forecast | Replays the forecast over your Prometheus history, before you turn on autoResume | No, but it needs Prometheus history |
status | Shows what Napwake is doing with each workload it manages | Yes |
enable | Ends dry-run for a workload or namespace | Yes |
pause | Pauses a workload now, to wake on its next request | Yes |
wake | Wakes a paused workload and waits until it's Running | Yes |
deps | Shows what Napwake wakes and holds awake with a workload, and what depends on it | Yes |
version | Prints the plugin's version | No |
Every flag is in the kubectl plugin reference.
How it's built
Napwake is at 0.2.0. Its API is napwake.dev/v1alpha1, which may change before 1.0. It has no telemetry, usage reporting or update checks.
Code lands through pull requests. Each one runs the unit tests, and end-to-end tests on kind with Kubernetes 1.30 and 1.37. Napwake is also tested by hand on GKE Standard. EKS, AKS and GKE Autopilot aren't tested yet.
Each release signs its image, chart and checksums with Sigstore, keylessly. It carries an SPDX SBOM for each platform, and GitHub build provenance. Then the install smoke test installs it as the docs say, with Homebrew and krew on clean macOS and Ubuntu, and with Helm and install.yaml on a new kind cluster, and checks its signatures.
Help and contributing
Licence
Copyright 2026 The Napwake Authors. Licensed under the Apache License, Version 2.0.
