--- title: "Patching Hyperscience" slug: "patching-hyperscience" description: "Patch your Hyperscience instance to apply security and application fixes. Covers patch benefits, cadence, availability, and on-premises and SaaS patching steps." updated: 2026-09-18T17:35:45Z published: 2026-09-18T17:35:45Z canonical: "help.hyperscience.ai/patching-hyperscience" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.hyperscience.ai/llms.txt > Use this file to discover all available pages before exploring further. # Patching Hyperscience Hyperscience releases patch versions to provide application and security fixes for on-prem and SaaS instances. Applying these patches helps keep your instance secure, reliable, and up to date. A patch applies targeted updates without moving your instance to another platform release or SaaS innovation release. For example, patching from v43.0.7 to v43.0.8 applies the fixes included in v43.0.8 without requiring you to update compatible flows or models. This article explains the benefits of patching, when patches become available, what to consider before patching, and how to update your Hyperscience instances to a patch release version. ## Benefits of patching Patching can help you keep your instance healthy by: - Resolving or preventing known application issues. - Addressing security issues. - Improving application reliability. - Providing a more up-to-date baseline for troubleshooting. > [!NOTE] > **Review the release notes before you apply a patch** > > They describe the included updates and identify any considerations for your instance, flows, or models. See relevant information for your instance version in [Release Notes](/general-information/docs/release-notes). ## Patching by deployment type The patching process differs for on-prem and SaaS instances. See the table below: | Deployment type | Patching managed by | Notes | | --- | --- | --- | | [On Premises / Private Cloud](/deployment/docs/saas-vs-on-premise-private-cloud) | Customer | Hyperscience provides the approved patch Bundle, checksum, release notes, and supporting documentation. Your organization applies and validates the patch. Validate the flows and models used in critical business processes in your testing instance before patching your Production Instance. | | [Hyperscience SaaS](/deployment/docs/saas-vs-on-premise-private-cloud) | Hyperscience | Hyperscience schedules and deploys all patches. See [Patch a SaaS instance](/deployment/docs/patching-hyperscience#patch-a-saas-instance). | ## Patching cadence Hyperscience generally releases scheduled patches **every three weeks**. All patches undergo testing, security review, and approval before release. Hyperscience may release off-cycle patches to address critical customer issues or security vulnerabilities. A patch already on the schedule may also ship earlier than planned when a critical issue requires it. Non-critical fixes normally follow the scheduled patch cadence. The inclusion of a fix in a specific patch is not confirmed until Hyperscience finalizes the updates. Review the release notes for a complete list of the fixes included in each patch. When an issue affects multiple supported versions, Hyperscience may include the fix in separate patches for those versions. Availability depends on the affected version, its support status, and whether the fix applies to that version. ## Support and patch availability Patch availability depends on your deployment type, the support status of your version, and the update included in the patch. To learn more, see [Hyperscience Release Model](/deployment/docs/hyperscience-release-process). > [!NOTE] > **Patch availability** > > Confirm patch availability with your Hyperscience representative before scheduling a production change. A scheduled date may change to accommodate a critical issue or release concern. ## Patch a SaaS instance Hyperscience manages patching for SaaS instances. You do not download patch bundles, schedule maintenance, or run any patching steps. Hyperscience applies patches proactively during a dedicated maintenance window. Your testing and production instances are patched in the same window. Patches typically do not require customer action or affect service availability. When a patch requires action from your team or affects availability, Hyperscience communicates the details through the established release notification process. To see the fixes included in a patch applied to your instance, review the [release notes](/general-information/docs/release-notes) for your version. Contact your Hyperscience representative with questions about patch timing for your instance. ## Patch an on-prem instance The Hyperscience Application and Trainer come bundled in a single archive file named `hyperscience-trainer-x.x.x.tgz`, where `x.x.x` is the version number. > [!NOTE] > **Patching follows the same steps as an upgrade** > > However, during patching, you **do not** need to upgrade your flows or retrain your models unless the release notes state otherwise. Hyperscience Support provides the download link for the latest patch applicable to your instance in your Support ticket. Use the link in the ticket to download the approved patch bundle. Patch bundles are cumulative. The latest patch contains the fixes included in the preceding patch versions for the same release. You do not need to apply each intermediate patch separately. For example, you can patch directly from v43.0.1 to v43.0.08 without applying v43.0.2 to v43.0.8 individually. Review the [release notes](/general-information/docs/release-notes) associated with the patch to confirm: - The target patch version. - The fixes included in the patch. - Compatibility considerations. - Required actions. Contact Hyperscience Support if you are unsure which patch applies to your instance. ### Patch the testing instance 1. Download the approved version bundle from the link in your Support ticket. 2. Expand the bundle in a dedicated folder. 3. Copy the `.env` file from the current version directory to the new version directory on each application machine. 4. Run `run.sh init` on one application machine. 5. Run `run.sh` on all application machines. 6. Complete the required trainer update. Follow the steps in the Upgrade the trainer section of the [Technical Upgrade Instructions](/deployment/docs/technical-upgrade-instructions#upgrade-the-trainer) article. #### Validate the testing instance Confirm that: - The expected patch version is running. - All required services are healthy. - Users can access the application. - Critical flows and models operate as expected. - Required integrations operate as expected. - The issue addressed by the patch no longer occurs, if applicable. ### Patch the production instance After the testing instance passes validation, follow your organization’s change-management process and repeat the patching steps in the production instance. #### Validate the production instance Repeat the required health checks and business-process validation in the production instance. Delete the bundle after completing the validation. A packaged file that contains everything needed to install or upgrade the Hyperscience platform. It includes the application and all required tools, helping to streamline setup and upgrade processes. The live Hyperscience system, where real documents and data are processed as part of day-to-day business operations. This instance is used by end users and must meet high standards for performance, stability, and data security. It is distinct from development or testing instances. A separate machine dedicated to handling resource-heavy tasks like training Identification models. It operates independently and connects to the main application through the API.