Install via Helm

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update

# Minimal: assumes Prometheus is already in the cluster (kube-prometheus-stack, etc.)
helm install opencost opencost/opencost \
    --namespace opencost --create-namespace \
    --set opencost.prometheus.internal.namespaceName=monitoring \
    --set opencost.prometheus.internal.serviceName=prometheus-server \
    --set opencost.exporter.cloudProviderApiKey=<optional-api-key>

For AWS, OpenCost pulls actual on-demand / spot / RI pricing from the AWS pricing API; for GCP / Azure, similar. For on-prem, configure a custom price book (below).

Required: Prometheus with kube-state-metrics + node-exporter

OpenCost relies on standard Prometheus metrics:

  • kube-state-metrics — pod / deployment / namespace metadata
  • node-exporter — node hardware metrics
  • cAdvisor (via kubelet) — per-container resource usage

If you used the kube-prometheus-stack Helm chart (see Prometheus tutorial), all three are already installed.

The web UI

kubectl -n opencost port-forward svc/opencost 9090
# Open http://localhost:9090

The UI shows:

  • Allocation — cost by namespace, by deployment, by label, by pod over selectable time windows.
  • Assets — cluster-level cost: nodes, persistent volumes, network out, plus idle (unused) capacity.
  • Cloud Costs — broken-out per-service (EC2, EBS, ELB, S3, etc.) from cloud billing data.
  • Reports — saved queries for finance / per-team breakdowns.

How OpenCost computes per-pod cost

The trick: nodes have known $/hour, plus per-pod request/usage data. OpenCost allocates the node's cost across pods proportionally to their resource consumption:

pod_cost = pod_cpu_share * node_cpu_cost
         + pod_memory_share * node_memory_cost
         + pod_storage_use * volume_cost
         + pod_network_egress * egress_cost

"Pod cpu share" defaults to max(request, usage) — charges for what the pod reserved or used, whichever is higher. This catches both "over-requested + underused" (waste) and "underrequested + bursts" (noisy neighbor).

On-prem pricing (no cloud provider)

Configure a custom price book in the Helm values:

opencost:
  customPricing:
    enabled: true
    configmapName: pricing-configs
    configPath: /tmp/configs

    provider: custom
    description: "Self-managed on-prem cluster"

    # Per resource-unit pricing in USD
    CPU: 0.024                # $/CPU/hour
    RAM: 0.003                # $/GiB/hour
    GPU: 0.95                 # $/GPU/hour (e.g. an L40S)
    Storage: 0.000027         # $/GB/hour
    InternetNetworkEgress: 0.05
    RegionNetworkEgress: 0.01
    ZoneNetworkEgress: 0.005

Derive your numbers from electricity + amortized hardware + cooling. For a homelab, you might charge yourself an order of magnitude less than a cloud equivalent — OpenCost just needs some price to allocate.

Prometheus metrics

OpenCost exposes its own metrics at /metrics:

# Per-namespace daily cost
sum by (namespace)(opencost_pod_total_cost{}[1d])

# Per-deployment cost over the last 7 days
sum by (namespace, deployment)(opencost_workload_total_cost{}[7d])

# Idle / wasted capacity
sum(opencost_node_idle_cost{}[1d])

Wire to Grafana dashboards alongside the rest of your Prometheus data. OpenCost's GitHub repo has importable dashboards.

API access

# Cost allocation for "default" namespace, last 7 days
curl 'http://<opencost>:9003/allocation?window=7d&aggregate=namespace' | jq .

# By label (e.g. tier=production)
curl 'http://<opencost>:9003/allocation?window=7d&aggregate=label:tier&filterLabels=tier:production' | jq .

# Asset (nodes + PVs)
curl 'http://<opencost>:9003/assets?window=7d' | jq .

For finance integration, schedule a daily script that pulls + posts to a billing system or Slack.

Per-team chargeback

The killer feature once your cluster has many teams. Label every workload with team: <name>:

# Argo CD ApplicationSet or Helm chart default
metadata:
  labels:
    team: payments
    cost-center: cc-1234

Then OpenCost groups by team — finance can see "payments team consumed $12,500 of cluster cost this month." Combined with monthly reports, the chargeback story works.

Right-sizing recommendations

OpenCost surfaces over-requested pods (requested more CPU/RAM than used):

curl 'http://<opencost>:9003/savings/requestSizing?window=7d' | jq .

Returns per-deployment recommendations: "this deployment requests 4 CPUs but P95 usage is 0.6; right-size to 1 CPU saves $XX/month." Useful for reducing waste.

OpenCost vs Kubecost

Kubecost is the commercial fork (same company, Stackwatch). OpenCost has the core cost engine; Kubecost adds enterprise features (multi-cluster aggregation, longer retention, advanced alerts, SAML SSO, governance). For homelab / single-cluster cost visibility, OpenCost alone is fine; for multi-cluster enterprise FinOps, Kubecost.

What OpenCost isn't

  • Not a billing tool. It estimates cost based on pricing data; the cloud's invoice is the source of truth.
  • Not a forecast tool. Shows historical + current; for "what will next month cost?", combine with growth-trend analysis externally.
  • Not workload-specific optimization. It surfaces waste but doesn't automatically rightsize; pair with Vertical Pod Autoscaler or manual right-sizing.

For "I want to know what my Kubernetes cluster actually costs and who's responsible for each dollar," OpenCost is the canonical tool in 2026.