Updates and Maintenance

ɳSelf Cloud keeps your stack current without surprise downtime. Updates are applied automatically in your configured maintenance window. Security patches ship within 6 hours on all channels. Plugin updates are continuous and individually rollbackable. This page documents how all of this works and what controls you have.

Update channels

Security releases bypass the channel cadence entirely. A CVE rated Critical or High is patched and deployed to all servers on all channels within 6 hours of the fix being validated on staging.

Switching channels

# Switch to beta channel
nself cloud channel myapp --set beta

# Switch back to stable
nself cloud channel myapp --set stable

# Current channel
nself cloud status myapp
# Channel: stable
# CLI version: 1.1.0 (latest on stable)
# Next update window: Sun 2026-05-12 03:00 local

Update cadence

Maintenance windows

Non-urgent updates (patches and minor releases) run inside your configured maintenance window. The default is Sunday 03:00 local time for 2 hours.

Change the window in Settings → Maintenance in the dashboard, or via CLI:

# Set maintenance window to Wednesday 01:00 UTC, max 3 hours
nself cloud maintenance myapp --day wednesday --time "01:00" --timezone UTC --max-duration 3h

# Pause automatic updates (manual updates only)
nself cloud maintenance myapp --pause

# Resume automatic updates
nself cloud maintenance myapp --resume

# View current window
nself cloud maintenance myapp
# Window:    Sunday 03:00 (Europe/Berlin)
# Duration:  2 hours max
# Status:    Active
# Last run:  2026-05-04 03:07 — 1.0.12 → 1.0.13 (4m 22s)

Manual update

Trigger an update on demand without waiting for the next maintenance window:

# Trigger update now (runs in background)
nself cloud upgrade myapp

# Output:
# Starting upgrade for myapp.cloud.nself.org...
# Current: 1.0.12 → Target: 1.0.13
# Backup snapshot created: snap-2026-05-07-0841
# Stopping services (rolling)...
# Updating CLI binary...
# Running migrations (3 up)...
# Restarting services (rolling)...
# Health check passed.
# Upgrade complete in 3m 47s.

# Force upgrade to a specific version
nself cloud upgrade myapp --version 1.0.13

# Upgrade with dry run (shows what would change)
nself cloud upgrade myapp --dry-run

During an update, services are restarted one at a time with health checks in between. Expect 30–90 seconds of possible 502 responses from Nginx as services reload. The total update duration is typically 3–8 minutes depending on the number of migration steps.

What happens during an update

1. Pre-update backup snapshot. A Hetzner VPS snapshot is taken. Your application data is also pg_dump'd and stored in object storage. This is separate from nightly backups and is retained for 7 days.
2. Download new CLI binary and plugin versions. Downloaded from the ɳSelf CDN, verified via SHA-256 checksum before extraction.
3. Run database migrations (forward). Migrations run against Postgres with a short lock window. Long-running migrations are broken into batches by the migration system to avoid holding locks.
4. Rolling service restart. Auth → Hasura → MinIO → Redis → Functions → Nginx. Each service is health-checked before the next one is restarted.
5. Post-update health check. All four required services (Postgres, Hasura, Auth, Nginx) must pass health checks within 60 seconds. If any fail, automatic rollback triggers immediately.
6. Notification. An email is sent confirming the update or describing the rollback event.

Rollback

Roll back to the previous version from the dashboard or CLI. We retain the previous CLI binary, plugin set, and config snapshot for 7 days after each update.

# Roll back to previous version
nself cloud rollback myapp

# Output:
# Rolling back myapp.cloud.nself.org...
# Current: 1.0.13 → Rolling back to: 1.0.12
# Restoring pre-update snapshot snap-2026-05-07-0841...
# Running migrations (3 down)...
# Restarting services (rolling)...
# Health check passed.
# Rollback complete in 4m 12s.

# Roll back to a specific snapshot
nself cloud rollback myapp --snapshot snap-2026-05-01-0300

Schema changes and rollback

Every migration is tested both forward and in reverse on our staging environment before being promoted to stable. A schema change that cannot be safely reversed is flagged asno-rollback in the update metadata. When a no-rollback migration is included, you will be prompted to accept it before the update proceeds:

# Example: update contains a no-rollback migration
nself cloud upgrade myapp
# Warning: This update includes migration 0094_drop_legacy_tokens which cannot
# be reversed after it runs.
#
# Confirm? A pre-update snapshot will still be taken, but schema rollback
# is not available after this migration. (yes/no): yes

Even in these cases, the VPS snapshot means you can restore the entire server to its prior state if needed — the snapshot includes the database volume. Schema rollback and server rollback are two distinct mechanisms.

Plugin updates

Plugin updates are applied continuously, independent of the CLI update cycle. Each plugin update is a hot swap — the plugin process is restarted without restarting other services. You can pin a plugin to a specific version or roll back an individual plugin:

# View plugin versions
nself plugin list --installed --versions

# Roll back a single plugin
nself plugin rollback ai --version 2.1.3

# Pin a plugin to a specific version (prevents auto-update)
nself plugin pin ai --version 2.1.3

# Unpin (allow auto-update again)
nself plugin unpin ai

Update notifications

You receive email notifications for:

• Successful updates (patch summary, duration, new version)
• Update failures and automatic rollback events
• Upcoming minor release deployments (7 days advance notice)
• Security patch deployments (post-deploy notification)
• Infrastructure price changes (14 days advance notice)

Notification preferences are in Settings → Notifications. You can also configure a webhook to receive update events in your own systems:

# Configure update webhook
nself cloud webhook myapp --url https://your-app.com/hooks/nself-updates \
  --events update.success,update.failed,update.rollback

Quick links

• Getting started — provision your first server
• Provisioning — what happens during provisioning
• Billing and subscriptions — plans and payment
• Privacy and data portability — export and deletion
• Support — SLAs and how to file a ticket
• Cloud CLI reference — all nself cloud commands