Skip to main content

​
The flow

helm repo update
helm upgrade radar-hub skyhook/radar-hub --reuse-values
What happens:
  1. Helm renders the new manifests against your existing values.
  2. The radar-hub Deployment rolls (default rolling update; one new pod up + healthy before the old terminates). Each new pod’s migrate initContainer applies any pending schema migrations against your Postgres before the main hub container starts.
  3. The radar-hub-web Deployment rolls similarly.
Rolling-update strategy is deliberately conservative - the control plane is single-replica today, so the rollout briefly serves out of one new pod before the old terminates. Brief 503s during the cut are normal; the web app’s auto-retry covers them.

​
Pinning a specific version

helm upgrade radar-hub skyhook/radar-hub --reuse-values \
  --set image.hub.tag=0.2.1 --set image.web.tag=0.2.1
Pin both - they share appVersion and we publish them together. Mismatched tags work but aren’t a tested combination.

​
Migration safety

All migrations land in db/migrations/NNN_*.sql and follow these rules:
  • Forward-only. No down-migrations - rolling back means restoring from backup.
  • Additive-by-default. New columns are nullable + defaulted; new tables don’t break existing reads.
  • Idempotent. IF NOT EXISTS, IF EXISTS, ON CONFLICT DO NOTHING. A re-run never fails.
  • Tracked. schema_migrations records every applied version; the runner skips applied ones.
When a migration is destructive (drops a column, rewrites data, requires a downtime window), it’ll be flagged in the release notes and gated behind a --set migrations.allowDestructive=true value. We don’t have any of those today.

​
Version-skew policy

  • The chart and the images ship together. Use helm upgrade (which pins both via appVersion) rather than rolling images independently.
  • The control plane speaks to in-cluster Radar via the tunnel protocol, which is forward-compatible by design - older Radar versions talk to newer control planes. We test 2 minor versions back. If you see protocol-level errors, check the Helm chart pinned in customer clusters: radar chart ≥ 1.5.4 is required for cloud-mode RBAC.
  • The web app is served by the radar-hub-web image and is pinned to the control plane by appVersion. You can’t run a newer web app against an older control plane - the chart prevents this.

​
Pre-upgrade checks

# 1. Verify the chart is reachable + the new version is what you expect.
helm search repo skyhook/radar-hub

# 2. Lint the new chart against your live values.
helm get values radar-hub > /tmp/live-values.yaml
helm template radar-hub skyhook/radar-hub -f /tmp/live-values.yaml > /tmp/rendered.yaml

# 3. (Recommended) Take a backup of your Postgres.
pg_dump -h <host> -U radar radar_hub | gzip > radar-hub-pre-upgrade.sql.gz

​
After upgrade

The first thing to check post-upgrade: 
kubectl -n radar-hub logs deploy/radar-hub-hub --tail=30
Look for:
  • radar-hub starting addr=:8080 mode=self_hosted ... - the control plane booted.
  • license verified - the new build is signed against the same Skyhook public key as the old.
  • No database schema not found / pg_query: relation "X" does not exist - the migrate initContainer applied successfully before the main container started.
In the web app: hit GET /api/config and confirm version.current matches the chart’s appVersion.

​
Rollback

helm rollback radar-hub <previous-revision>
Caveat: Helm rollback rolls back the manifests, NOT the database. If the previous release had a different schema, the rolled-back control plane will fail against the migrated DB. We don’t ship down-migrations. Practical guidance:
  • For chart-template-only changes (annotations, resources, ingress): rollback is safe.
  • For binary-version rollbacks within the same migration cohort: rollback is safe.
  • For binary-version rollbacks across a destructive migration: restore from backup.
Tag releases that include destructive migrations clearly in our release notes so you know which rollbacks need a DB restore.

​
Cadence

  • Patch (0.x.Y): as needed, typically weekly. Bug fixes only. Minor or no migration.
  • Minor (0.X.0): monthly. Feature work + migrations as needed.
  • Major (X.0.0): breaking changes, e.g. cookie format change, mandatory new env var. We’ll publish a migration guide ahead of these.
We support the current minor + the previous one. A 6-month-old version is out of support and may not get patches.