Cluster Portal
The Cluster Portal is a web application that runs on your own cluster. It lets you change your cluster definition through a form instead of editing YAML by hand, and it shows what the platform does for you: what runs on the cluster, the platform updates you received, the alerts that fired and how your issues and pull requests moved.
The portal never changes your cluster directly. Every change becomes a pull request on your infrastructure repository, which your team and Skyscrapers review and merge like any other.
Request the portal
The portal is an opt-in capability, enabled per cluster by Skyscrapers. To get it, ask your Customer Lead or open a GitHub issue. Tell us:
- which cluster should run it (usually production);
- which groups of your identity provider may use it, if not everyone who can log in to Grafana.
We install a dedicated GitHub App on your infrastructure repository, with access to that repository only, and enable the portal on the cluster.
Open the portal
The portal is available at https://portal.<cluster_fqdn>, for example https://portal.production.eks.example.com. Like Grafana, Prometheus and Alertmanager, it is only reachable through your VPN.
You log in with the same single sign-on as Grafana (your own identity provider, through DEX). If you are already logged in to Grafana, the portal opens without asking again. The portal uses the email address of your login to name you on the pull requests you create.
Each portal shows one cluster: the one it runs on. If your repository holds several clusters, each cluster with the portal enabled has its own address.
Change your cluster definition
- Open Clusters and select your cluster. The editor opens on an overview of all settings, grouped by block (networking, ingress, observability, and so on). The switches turn a component on or off directly.
- Select a block to open its form. Every field carries the description from the schema, and the Reference page lists every property with its type and allowed values.
- Fix the values the form marks as invalid. The portal validates against the same schema as the check that runs on your pull requests, so a change the portal accepts also passes that check.
- Select Review changes to see the exact diff of the file.
- Select Create change. The portal opens a pull request on your repository, from a
cluster-portal/<timestamp>branch, labelledcluster-portal, naming you as the requester.
The portal changes only the lines you edited: comments, ordering and formatting in the rest of the file stay as they are.
Review the pull request like any change to a cluster definition: merging it rolls the cluster out. The portal never merges anything.
If someone changed the file after you opened it, the portal refuses to create the change and asks you to reload the file, so nobody’s work is overwritten. Your edits in progress are kept if your login expires while you work.
What you cannot change in the portal
Some parts of the definition are shown read-only, or not at all. The portal refuses to change them whatever the browser sends.
| Setting | Why |
|---|---|
customerName, sla, forceDestroy | Part of your agreement with Skyscrapers. |
kubernetesVersion | Kubernetes upgrades are planned and rolled out by Skyscrapers. |
aws and nodes.systemPool | Set when the cluster is created; they hold the platform itself together. |
Encrypted values (fields ending in Payload) | They are encrypted with KMS. The portal never handles plaintext secrets, so it cannot create them. |
metadata and internal Skyscrapers overrides | They identify the file or are managed by Skyscrapers; the editor does not show them. |
To change any of these, open a GitHub issue or a pull request on your repository, as you do today.
See what the platform does for you
Besides the editor, the portal has pages that show the work behind your platform:
- Overview: what runs on the cluster, the platform version, the latest changelog entries and a usage dashboard from Grafana.
- Impact: the platform updates your cluster received, the issues and pull requests handled on your repository, and the alerts that fired on your cluster, including those that paged the Skyscrapers on-call engineer. Every number links to where it comes from (GitHub, Prometheus), so you can check it.