Goldilocks: VPA-backed resource request recommendations for Kubernetes workloads
Get your resource requests "Just Right"
At a glance
- What is it?
- FairwindsOps/goldilocks creates a VerticalPodAutoscaler for each workload in a namespace and reports the recommendations in a dashboard. It is a starting point for setting requests and limits, not an autoscaler that resizes pods.
- Who is it for?
- Adopt Goldilocks if you already run the Kubernetes vertical-pod-autoscaler in recommendation mode and want a read-only view of suggested requests per workload, on a cluster where you can install the VPA CRDs. Do not adopt it if you expect it to resize pods, if you cannot install VPA, or if you need multi-cluster history and Slack or Jira integration, which the README points at Fairwinds Insights for.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Goldilocks solves: nobody knows what to put in requests and limits
Resource requests in Kubernetes are a guess more often than a measurement. Set them too low and pods get evicted or throttled; set them too high and the scheduler reserves capacity that nothing uses. Goldilocks targets exactly that gap. The README describes it as "a utility that can help you identify a starting point for resource requests and limits", which is a deliberately modest claim: it produces a suggestion, not a decision.
The audience is platform and infrastructure engineers who run Kubernetes and already have the vertical-pod-autoscaler available. Goldilocks does not measure application behaviour itself. It leans on VPA's recommendation engine, which observes real usage over time, and turns those recommendations into something a human can read per workload. If your cluster has no VPA, Goldilocks has nothing to query.
How Goldilocks works: one VPA per workload, then a dashboard query
The mechanism is stated plainly in the README. Goldilocks uses the Kubernetes vertical-pod-autoscaler "in recommendation mode", which means VPA computes a suggestion for resource requests but does not act on it. Goldilocks then "creates a VPA for each workload in a namespace and then queries them for information".
That ordering matters. Goldilocks is a VPA object manager plus a read path. It writes VerticalPodAutoscaler resources into namespaces, waits for the VPA controller to populate status, and reads the recommendation back out for display. The recommendation quality is therefore bounded by how long VPA has been observing the workload and by VPA's own model, not by anything Goldilocks computes.
The repository layout supports this reading. The Go module depends on k8s.io/autoscaler/vertical-pod-autoscaler v1.7.1, alongside controller-runtime v0.24.1 and client-go v0.36.3, so Goldilocks talks to the API server through the standard controller-runtime stack and uses the upstream VPA API types rather than a private copy. cmd/, pkg/ and main.go hold the binary, and the Makefile builds a single Go binary named goldilocks. The Dockerfile runs that binary as user 65534 on Alpine with a CA bundle installed for TLS, so the shipped container carries no shell tooling and no root user.
Installing Goldilocks and reading your first recommendation
The README does not reproduce an install command; it points to the documentation at goldilocks.docs.fairwinds.com and to the releases page. What the README does specify is the image location, because of a registry migration. Starting with v4.15.0, images moved to us-docker.pkg.dev/fairwinds-ops/oss/goldilocks, and quay.io/fairwinds/goldilocks is deprecated. The README gives the replacement as a diff:
- quay.io/fairwinds/goldilocks:<tag>
+ us-docker.pkg.dev/fairwinds-ops/oss/goldilocks:<tag>The README also states that tags are now immutable and that floating tags such as v4, v4.14 and latest no longer exist. It gives two ways to reference the image, a full version tag or a digest pin:
us-docker.pkg.dev/fairwinds-ops/oss/goldilocks:v<major>.<minor>.<patch>
us-docker.pkg.dev/fairwinds-ops/oss/goldilocks@sha256:<digest>If you build from source rather than pulling, the Makefile defines the targets. Note that build-docker depends on build-linux, which cross-compiles for linux/amd64 before the image is assembled:
make build-dockerOnce Goldilocks is running against a cluster that has VPA in recommendation mode, the README says recommendations appear in the Goldilocks dashboard, and the screenshot in the repository shows that view. The practical first step is to point it at one non-production namespace and read the suggested requests there before changing any manifest. Because the VPA is created in recommendation mode, nothing is resized while you look.
Where Goldilocks is the wrong tool
Goldilocks does not resize anything. It creates VPAs in recommendation mode and reports what they suggest. If you want pods to actually be adjusted, you are looking for VPA in an acting mode, not for Goldilocks, and the README makes no claim otherwise.
The second boundary is the VPA dependency. Goldilocks requires the vertical-pod-autoscaler to be present, which means the VPA CRDs and controller must be installed in the cluster. On managed clusters where you cannot install cluster-scoped components, or where VPA is not offered, Goldilocks has no data source. The README does not document a fallback that computes recommendations without VPA.
The third is scope. The README states that Goldilocks creates a VPA for each workload in a namespace. On a cluster with many workloads, that is a VPA object per workload, and each one is a live custom resource the VPA controller has to reconcile. There is no statement in the README about an opt-out per workload, so treat namespace selection as the control you have.
Finally, the README is explicit that running Goldilocks across multiple clusters, tracking results over time, and integrating with Slack, Datadog and Jira are things to look at Fairwinds Insights for. Single-cluster, point-in-time reporting is what the open source project covers.
Goldilocks compared with running VPA directly
The obvious alternative is to install the vertical-pod-autoscaler yourself and read the recommendations with kubectl. That is a genuinely different workflow, not a lesser one. With VPA alone you author each VerticalPodAutoscaler manifest by hand, decide which workloads get one, and inspect the status field of each object to see the suggestion. You get the same underlying numbers, because Goldilocks is reading VPA's output either way.
The difference is who creates and enumerates the objects. Goldilocks creates a VPA per workload in a namespace and presents the results in one dashboard, which removes the per-workload manifest authoring and gives you a single view across a namespace. Direct VPA gives you finer control over the spec of each VPA and no extra component in the cluster. If you have a small number of workloads and you already know which ones need attention, the extra controller may not earn its place. If you have a namespace full of services and no idea where to start, the enumeration is the point.
Maintenance, releases and what the Apache-2.0 licence means in practice
The repository is not archived, and the last push was on 2026-09-18. Releases are frequent: v4.16.0 on 2026-08-13, v4.16.1 on 2026-08-14, and v4.16.2 on 2026-09-15. The project tracks current Kubernetes libraries, with k8s.io/api, k8s.io/apimachinery and k8s.io/client-go all at v0.36.3 in go.mod, and it declares go 1.27.1. That version cadence is the upgrade cost: expect to move with Kubernetes client library bumps, and expect the VPA dependency to move too.
The registry migration is the concrete upgrade hazard. Any manifest still referencing quay.io/fairwinds/goldilocks needs to be repointed at us-docker.pkg.dev/fairwinds-ops/oss/goldilocks, and any deployment relying on a floating tag such as latest or v4 will break, because the README states those tags no longer exist. Pinning by digest is the most stable option the README offers.
Goldilocks is licensed Apache-2.0, and the Dockerfile carries the matching org.opencontainers.image.licenses label. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that licence and notice files be preserved. This is a description of the licence text, not legal advice for your distribution.
Editorial conclusion
Adopt Goldilocks if you already run the Kubernetes vertical-pod-autoscaler in recommendation mode and want a read-only view of suggested requests per workload, on a cluster where you can install the VPA CRDs. Do not adopt it if you expect it to resize pods, if you cannot install VPA, or if you need multi-cluster history and Slack or Jira integration, which the README points at Fairwinds Insights for. Before rolling it out, verify which VPA version is installed against the k8s.io/autoscaler/vertical-pod-autoscaler v1.7.1 dependency in go.mod, and check that your image references use the us-docker.pkg.dev/fairwinds-ops/oss/goldilocks registry with a full version tag.
Frequently asked questions
What is FairwindsOps/goldilocks used for in Kubernetes?
It helps you find a starting point for resource requests and limits. It does this by creating a VerticalPodAutoscaler for each workload in a namespace and querying them, then showing the recommendations in a dashboard.
Does Goldilocks change my pods' resource requests automatically?
No. It uses the vertical-pod-autoscaler in recommendation mode, so the VPA produces a suggestion and Goldilocks reports it. Acting on the suggestion is a separate change you make yourself.
Which container image should I pull for Goldilocks?
Starting with v4.15.0, images moved to us-docker.pkg.dev/fairwinds-ops/oss/goldilocks, and quay.io/fairwinds/goldilocks is deprecated. Tags are immutable and floating tags such as v4, v4.14 and latest no longer exist, so use a full version tag or pin by digest.
Does Goldilocks work across multiple clusters?
The README points to Fairwinds Insights for running Goldilocks in multiple clusters, tracking results over time, and integrating with Slack, Datadog and Jira. The open source project itself is described in terms of per-namespace VPA creation and dashboard reporting.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/fairwindsops-goldilocks)