Infrastructure

What this screen is for

Infrastructure is where Fenwave learns about the world it deploys into: cloud accounts, Kubernetes clusters, the environments running on those clusters, and object storage.

This area comes first on a new install. Deployments, pipelines, CI/CD integrations, addons and environment-scoped permission policies all reference things registered here, and none of them can be configured against something that does not exist yet.

Before you start

Tab Read Change
Cloud platform-settings.cloud.read .cloud.create .update .delete .validate
Clusters platform-settings.cluster.read .cluster.create .update .delete .validate
Environments platform-settings.environment.read .environment.create .update .delete
Object Storage platform-settings.storage.read .storage.create .update .delete

Note the validate permissions on Cloud and Clusters. Validation is a separate action from editing, and it is the only thing that proves a credential works.

Opening it

  1. Settings in the sidebar.
  2. Infrastructure.

Direct URL: /platform-settings/infrastructure

The interface

📸 Screenshot Placeholder: The Infrastructure page. Mark: (1) the tab bar showing Cloud, Clusters, Environments, Object Storage, Addons, (2) the table, (3) the status column, (4) the validate action.

# Control What it does When you’d use it
1 Tab bar Cloud · Clusters · Environments · Object Storage · Addons Switching between infrastructure registries
2 Table The entries for the selected tab Reviewing what is registered
3 Status column Whether the entry’s credentials are Valid, Invalid, or Pending Triage
4 Validate Re-tests the stored credentials now After any credential change

The Addons tab has moved

The fifth tab shows only a notice. Cluster addons are now managed under Development › Addons.

Walkthroughs

Register things in this order — each step depends on the one before it:

  1. Cloud — the cloud account.
  2. Clusters — the Kubernetes clusters, which may authenticate using the cloud credential from step 1.
  3. Environments — dev, staging and production on those clusters.
  4. Object Storage — S3 or GCS buckets.

Scenario

Register a first Kubernetes cluster and validate it end to end.

  1. Cloud — add the AWS or GCP account. Validate it. If this fails, stop here: a cluster that authenticates through this credential cannot succeed while the credential does not.
  2. Clusters — add the cluster and choose an authentication method. On EKS, prefer IRSA or Pod Identity over a static service account token: they carry no long-lived secret to rotate.
  3. Validate the cluster. Watch the status reach Valid — not Pending, and certainly not Invalid.
  4. Environments — create the environments on that cluster. Until they exist, no policy can be scoped to them.
  5. Go to People & Access › Policies and check that the new cluster and environments now appear in the scope selectors. If they do not, something in steps 1–4 did not complete.
  6. Only now connect CI/CD, which needs the cluster to exist.

Steps 3 and 5 are the ones people skip. A cluster left at Pending looks registered in the table and fails at the first deployment.

When it doesn’t work

Symptom Cause How to check Fix
A cluster is not offered anywhere else in Fenwave It is registered but not Valid The status column Validate it and resolve the error
Environments cannot be created No cluster registered yet The Clusters tab Register and validate a cluster first
A cluster or environment is missing from a policy’s scope selector It is not registered, or not valid This page Register and validate it, then edit the policy
The Addons tab shows only a message Addons moved to Development Use Development › Addons
A cluster you use is entirely absent Clusters come from this registry, not from app-config This page Register it here

Clusters come from this registry

Fenwave reads clusters from the platform-settings registry. Static configuration is consulted only when this registry is empty. A cluster that is “missing” is nearly always unregistered rather than misconfigured.

Next