Skip to main content
There are several easy ways to update Curator. To see if Curator needs an update, check the status of your Curator instance on the homepage of the backend, or on the System Upgrade page. The System Upgrade page opens with a sentence that names the release you are running, for example “You’re on 2026.08-03”. A second line names the newest release and how many releases sit between the two. Under that, three tiles show the kernel build, the newest release and your license, each with its label above the value. The Latest Release tile reads “Up to date” once you are on the newest release. The License tile reads “Valid until” and the date; when the license is close to expiring or already past it, the tile turns red and adds how many days are left. Below the tiles sit the “Change License Key” and “Upgrade From an Archive” links. The first line changes with your situation. On the newest release it reads “You’re on 2026.09-02, the newest release”. On a build ahead of the newest published release, such as a release candidate, it reads “ahead of the newest release” and names that release. On a development build the page cannot match to a release, it says only which build you are on, and the second line points at the list below instead of counting. On a portal hosted by InterWorks, the second line says that InterWorks installs each release for you. When such a portal is behind, it names the release InterWorks will bring the site up to. Below the status, the page lists recent releases on a timeline, newest first. Each entry shows the release, its release notes, and any known issues. A marker shows where you are: “You Are Here” on the release you run, “Recommended Next Step” on the release we suggest upgrading to, and “Newest” on the newest release when it is not the same one. Attention: We recommend taking a Curator Backup before an upgrade. See the Curator Backup documentation for details.

​
Testing Upgrades in a Non-Production Environment

Before upgrading a production instance, we strongly recommend validating the upgrade against a separate dev or staging instance that mirrors production. This catches version-specific issues against your actual data and configuration before they affect end users. A standard Curator license covers up to three instances, so a dedicated non-production instance is available at no additional cost in most cases. The recommended workflow is:
  1. Export production data. From the production instance, navigate to Settings > Curator > Import/Export and run a full export. Download the resulting archive.
  2. Stand up a dev instance at the same version as production. Install a fresh Curator instance running the exact same version as production, then use the Import/Export tool on the dev instance to import the archive from step 1. The dev instance should now closely match production.
  3. Upgrade and validate the dev instance. Perform the upgrade on the dev instance using whichever method you plan to use in production (One-click, Manual, or API). Once the upgrade completes, exercise the integrations and pages most critical to your users — Tableau, Power BI, or ThoughtSpot dashboards, SSO sign-in, scheduled syncs, and any custom themes or pages. Confirm everything renders and behaves as expected.
  4. Back up and upgrade production. Only after the dev upgrade is validated, take a full Curator Backup of production and then run the same upgrade against production.
If the dev upgrade surfaces an issue, you can iterate on the dev instance without disrupting end users, and report findings to InterWorks Support before touching production.

​
Upgrading Curator

One-click Upgrade:
  1. Login to the backend of your Curator instance (e.g. https://curator.example.com/backend).
  2. Navigate to the Settings > Curator > System Upgrade section using the left-hand menu.
  3. Click the button at the top right, which names the newest release (for example “Upgrade to 2026.09-02”).
  4. To upgrade to a release other than the newest one, click “Upgrade to This Version” on that release in the timeline instead.
Manual Upgrade: Use this method when the Curator server has no route to the InterWorks update server.
  1. Login to the backend of your Curator instance (e.g. https://curator.example.com/backend).
  2. Navigate to the Settings > Curator > System Upgrade section using the left-hand menu.
  3. On a machine that does have internet access, open the same page and click “Download Archive” on the release you want. This downloads a .zip file containing the upgrade contents.
  4. Back on the Curator server, click “Upgrade From an Archive” below the tiles. This opens the panel of the same name.
  5. Click “Choose Archive”, select the .zip file you downloaded, and click “Upload and Upgrade”.
Uploading an archive only moves Curator forward. It replaces the application files and runs the database migrations for the release you uploaded; it does not restore the database. To return to an earlier release, restore a full backup taken while that release was running. See the Curator Backup documentation. Curator API:
  1. Login to the backend of your Curator instance (e.g. https://curator.example.com/backend).
  2. Navigate to the Settings > Curator > API Keys section using the left-hand menu.
  3. Select an existing key or create a new key
  4. If creating a new key, save the key.
  5. From the REST API dropdowns, select ‘Portal’ in the left dropdown and ‘Upgrade’ in the right dropdown.
  6. Click the link that was generated below the drop-downs.
  7. This will open a new tab, when upgrade is successful a small success text display will populate.

​
Changing Your License Key

The status line at the top of the System Upgrade page shows when your license expires, followed by a “Change License Key” link. That link opens a page which repeats the current expiry date and takes the new key. Paste the full key from your InterWorks license email exactly as it appears there and click “Save Key”. The key is saved as entered and is not checked first, and upgrades need a valid key, so a mistyped or partial key leaves the instance unable to upgrade until it is corrected. “Back to System Upgrade” returns to the page without saving. If the license has expired or no key is set, the status line says so instead of showing an expiry date, and every upgrade control on the page is withdrawn: the button at the top, the archive upload, and the per-release actions. Entering a valid key restores them. This link does not appear on a portal hosted by InterWorks, because InterWorks manages the license there.

​
Troubleshooting

Having Issues With the Upgrade? Try our Upgrade Troubleshooting Documentation.

​
PHP Version Compatibility

The System Upgrade page automatically checks your server’s PHP version against each release’s minimum PHP requirement. If your server’s PHP version is too old for a given release:
  • That release’s action is disabled and reads “PHP X.X+ Required” in red, with the version this server runs on the line below it.
  • If the newest release needs a newer PHP, the button at the top of the page is disabled and carries the same label, so an upgrade to it cannot be started from there either.
  • That release is never put forward as the “Recommended next step”. The recommendation moves to the newest release of that month your server can actually install.
  • If you reach an incompatible release another way, the confirmation dialog blocks the upgrade and directs you to update PHP first.
To resolve this, upgrade your server’s PHP version before upgrading Curator. See our Dependency Updates page for platform-specific instructions.

​
Database Version Compatibility

Starting with 2026.06-01, Curator also checks your server’s MySQL or MariaDB version against each release’s minimum database requirement. Older database versions are no longer compatible with the underlying framework. If your server’s database version is too old for a given release, the upgrade will be blocked and you will see an error similar to:
ERROR: Your Curator server’s MariaDB version (10.3.39) is too old. You need MariaDB 10.5 or newer before upgrading Curator. Reach out to Curator support if you need help with this.
The minimum supported versions are MySQL 8.0 and MariaDB 10.5. To resolve this, upgrade your database engine before upgrading Curator. See the Database Dependencies by Curator Version section of our Dependency Updates page for the version table and platform-specific upgrade instructions.

​
Known Issues

The System Upgrade page also shows the known issues InterWorks has published for each release, so you can see what affects a release before you upgrade to it and what affects the release you are running today. When a release has known issues:
  • An “N known issues” badge appears under the release in the timeline.
  • A “Known Issues (N)” heading appears under the release notes. The list is collapsed by default; click the heading to expand it.
  • Each entry is a bullet that starts with an impact badge (Small, Medium, or Large), followed by a short note describing the behavior. An entry without a note shows the issue title instead.
  • A smaller line under the note lists the affected areas of Curator. When known, it also shows “Since X” with the release where the issue first appeared. When a later release fixes the issue, it shows “Fixed in X” with that release version.
When the release you are running has known issues, a box near the top of the page also summarizes them, under the heading “Your Version X Has N Known Issues”. Beside the heading it shows the mix of impacts, such as “1 Large, 2 Medium”, and, when every issue has a fix, “All fixed in X” names the release that clears all of them. Click the heading to expand the full list. Each entry uses the same layout, and “Upgrade to X to fix” names the release that fixes that issue. On a portal hosted by InterWorks, the entry shows “Fixed in X” instead, because InterWorks runs the upgrade. The box does not appear when the running release has no known issues or when the page cannot load the release list. This list is curated by InterWorks and only reviewed entries appear. A release with no badge means no known issues have been recorded for it yet, not that the release is free of bugs. If you run into a problem that is not listed, reach out to Curator support.

​
Multi-month Upgrades

We recommend upgrading no more than one month of releases at a time. Curator releases are tagged by year and month, such as 2026.08-03. Moving to another release in the same month, or to any release in the month after it, is a normal step. Moving two or more months ahead is the jump we recommend against, and the confirmation dialog warns about it. If your instance is several months out of date, step through the months rather than jumping straight to the newest release. The timeline marks the release to take next as the “Recommended Next Step”: it is the newest release of the month after the one you are running. Upgrade to that release, then repeat until you reach the newest release. Use the per-release “Upgrade to This Version” action for each step, rather than the button at the top of the page, which always targets the newest release. The recommended step never raises the warning itself, however far ahead it sits. If no release was published in the months right after the one you are running, the nearest later release is both the recommended step and more than a month away, and taking it is the move we are asking for.

​
Common Upgrade Gotchas

When planning an upgrade — especially when jumping several versions — keep the following in mind. Most of these are covered in more detail elsewhere in the docs; this list is a quick pre-upgrade checklist so you know what to watch for.
  • PHP version requirement — Each release declares a minimum PHP version. The System Upgrade page disables the upgrade action for that release, showing a red note naming the PHP version it needs, and blocks one-click upgrades if your server’s PHP is too old. Upgrade PHP first. See the PHP Version Compatibility section above and the Dependency Updates page.
  • Database version requirement — Starting with 2026.06-01, the upgrade is also blocked if your MySQL or MariaDB version is too old (minimums are MySQL 8.0 and MariaDB 10.5). Upgrade your database engine first. See the Database Version Compatibility section above.
  • Upgrading too many months at once. Jumping two or more months of releases in a single step is not recommended. For an instance several months out of date, follow the “Recommended next step” marker on the timeline and upgrade one month at a time. See Multi-month Upgrades above.
  • Database migrations not applied — If the upgrade completes but new features appear missing or the system behaves unexpectedly, the database migrations may not have finished. You can safely re-run them multiple times; follow the steps in Updating the Curator Database (Running Migrations).
  • Stale cache after upgrade — Unexpected behavior immediately after an upgrade is often a stale cache. Ask end users to hard-refresh their browser (Ctrl+Shift+R / Cmd+Shift+R). To flush Curator’s server-side cache, use the Clear Cache button in the backend, or append ?cache=clear to any Curator page URL.
  • Authentication and session changes — Some releases adjust session handling or SSO sign-in. If users are unexpectedly signed out or cannot authenticate after an upgrade, review the release notes for any intermediate versions you skipped and consult the Upgrade Troubleshooting guide.
  • Always upgrade non-production first — Validate the upgrade against a dev or staging instance before touching production. See Testing Upgrades in a Non-Production Environment above.