# Upgrade & Backup

> Part of the NocoDB documentation (Self-hosting > Installation > Kubernetes). Index of all pages: https://nocodb.com/llms.txt. Any docs page is available as Markdown by adding `.md` to its URL.

URL: https://nocodb.com/docs/self-hosting/installation/kubernetes/upgrade
Last updated: 2026-08-17

Upgrade, roll back, and back up a NocoDB Helm deployment on Kubernetes.

## Before you upgrade

1. Read the [release notes](/docs/changelog) for the target version.
2. **Back up PostgreSQL** (snapshot or `pg_dump`). This is your rollback safety net.

<Callout type="warn">
  Always back up the database before a major upgrade. Schema migrations run automatically on pod
  startup and are not reversed by `helm rollback`.
</Callout>

## Upgrade

```bash
helm upgrade nocodb oci://ghcr.io/nocodb/charts/nocodb --version <new-version> \
  -n nocodb -f values.yaml --wait
```

The app uses an ordered rollout (`maxSurge: 1, maxUnavailable: 0`): the first new pod runs any
schema migrations (serialized by a migration lock), and the rest start once they complete. The
generous startup probe prevents pods from being killed mid-migration.

For a major upgrade you can be extra cautious by temporarily scaling the app to one replica first:

```bash
helm upgrade nocodb oci://ghcr.io/nocodb/charts/nocodb --version <new-version> \
  -n nocodb -f values.yaml --set replicaCount=1 --wait
# once healthy, restore your normal replica count
```

## Roll back

```bash
helm history nocodb -n nocodb
helm rollback nocodb <revision> -n nocodb --wait
```

<Callout type="note">
  The auto-generated JWT secret and datasource encryption key are never rotated by upgrades (they
  carry `helm.sh/resource-policy: keep`), so rollbacks do not invalidate sessions or stored
  credentials. If a migration changed the schema, restore your database backup to fully revert.
</Callout>

## Backup & restore

* **PostgreSQL:** use your provider's snapshots or `pg_dump`/`pg_restore`. This holds all NocoDB
  metadata.
* **S3:** enable bucket versioning; attachments live here.
* See [Backups](/docs/self-hosting/maintenance/backups) for the general approach.

## Troubleshooting

| Symptom                                      | Likely cause                                                                                                                                                                  |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pod stuck `0/1` for minutes on first install | First-boot migrations running; the startup probe allows this                                                                                                                  |
| `NocoDB requires Redis...` at install        | `replicaCount>1` or `worker.enabled`, and `externalRedis` not configured                                                                                                      |
| Attachments missing on some requests         | Object storage not configured; set up an S3-compatible Storage plugin in the App Store                                                                                        |
| New pods not picking up env changes          | Values delivered via `extraEnvVars` or an external Secret are not tracked by the config checksum; restart the rollout with `kubectl rollout restart` or re-run `helm upgrade` |

---

## Related pages

- [Kubernetes](https://nocodb.com/docs/self-hosting/installation/kubernetes.md): Deploy NocoDB on Kubernetes with the official Helm chart for production, high-availability setups.
- [Install](https://nocodb.com/docs/self-hosting/installation/kubernetes/install.md): Production installation of NocoDB on Kubernetes with the official Helm chart.