TL;DR: Bold BI® Upgrade Center (Beta) brings the Kubernetes upgrade workflow into the product by checking for available versions, validating the environment, backing up database tables affected by schema changes, updating application images, and monitoring the operation. It also supports automatic rollback when applicable and manual rollback within the supported rollback period, helping Kubernetes administrators manage upgrades through a guided interface.
Introduction
BI platforms are evolving fast, and deployment, patching, and version upgrades are becoming just as important as the analytics features themselves. For admins running Bold BI on Kubernetes, upgrading used to mean coordinating image updates by hand, tracking schema changes manually, and hoping the rollout went smoothly.
Bold BI's Upgrade Center changes that. In this blog, we'll show you how to upgrade Bold BI on Kubernetes using Upgrade Center, walk through the process step by step, and explain how it helps reduce upgrade risk with validation, backup, monitoring, and rollback capabilities built in.
Why In-App Upgrades Matter for Bold BI Admins
Kubernetes gives Bold BI the flexibility to scale in production, but it also adds real complexity to every version upgrade. A typical rollout means updating deployment images, watching rollout status, and confirming every service is healthy again, all while wondering whether a schema change will break an existing dashboard.
Upgrade Center removes that guesswork by bringing the entire process in-app. Here's what changes:
| Aspect | Without Upgrade Center | With Bold BI Upgrade Center |
| Checking for a new version | Track release notes and docs separately | See available versions and notes right in the product menu |
| Schema risk | Manually identify which tables a release will touch | Affected tables are found and backed up automatically |
| Rollout | Update images and watch rollout status by hand | Controlled, sequenced rollout with built-in health checks |
| Recovery | Manually restore from a separate backup process | One-click rollback, manual or automatic |
That shift mirrors a broader pattern in cloud-native operations. Kubernetes itself already reduces upgrade risk at the infrastructure level: its rolling-update mechanism replaces Pods incrementally instead of all at once, keeping a minimum number available throughout the process (Kubernetes documentation: Performing a Rolling Update, retrieved 2026-09-03). Upgrade Center builds directly on top of that primitive. In other words, it adds the BI-specific checks (schema backups, pre- and post-upgrade validation) that the Kubernetes rollout mechanism has no way to know about on its own.
What Is Bold BI Upgrade Center?
Bold BI Upgrade Center is an in-app upgrade management feature built for Bold BI deployments running on Kubernetes. Instead of manually updating deployment configurations and tracking upgrade progress across multiple tools, administrators get a guided workflow that manages validation, backup, rollout, monitoring, and rollback from a single interface. In practice, that guided workflow shows up as five concrete capabilities:
- See what's new without leaving the app. Check available versions and release notes right from the product menu.
- Know what will change before you commit. Upgrade Center flags the exact database tables a release will touch.
- Never upgrade on faith. Affected tables are backed up automatically before anything changes.
- Stay in control of the rollout. Deployments update in a controlled, sequenced order instead of all at once.
- Go back if you need to. Roll back to the previous version without running a separate recovery process.
Getting Upgrade Center Ready on Kubernetes
Upgrade Center currently supports Kubernetes-based Bold BI deployments, including Google Kubernetes Engine, Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Rancher-managed Kubernetes, and other supported distributions. You can deploy it using kubectl or Helm, and it runs on namespace-scoped permissions. Namespace-scoped permissions mean Upgrade Center only needs access within the namespace it's deployed to, rather than cluster-wide access, so a compromised credential has a much smaller blast radius.
What to Know Before You Get Started
Upgrade Center is designed for Kubernetes-based Bold BI deployments and supported database environments. Before getting started, keep a few important considerations in mind:
Upgrade Center is currently available in Beta for supported Kubernetes deployments. To evaluate this feature, use the 16.3.5_upgrade_center image tag for your Kubernetes deployment.
- Deployment and database support: Upgrade Center supports Kubernetes-based deployments and supported database engines configured for those environments. Non-Kubernetes deployments and certain database configurations, including Shared Database and Oracle Database setups, are not currently supported by Upgrade Center.
- Backup responsibility: Before upgrading, create and verify a complete database backup. Upgrade Center backs up only the tables affected by the selected release for rollback purposes and does not replace your organization's regular backup and disaster-recovery processes.
- Kubernetes permissions matter: Upgrade Center relies on the required Kubernetes permissions to create and manage its resources. Missing permissions can prevent deployment, validation, upgrade, or rollback operations from completing successfully.
- Image repository accessibility: Upgrade Center must be able to access the configured image repository during validation and upgrade operations. Invalid repository settings or inaccessible images can prevent an upgrade from proceeding.
- Service deployment requirements: Upgrade Center can upgrade only services that have already been deployed. New services must first be deployed through the standard Helm or kubectl deployment process.
- Upgrade operation limits: Only one upgrade or rollback operation can run at a time. To avoid conflicts, manual deployment changes should not be performed while an upgrade is in progress.
- Rollback availability: Rollback is available only while the required backup and rollback data remains within the supported retention window. If the backup data expires or is removed, rollback may no longer be available when needed.
A Step-by-Step Walkthrough: Upgrading Bold BI With Upgrade Center
Before enabling Upgrade Center, review the prerequisites, supported deployment environments, and current limitations to ensure your Bold BI deployment is ready for upgrade management.
Prerequisites
Confirm the following before enabling or using Upgrade Center:
- Database permissions: The startup database user must have permission to create and drop databases.
- Compute resources: The Kubernetes node where Upgrade Center and validation jobs run must have at least 2 vCPU and 4 GB of free memory available for the upgrade operation.
- Kubernetes permissions: The Kubernetes user applying the Upgrade Center manifests must be able to create the required Service Account, Role, and RoleBinding resources in the Bold BI namespace.
Once Upgrade Center is enabled, it appears in the product menu for administrators. Here's what the process looks like end to end.
Step 1: Check for Updates from the Product Menu
From the Bold BI product menu, select Check for Updates to open the Upgrade Center page. The landing page shows the version you're running, the latest available version, a list of releases with notes, a Custom patch option, and your upgrade history. If you're already on the latest version, Upgrade Center simply lets you know there's nothing new to install.
Upgrade Center landing page showing the current version, latest available release, and upgrade options
Step 2: Upgrade to the Latest Release
Moving from one supported version to the next, such as from v16.3.6 to v16.3.7, takes just a few clicks:
- Open Upgrade Center from the product menu.
- Go to the Available releases tab.
- Review the available versions and their release notes.
- Select the version you want.
- Click Upgrade.
- Review the confirmation dialog, including any affected database tables and warnings.
- Click Start Upgrade.
Confirmation dialog showing the target version and affected tables
After confirmation, Upgrade Center automatically manages the remaining upgrade workflow, including validation, backup, rollout monitoring, and status analytics.
Step 3: Apply a Custom Patch From Support
Sometimes Bold BI Support resolves a specific issue with a custom image tag or patch version ahead of the next full release. The Custom patch tab is built for exactly that. Enter the patch version Support gave you, optionally point to a custom image repository, then validate before upgrading:
- Open Upgrade Center and go to Custom patch.
- Enter the custom patch version or image tag provided by Support.
- Optionally enter a custom image repository. This field is pre-filled with your current deployment's repository, so you only need to change it if the patch is hosted elsewhere.
- Click Validate to confirm the image references.
- Review the validation results.
- Confirm and start the upgrade once everything checks out.
Custom Patch tab showing patch version validation and upgrade options
The patch version has to be higher than what you're currently running, and it uses the same monitoring, cleanup, and rollback experience as a standard upgrade. Schema backup is skipped here, since patches typically don't touch the database.
Step 4: See What Happens Behind the Scenes
A standard upgrade is processed through five monitored stages:
- Database backup: Upgrade Center identifies the existing database tables affected by the selected release and backs them up before application images are updated. This affected-table backup is not a complete database backup and does not replace the customer-managed backup that should be maintained before an upgrade.
- Pre-upgrade validation: Upgrade Center validates the existing environment before updating application images. If validation fails, the image update does not begin.
- Kubernetes upgrade: Deployment images are updated in predefined groups. Deployments within a group can update in parallel, and the next group begins only after the current group becomes healthy.
- Post-upgrade validation: Upgrade Center runs configured checks against the upgraded application to verify its health and key application workflows.
- Cleanup: Upgrade Center removes the temporary resources created for validation. Cleanup also runs when required after a validation failure or cancellation.
Custom patch upgrades use the same validation, Kubernetes upgrade, monitoring, and cleanup workflow, but database backup is skipped.
The monitoring page tracks all five stages and shows whether each stage is Pending, Running, Passed, Failed, or Skipped. You can expand a stage to review its details.
Here, Schema backup shows the affected tables that were backed up, while Kubernetes upgrade shows the grouped rollout and status of each deployment.
Schema backup and upgrade stages showing detailed progress and deployment rollout status
Step 5: Monitor the Upgrade in Real Time
The monitoring page tracks all five stages, such as schema backup, pre-upgrade validation, upgrade, post-upgrade validation, and cleanup, on one screen. Each stage shows its status, progress percentage, and duration as it happens. Status values include Pending, Running, Passed, Failed, Skipped, Rolled back, or Cancelled, so you always know exactly where things stand.
Upgrade monitoring page showing progress across all five upgrade stages
While the upgrade is running, Bold BI displays a banner across the app letting everyone else know an upgrade is underway. It asks them to hold off on creating or editing dashboards, sites, users, or settings until it finishes, so the whole team stays informed without a separate announcement.
Once post-upgrade validation passes, the Cleanup Job runs automatically, removing any temporary test users, sites, or data that validation created. It uses the same Playwright-based validation runner from the previous stage. This runner is the automated browser-testing tool Upgrade Center uses to confirm the application actually works after an upgrade, not just that the pods are running. If that runner is turned off, cleanup is simply skipped, and a skipped or failed cleanup does not mean the upgrade itself failed.
Want the full picture? Open View Details on any stage for its log, or Download Complete Logs for the whole job, including backups, rollout progress, warnings, and errors. An HTML report is also available. It is checked against a pass-rate threshold that defaults to 100%, and reports are kept for your last seven upgrade jobs.
Complete operation logs showing post-upgrade validation results and downloadable upgrade logs
Step 6: Track Your Upgrade History
Every upgrade and rollback is logged in the History tab: source version, target version, operation type, status, and who started it. Even failed or rolled-back jobs stay open, so you can dig into what happened. Each entry carries an Open action for those details, and, where a valid rollback point exists, a Roll back action right on the same row.
History tab showing past upgrade and rollback operations with their status and details
Step 7: Roll Back or Cancel If You Need To
Manual rollback: A rollback point is available from the History section for your most recent successful upgrade, within a 7-day window by default as shown in the following image. Select the Rollback point and confirm it.
Confirm rollback dialog showing version details, backup information & impact
Rollback progress page showing all rollback stages completed successfully
The confirmation dialog will open, showing exactly what will change, including database backups, Kubernetes images, and what to expect before rollback starts. One warning worth repeating from that screen is that you should not stop the Upgrade Center pod while a rollback is restoring database tables or deployment images.
- Automatic rollback: If something fails after changes have already been applied, such as a rollout issue, a failed health check, or a failed post-upgrade validation, Upgrade Center rolls back automatically. It uses the same rollback pipeline as a manual rollback, but the process is triggered automatically rather than by an administrator.
- Cancellation: You can cancel an upgrade while it's still safe to do so. Cancelling before images change simply stops the remaining steps; cancelling after may trigger a rollback.
Where Upgrade Center Fits: Real-World Use Cases
- Routine version upgrades: An admin wants to move a production deployment to the next minor version as soon as it's out, without booking a maintenance window.
- A support-provided fix applied fast: Bold BI Support resolves an issue with a custom patch, and the admin validates and applies it directly instead of waiting for the next release.
- De-risking upgrades in regulated environments: A compliance-sensitive team wants documented proof that an upgrade was validated before and after the change.
- Multi-tenant SaaS deployments: An ISV embedding Bold BI needs upgrades applied in a controlled sequence, so tenant dashboards stay consistent across every account.
Preparing for Safer, Simpler Bold BI Upgrades
As BI platforms take on more responsibility (AI-driven insights, embedded analytics, and real-time dashboards), the infrastructure behind them needs to keep pace without adding operational risk. Upgrade Center reflects that shift: a single, guided way for admins to keep Bold BI® current without the manual coordination upgrades used to require.
Ready to simplify Kubernetes upgrades? Follow the steps provided in this blog to configure Upgrade Center in your environment or start a free trial to experience how Bold BI streamlines deployment management, monitoring, and upgrades from a single platform.
Frequently Asked Questions
1. Who can use Bold BI Upgrade Center?
Administrators can access it from the product menu to start, monitor, cancel, or roll back an upgrade.
2. What happens if a database schema is affected?
Upgrade Center identifies the specific tables involved and backs them up before the upgrade begins, so the change can always be reviewed or reversed.
3. Can I stop an upgrade once it has started?
Yes. Depending on the stage it’s reached, cancelling either stops the remaining steps or triggers a rollback to the previous version.
4. What happens if an upgrade fails partway through?
If the failure happens after changes are already applied, such as a failed rollout or a failed validation check, Upgrade Center automatically rolls back to the last stable version.
5. Is Upgrade Center available outside Kubernetes?
Not yet. It’s built specifically for Kubernetes-based Bold BI deployments.

Top comments (0)