Stakater Forecastle: Automated Service dashboard for Kubernetes

In an environment where we have multiple tools and applications including micro-frontends, it may get a little tedious to keep track of the URLs of all of the services. It can get additionally confusing if there are multiple instances of the same tools deployed on different environments or kubernetes namespaces. Keeping track of these URLs and sharing them within a team or other group of consumers can become tiresome. We would like to have a central place where we can easily look for and access our applications running on Kubernetes. We would also like to have our apps on kubernetes to be dynamically discovered. For an easier way to manage this, the Stakater team has developed a Kubernetes controller, Forecastle.

Forecastle is a Kubernetes controller and a web dashboard. It watches Ingresses and looks for specific annotations on them to indicate whether the Ingress needs to be registered on the dashboard or not. If the relevant configuration is discovered in the annotations of the ingress, the Ingress URL is added to the Forecastle dashboard. The dashboard displays all the running applications that are registered with it, and provides a simple way to access them.

Following is an example of the Forecastle dashboard. The applications are automatically separated into sections based on the kubernetes namespace.

The dashboard page also has a search bar which can be used to filter the application list to find a particular application without having to scroll through the whole list.

How it works


Forecastle watches for specific annotations on ingresses. To make an app/ingress be discoverable and added to the Forecastle dashboard, the annotation with true value should be added to the ingress. There are other annotations which can be optionally used to customize how the application is displayed in the dashboard, but without the expose annotation mentioned they will be ignored.

With we can specify the URL of an image that should be used for the application button on the dashboard. can be used to specify a custom display name for the application on the dashboard. If this annotation isn’t specified, the name of the ingress is used by default.

A group/section name can be specified using This is the section on the dashboard page under which the application will be listed. If the annotation is not used, the application will be displayed under the section titled after its namespace by default.

When an Ingress with the required annotations is created in the cluster, the ingress is added to the Forecastle dashboard. Likewise when the ingress is removed from the cluster, it’s link button is removed from the dashboard.


While the Forecastle dashboard does not have a login mechanism built-in or support yet for integration with OAuth providers, etc., at Stakater we do use Keycloak single sign-on with Keycloak gatekeeper to protect the Forecastle dashboard. Keycloak gatekeeper redirects any unauthenticated requests to the Keycloak server, and once an authenticated session is established it forwards the requests to the target Forecastle container.

It is therefore recommended to use some external authentication mechanism to protect access to the Forecastle dashboard.

Running multiple instances

If needed, we can run multiple instances of forecastle by deploying multiple instances and configure the specific list of namespaces that Forecastle should watch for ingresses. The list of namespaces to watch is configured in the ConfigMap of the deployment.

config.yaml: |-
- qa-1
- qa-2

We can also have multiple Forecastle instances work within the same namespace and watch ingresses in the same namespace, but have applications register to only a selected number of the dashboards based on the instance name of the Forecastle deployment. The instanceName parameter is configured in the Forecastle deployment ConfigMap as follows:

config.yaml: |-
instanceName: dev-forecastle

On the Ingress, this configuration will be specified using the annotation. The annotation value can be a comma separated list of the forecastle instances where we want to register the ingress. This way we can have the application display on a single or multiple dashboards based on the value we specify in the instance annotation.

Having multiple instances of Forecastle can be useful from an authorization point-of-view. For example if we want dev team members to only have access to applications deployed for the dev team, they can have authorization to use the relevant Forecastle dashboard only. Similarly the QA team can have access to only a QA relevant Forecastle dashboard. And it’s possible there may be some tools for which we are using a single instance across different environments, e.g. if we have a single instance of Jenkins working for both the dev and qa environments. In such a case we can have Jenkins be displayed on both instances of Forecastle dashboard.