SkaleData DocsVersions and upgrades
How SkaleData versions a cluster with the Scaffold tag, how to check which version a cluster runs, and how to upgrade.
SkaleData versions each cluster with one identifier: the Scaffold release tag,
such as v0.1.0-beta.68. Scaffold is the infrastructure definition that
SkaleData applies to your cloud account. One tag pins the Kubernetes version and
the version of every platform component the cluster runs, so a cluster on a
given tag is a known, tested combination.
Versioning scheme
| Format | Example | Meaning |
|---|---|---|
v0.1.0-beta.N | v0.1.0-beta.68 | Beta release N |
- Pre-GA releases use
v0.1.0-beta.N. Releases move to semantic versioning (v1.0.0,v1.1.0) at general availability. - Upgrades only move forward. You can't move a cluster to an earlier tag.
- New clusters get the current default tag. Existing clusters stay on their tag until you upgrade them.
What a release pins
- Kubernetes: the GKE, EKS, or AKS version the cluster runs.
- Airflow: the Apache Airflow Helm chart and default image. The image has its own release log; see Image releases.
- Airbyte, Superset, and DataHub: the application charts and default images.
- CloudNativePG: the operator that runs the cluster's PostgreSQL.
- Terraform: the provisioning engine and provider versions.
Check a cluster's version
Open Clusters, select the cluster, and read the Version field in the cluster details.
Upgrade a cluster
When a newer tag is available, the cluster page shows an upgrade banner.
- Open Clusters and select the cluster.
- Click Upgrade, choose the target version, and confirm.
An upgrade runs terraform apply with the new tag. Kubernetes rolls
application pods onto the new versions, so workloads see at most brief
interruptions while pods restart. The Jobs page shows the upgrade's
progress and logs.
To start an upgrade from the API, send POST /clusters/{id}/upgrade with a
body of {"scaffold_version": "<tag>"}. POST /clusters/{id}/upgrade-preview
returns the plan without applying it.