Forecastle: a launchpad for the applications running on your Kubernetes cluster

The problem: a cluster full of tools nobody can find

Forecastle states the problem in three bullets. Finding and accessing applications on Kubernetes is challenging without a central hub. It is essential to have a dynamic way to discover and list applications that are actively running on Kubernetes. And developers often need a streamlined portal to the tools they use daily, naming Jenkins, Nexus, Kibana and Grafana as examples.

That last list is the point. Those are not applications anyone deploys once and forgets; they are long-running internal services that teams depend on for building, storing artifacts and reading logs. In a cluster of any size, the information about where they live ends up scattered across deployment manifests, ingress definitions and the memories of whoever set them up.

The solution Forecastle offers is a single control panel that aggregates those applications and provides a launchpad into them. The README describes it as a unified control panel and a convenient gateway, whether the target is monitoring tools, CI/CD pipelines or something else.

The audience is therefore an operations or platform team that has already chosen Kubernetes and now has to make the cluster navigable for the developers working inside it. The project is written in Go, released under Apache-2.0, and its last push was on 2026-10-17 with version 2.0.2 published on 2026-07-01.

How applications are discovered

Discovery runs through Kubernetes resources rather than through a static list, which is what makes the panel reflect the cluster rather than a deployment manifest.

The primary mechanism is the namespace selector. Forecastle reads a ConfigMap that lists the namespaces it should monitor, and it aggregates the applications found in all of them into one view. The README describes the namespaceSelector as a fine grained selector combining hardcoded namespaces with label selectors, and its default value is any: true.

Within those namespaces, the panel discovers URLs from Kubernetes resources, and the README notes that Forecastle utilizes specific annotations on ingresses for this. That is the mechanism to know about, because an application whose ingress lacks the expected annotation does not appear in the panel even though it is running perfectly well.

Two escape hatches cover what automatic discovery cannot. Custom apps integration adds non-Kubernetes or external applications to the dashboard, so a hosted tool that has no ingress at all can still be linked. The ForecastleApp custom resource definition does the same thing in a Kubernetes-native way, letting you add custom applications dynamically and, according to the feature list, organise them into custom groups with specific URLs. Detailed application information is provided for each entry, giving developers the essentials at a glance.

Deploying with plain manifests

The admin guide offers two installation paths, and the manifest route is the one to start with because it shows exactly what gets applied to the cluster.

For a vanilla Kubernetes cluster, which the README lists as EKS, GKE, AKS and similar, one command applies the manifest:

kubectl apply -f https://github.com/stakater/Forecastle/releases/latest/download/forecastle-kubernetes.yaml

OpenShift gets its own manifest, which includes a Route for external access:

kubectl apply -f https://github.com/stakater/Forecastle/releases/latest/download/forecastle-openshift.yaml

Neither variant exposes the panel by itself. On Kubernetes you reach it through a port forward, and the README notes that you would need to configure ingress yourself to access Forecastle from outside the cluster, based on your cluster's ingress configuration:

kubectl port-forward svc/forecastle 8080:8080

On OpenShift a default route is created for the service, so the dashboard is reachable at the route URL, which you look up with:

oc get route forecastle

The second step of the manifest flow is to modify the namespaceSelector key in the ConfigMap so that Forecastle watches the namespaces you intend. Applying the manifest without doing this leaves the default in place.

Installing with Helm and configuring through values.yaml

The chart route is shorter, because the repository and the release are both handled by Helm:

helm repo add stakater-charts https://stakater.github.io/stakater-charts/
helm install forecastle stakater-charts/forecastle

The chart lives in the repository under deployments/kubernetes/chart/forecastle, and its values.yaml file is where the configuration options are found. The README is explicit that you can customise Forecastle with either a ConfigMap or the values.yaml file, depending on which installation route you took.

The configuration surface is small and the first field is the one that matters. namespaceSelector selects which namespaces are aggregated, and defaults to any: true. The header fields then control appearance, with headerBackground taking the background colour of the header in CSS notation and headerForeground the matching foreground colour, both defaulting to null.

That is the whole table in the README, and it tells you something about the design: Forecastle is deliberately thin. It does not have a rule engine, a refresh interval, a per-application override or an authentication section in the documented configuration. What it does have is a way to choose what to show and a way to restyle the header, on the assumption that the panel sits behind whatever ingress and authentication your platform already provides.

What the dashboard actually gives you

The feature list is long enough to be worth reading for the ones that are more than cosmetic.

Comprehensive app listing is the core: apps from all namespaces in the ConfigMap in one view. Search functionality lets a user locate a specific application without scrolling. Namespace grouping organises entries by the namespace they came from, which is what keeps a shared cluster navigable once the application count grows.

Then there are the display features. A customisable header lets you set the title and colour schemes. There is a light and dark theme with automatic system preference detection, so the panel matches the operating system rather than asking. Grid and list views give two ways of visualising the same applications, and detailed application information puts the essentials next to each entry.

Two of these have a design consequence worth naming. Automatic system preference detection means you cannot force a single theme for everyone without changing the panel's behaviour for all users, which is why the customisable header matters: it is the part of the appearance that can be set by whoever administers the deployment. And grid or list is a per-user preference by design, since it is a toggle in the interface rather than a configuration key.

Building the image and running the test suites

Forecastle ships a container image built as a three-stage Dockerfile, and the stages are worth reading because they explain the shape of the project.

FROM --platform=${BUILDPLATFORM} golang:1.26 AS builder

ARG TARGETOS
ARG TARGETARCH

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

COPY --from=frontend-builder /app/frontend/build ./internal/web/build/

RUN CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} \
    go build -ldflags="-s -w" -o /forecastle ./cmd/forecastle

The first stage builds the frontend with node and yarn, and its output is copied into internal/web/build before the Go build, which is how the compiled UI ends up embedded in the binary. The Go build itself is cross-compiled with CGO disabled and the architecture passed as build arguments, and the final stage is a distroless static image running as the nonroot user with the binary as the entry point.

The Makefile mirrors that structure with separate build-frontend and build-go targets, a docker-build target that uses buildx, and release-all that loops over arm64, arm and amd64 before pushing a multi-architecture manifest for the stakater/forecastle image.

The test targets separate concerns. The unit test target runs the Go tests over the cmd, internal and pkg trees with a 30 minute timeout, while the end-to-end target runs the e2e package against a running instance, and the Makefile comments record its requirements: kubectl access to a cluster and a FORECASTLE_URL environment variable, defaulting to http://localhost:3000.

Where Forecastle is the wrong tool

The first limitation is the default configuration. With namespaceSelector set to any: true, Forecastle aggregates applications from every namespace in the cluster, and what it displays includes the URLs of internal tools. A panel that lists every ingress in a cluster is a map of your internal estate, and on a cluster where that map is sensitive the default is the wrong starting point. Narrowing the selector is not optional hardening, it is the first configuration step.

The second limitation is scope. Forecastle lists applications and links to them. It does not report whether those applications are healthy, and the feature list has nothing about status, latency or error rates. A team looking for one page that tells them what is broken will not find it here, and would need a monitoring system for that, with Forecastle alongside rather than instead.

The third is the dependency on ingress annotations. Discovery leans on specific annotations on ingress objects, so the panel only shows what has opted in. An application deployed with a plain Ingress and no annotations is invisible, and an application exposed through something other than an Ingress, such as a NodePort service, is not what this mechanism is looking for. The ForecastleApp custom resource and custom apps cover those cases one by one, which is more work than a single ingress annotation would be.

The fourth is multi-cluster. The project supports multiple instances of Forecastle, and the configuration is per instance, so one panel covers one cluster's namespaces. There is no documented federation across clusters, which means a platform team running several clusters gets one dashboard per cluster rather than one list of everything.

Maintenance, project layout and licence

The repository is organised into cmd for the entry point, internal for the application internals including the embedded web assets, pkg for the reusable packages, frontend for the TypeScript frontend, deployments for the manifests and the Helm chart, e2e for the end-to-end tests and docs for the documentation.

The Go module is github.com/stakater/Forecastle/v1 and requires Go 1.25. The dependencies explain the scope: the Kubernetes client libraries at version 0.35.3, the OpenShift API and client-go, Traefik v2 and the Gateway API for ingress handling, Viper for configuration, Logrus for logging and the xurls library for URL validation. A separate .goreleaser.yml and a renovate.json indicate that releases and dependency updates are automated rather than manual.

The release history shows a deliberate move to a 2.x line: v2.0.0 in January 2026, v2.0.1 in March and v2.0.2 in July. The repository is not archived and the last push was on 2026-10-17.

The licence is Apache-2.0, with a LICENSE file at the root of the repository. That is a permissive licence including an express patent grant, with the usual requirement that notices are preserved, which suits a component that teams are likely to run as-is inside their own clusters. This is a description of the terms rather than legal advice.

Editorial conclusion

Adopt Forecastle if your cluster has grown past the point where people can remember which tool lives at which internal hostname, and you want one addressable page that lists what is deployed and where it is reachable. Do not adopt it as a monitoring or health dashboard, since it lists links rather than status, and do not deploy it with the default namespace selector on a cluster where exposing internal application URLs is a concern. Verify first that the namespaceSelector in the ConfigMap is narrowed to what you intend to publish, that the ingress annotations the discovery relies on are present on the applications you expect to see, and that your cluster's ingress is configured, because the panel is only reachable through it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. stakater/Forecastle on GitHub