Installation on StormForge Documentation

Basic installation

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites

A Kubernetes cluster (from any Kubernetes distribution, such as EKS, AKS, GKE, minikube, or kind)
A StormForge account — sign up for free at app.stormforge.io/signup
In an enterprise environment, make sure a system administrator has addressed additional prerequisites (such as firewall rules and proxies)

Install StormForge

Log in to app.stormforge.io.

If you are setting up StormForge for the first time, you will be automatically taken to the Add Cluster page — continue to step 3.

Advanced installation

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites

A StormForge Account
Kubernetes version 1.24 or later
helm version 3.14.0 or later
kubectl configured with access to your cluster
cluster-admin access (for installation only)
A Kubernetes cluster and a name to identify it in StormForge.
The name cannot exceed 63 characters, cannot start or end with a dash (-), and must follow the RFC 1123 DNS label standard.
Configure a proxy, if needed
If you use a private container registry, import the required containers
Configure firewall rules, including granting Kubernetes clusters access to these StormForge service endpoints on port 443:
- api.stormforge.io
- in.stormforge.io
- registry.stormforge.io*
  (*If you configure the Agent to use an internal registry, you don’t need to grant cluster access to this endpoint)

Set up the StormForge CLI

The StormForge CLI is used to authenticate, retrieve credentials, and register StormForge on your Kubernetes cluster.

Agent configuration

Mon, 01 Jan 0001 00:00:00 +0000

This topic describes the additional parameters available for configuring the StormForge Agent, as well as shared top-level parameters that apply to all StormForge components. For parameters that apply to the StormForge Applier, see the Applier configuration topic.

Agent parameters:

Third-party secret management

Controls whether the StormForge Agent creates and manages its authorization secret.

Applier configuration

Mon, 01 Jan 0001 00:00:00 +0000

This topic describes the additional parameters available for configuring the StormForge Applier. For parameters that apply to the StormForge Agent, see the Agent configuration topic.

The Applier is enabled by default. To disable it, add --set applier.enabled=false to your Helm install or upgrade command.

Applier settings:

Continuous reconciliation

Controls resource patching behavior based on CI/CD and cluster activity. Auto-deploy must be enabled.

Exporter configuration

Mon, 01 Jan 0001 00:00:00 +0000

The Exporter collects workload metrics and forwards them to StormForge. This topic covers the additional configuration parameters available.

Exporter parameters:

Private container registry

Override the Exporter image repository for environments that use a private container registry.

Helm parameter	Default value
`exporter.image.repository`	`quay.io/prometheus/prometheus`
`exporter.image.tag`	(pinned to a tested Prometheus version)

Description

The Exporter uses the Prometheus container image, separate from the StormForge Agent image. When using a private registry, you must push the Prometheus image to your registry and set exporter.image.repository accordingly.

Webhook configuration

Mon, 01 Jan 0001 00:00:00 +0000

Webhook parameters:

Enable or disable the webhook

Controls whether the Applier uses a mutating admission webhook to apply recommendations.

Parameter	Default value
`webhook.enabled`	`true`

Description

By default, the Applier can use a mutating admission webhook to apply recommendations. This setting also grants the additional RBAC permissions required for webhook operation to the Applier.

Cluster defaults templates

Mon, 01 Jan 0001 00:00:00 +0000

The StormForge Agent reads cluster-level optimization defaults from a ConfigMap named cluster-defaults in the stormforge-system namespace. You can create and manage this ConfigMap using kubectl or your GitOps tool. For full management details, see Configure optimization defaults for the cluster.

Check current cluster defaults

To check whether any defaults are already set:

kubectl describe configmap cluster-defaults -n stormforge-system

If you see Error from server (NotFound): configmaps "cluster-defaults" not found, no cluster-level defaults are set.

Install StormForge as an EKS add-on

Mon, 01 Jan 0001 00:00:00 +0000

If you’re running an Amazon EKS cluster, you can install StormForge as an EKS add-on in one of two ways:

Prerequisites

An Amazon EKS cluster
A StormForge account — sign up for a free trial

Install using the EKS UI and StormForge UI

Install the add-on

Open two browser windows side by side.

Install on Red Hat OpenShift Container Platform

Mon, 01 Jan 0001 00:00:00 +0000

Red Hat OpenShift Container Platform is a Kubernetes solution for both cloud and on-premises with providers such as AWS, Google and Microsoft Azure. StormForge is compatible with OpenShift Container Platform versions 4.x and later.

Installation

To install StormForge on OpenShift, do one of the following:

In the StormForge values.yaml file, set openshift: true as a top-level key-value pair, and then apply the file:
```
kubectl apply -f values.yaml
```
Include the --set openshift=true argument when you run helm install, as in this example:

Upgrade

Mon, 01 Jan 0001 00:00:00 +0000

(Optional) Review the current Helm values:
```
helm get values stormforge -n stormforge-system
```
To change any values, save the output to a .yaml file and modify it as needed. When you upgrade, pass the adjusted file to Helm using the -f flag.

Upgrade and reuse all current Helm values:

helm upgrade stormforge oci://registry.stormforge.io/library/stormforge \
  -n stormforge-system \
  --reset-then-reuse-values

Uninstall

Mon, 01 Jan 0001 00:00:00 +0000

Uninstall StormForge when you want to stop optimizing workloads on a cluster or before you delete a cluster from StormForge:

helm uninstall stormforge -n stormforge-system

Uninstalling removes the StormForge components but leaves the StormForge CRDs — and any custom resources, such as optimization configurations — in place. This is expected: it ensures your optimization configuration survives a reinstall.

Migrate from v2 to v3

Mon, 01 Jan 0001 00:00:00 +0000

With v3, the separate stormforge-agent and stormforge-applier Helm charts are combined into a single stormforge chart.

Prerequisites

Before you begin, ensure you have:

The StormForge CLI installed
Access to the values.yaml files for the Agent and/or the Applier

Webhook considerations

The v3 chart’s MutatingWebhookConfiguration reuses the name of the v2 applier webhook. This means:

Helm-managed installs: If a v2 Applier is still installed when you run helm install stormforge, Helm’s release-ownership check will refuse to install.
GitOps users (ArgoCD, Flux, kubectl apply): There is no automatic conflict detection. You must fully remove the v2 Applier before applying the v3 manifests. Failing to do so will result in two conflicting MutatingWebhookConfiguration resources.

CRD considerations

When you uninstall the v2 Agent, the optimize.stormforge.io CustomResourceDefinitions (CRDs) — and all associated custom resources, such as optimization configurations — remain on your cluster. This is expected, as helm uninstall doesn’t remove CRDs. Don’t delete them manually. Deleting a CRD removes every associated custom resource from the cluster.

Installation on StormForge Documentation

Basic installation

Prerequisites

Install StormForge

Advanced installation

Prerequisites

Set up the StormForge CLI

Agent configuration

Third-party secret management

Applier configuration

Continuous reconciliation

Exporter configuration

Private container registry

Description

Webhook configuration

Enable or disable the webhook

Description

Cluster defaults templates

Check current cluster defaults

Install StormForge as an EKS add-on

Prerequisites

Install using the EKS UI and StormForge UI

Install the add-on

Install on Red Hat OpenShift Container Platform

Installation

Upgrade

Related topics

Installation/Migrate v2 → v3

Uninstall

Migrate from v2 to v3

Prerequisites

Webhook considerations

CRD considerations