Deployment & Settings Changes - v1.70.0
Release Date: 2026-08-02
MetaTitle: Deployment Guide 1.70.0 - Seatmap.pro
MetaDescription: Migrations, Helm values and manual steps for upgrading Seatmap to 1.70.0, including the JWT Secret move and the webhook target requirements.
Summary
This release stores the editor’s JWT signing keys in a Secret, ships five Flyway migrations (one of which rewrites data), removes a deprecated SSO value from the editor chart, and adds new Helm values.
Upgrade order: helm upgrade, then delete the old ConfigMap once the editor is healthy.
Manual steps
| Step | Required for | When |
|---|---|---|
Delete the old <release>-rsa ConfigMap |
All deployments using chart-generated keys | After the editor is healthy |
| Review webhook targets | Deployments with webhooks to private addresses | Before the upgrade |
| Run the baked-background section-title backfill | Deployments that baked backgrounds since 1.67.0 | After the upgrade |
Delete the old RSA ConfigMap
See “JWT signing keys are stored in a Secret” below.
Review webhook targets
Webhook delivery validates the target: only public HTTPS destinations are accepted. A target that resolves to a private, loopback or link-local address stops delivering after the upgrade.
Self-hosted deployments that deliver to an internal receiver must opt back in on editor-service. This is a Spring property, not a chart value, so set it through your existing configuration override or as an environment variable:
seatmap.webhooks.allow-private-targets: true
SEATMAP_WEBHOOKS_ALLOW_PRIVATE_TARGETS=true
This turns the address check off. Enable it only where the whole network path is under your control.
Regenerate backgrounds baked since 1.67.0
Backgrounds baked between 1.67.0 and this release are missing their seated section titles. The stripper is fixed, but existing baked output is not repaired automatically. A global administrator triggers the repair once after upgrading; see docs/runbooks/background-section-title-backfill.md. Run it in dry-run mode first to see how many schemas are affected. Backgrounds are also repaired individually the next time they are processed for any other reason.
Database changes
Five migrations run on upgrade. Flyway applies them automatically at editor-service startup.
| Migration | Effect | Data impact |
|---|---|---|
V109__schema_optimistic_lock_version |
Adds schema.version BIGINT NOT NULL DEFAULT 0 for optimistic locking |
Backfills existing rows with 0 |
V110__seat_and_section_category |
Adds nullable category columns to seat and group_of_seats |
None; no code reads them |
V111__pricing_provenance |
Adds provenance columns to seat_state_events and creates the config_snapshot and schema_revision tables |
None; no code reads them. event_type is NOT NULL with a default, so existing rows are backfilled |
V112__fix_pricing_zone_event_keys |
Repairs prices assigned across events by a shared pricing zone | Inserts price rows and rewrites seat_on_event.price_id |
V113__schema_event_config |
Adds nullable config jsonb to schema and event |
None; no code reads them |
V112 is the one to plan for. Where a pricing zone was shared by more than one event, seats could be assigned a price belonging to a different event; the migration creates the missing per-event price rows and repoints the affected seat_on_event rows at them. Take the usual database backup before upgrading.
V110, V111 and V113 are additive IF NOT EXISTS columns left over from pricing work that was rolled back before this release. They are inert - nothing reads them - and are kept because they are already applied on existing environments, where deleting them would fail Flyway validation at startup.
Out-of-order migrations
editor.config.spring.flyway.outOfOrder (default false) is exposed as SPRING_FLYWAY_OUT_OF_ORDER. Deployments that have applied migrations in a non-linear order - typically after running a hotfix branch - can set it to true to let Flyway apply a lower-numbered migration that arrives later. Leave it false unless you hit that specific validation failure.
Configuration changes
New Helm values
| Value | Default | Effect |
|---|---|---|
editor.config.spring.flyway.outOfOrder |
false |
Allows out-of-order Flyway migrations |
booking.config.seatmap.watermark.disabled |
false |
Suppresses the “Powered by Seatmap.pro” branding in the booking widget |
The watermark value maps to SEATMAP_WATERMARK_DISABLED on the booking service. Self-hosted deployments that must not display the branding should set it before upgrading, so the branding never appears.
Removed values
editor.config.seatmap.security.sso.externalPublicKeyUrl is removed from the editor chart along with the SEATMAP_SECURITY_SSO_EXTERNAL_PUBLIC_KEY_URL environment variable. The editor no longer fetches SSO public keys from a remote URL. A value left in a custom values.yaml is ignored and can be deleted.
Kubernetes changes
JWT signing keys are stored in a Secret
The editor’s RSA signing keys are stored in a Secret named <release>-rsa, with private-key and public-key entries.
The key generation job runs on upgrade as well as install, and migrates existing key material into the Secret verbatim, so issued tokens keep verifying and no one is signed out. A new keypair is generated only on a fresh install. The editor deployment waits for the Secret, mounts it as the rsa-keys volume, and reads both keys through secretKeyRef.
After upgrading, once the editor pods are running and healthy on the new release:
kubectl -n <namespace> delete configmap <release>-rsa
Deleting it before the upgrade completes removes the only copy of the keys.
Deployments that supply the keys by some other means, rather than letting the chart generate them, must provide a Secret named <release>-rsa with private-key and public-key entries before upgrading.
Rollback
Rolling the application back to the previous version is safe: V109 and the inert columns are additive, and the code path that reads schema.version is absent in the older release. V112 is not reversible - it has already rewritten price assignments - but its result is the correct per-event assignment, which the older code reads without complaint.
If you roll back, do not delete the <release>-rsa Secret: the older release reads the ConfigMap, so keep both until you are past the decision point.