Note:

1. This feature is currently available as an early access feature for all paid plans of Creator 6
2. Hotfix can be applied only to:
   
1. applications that were published from Development to Stage and then to Production after June 27, 2026.
2. independent apps with no dependencies across all environments.
   

In a nutshell

Hotfix in environments enables the implementation of critical fixes directly in production by using a temporary, isolated environment setup. It is particularly useful when a Production issue requires an immediate fix but Development is mid-cycle with unreleased changes that cannot be pushed to Production yet. This addresses urgent issues outside the standard deployment cycle, and also ensures that the changes are reverse-merged to Stage and Development for future release continuity.

1. Overview

Hotfix is a dedicated, temporary environment that lets you push critical fixes directly to your live application, bypassing the standard “Development > Stage > Production” deployment.

In a typical application that has been added to environments, version updates move through Development, Stage, and then Production which is a structured flow that ensures stability and controlled releases. However, when a critical issue arises in a live application, waiting for the standard deployment means downtime or disruption for your users. A hotfix allows you to temporarily bypass the standard cycle by fixing the issue in Production through an isolated hotfix environment.

Once you create a hotfix, Creator duplicates your production application to the hotfix environment where you can implement the necessary changes. Once ready, these fixes are published directly to Production. The changes can then be merged back into the Stage versions and Development environment of the app, ensuring future releases remain consistent with what is already live.

For example, in manufacturing systems, a failure in a form workflow that processes production data can disrupt operations. A hotfix allows the issue to be corrected instantly without waiting for the next release cycle.

1.1. What can be edited in a hotfix?

Hotfix supports editing Deluge scripts across the following workflow types:

1. Form workflows
2. Functions

Within the hotfix environment, these existing components can be modified but new components cannot be added and existing ones cannot be deleted.

1.2. How does hotfix affect the standard deployment cycle?

Initiating a hotfix places temporary restrictions on the deployment pipeline for the involved app:

1. Standard Publish Operations Locked: The app can be edited in the Development environment and accessed in the Stage environment since these actions do not affect the publish pipeline. But, standard publish operations from Development to Stage and from Stage to Production are locked during hotfix creation until the fix has been manually merged back into Stage and Development. This ensures that no conflicting changes are introduced while the lifecycle is in an intermediate state.
2. Live Production App in Maintenance Mode: The live mode of the Production app enters maintenance mode only while the hotfix changes are being applied in Production. During this phase, the live application will not be available to the end-users. Once this publish is complete, the application’s live mode becomes accessible again.

2. Hotfix lifecycle

A hotfix lifecycle follows a defined sequence of steps that ensure the emergency fix is released without any hindrances to the existing progress made in each environment:

1. Hotfix Details - Configure the hotfix by verifying the selected production app that is to be added to the hotfix environment and providing a unique link name for the hotfix.

Note: The selected application is the production app that contains the issue to be fixed. Once the app is added to the hotfix environment, this selection is final and cannot be modified within the current hotfix lifecycle.

2. Apply Fix to Production - Edit the required Deluge scripts within the app in the hotfix environment and publish the changes to Production. Once the fix is in Production, it cannot be edited again as part of this hotfix.
3. Merge Fix to Stage - Merge the hotfix changes back into the Stage version of the app. During this process, conflicts may arise when the same component has been modified in both the hotfix and a Stage version.
   1. No Conflicts: The merge can proceed directly.
   2. Conflicts Detected: Since the conflicts cannot be resolved directly in the Stage version, each conflicted Stage version must be published to the hotfix environment one at a time sequentially to compare and complete conflict resolution. The next conflicted version cannot be published to the hotfix until the previous one is fully resolved. Once all Stage versions have been resolved of conflicts, the merge to Stage can proceed.
4. Merge Fix to Development - Merge the hotfix changes into the Development version of the app. Any conflicts between the Development version and the hotfix changes must be resolved before the merge can be completed.
5. Hotfix Complete - Once all steps are complete, the hotfix is marked as complete and all publish operations resume for the involved app.

2.1. Conflict resolution process

In a hotfix lifecycle, a conflict can arise when the same component is modified both in a Stage version or Development application, and as a part of the hotfix. In this scenario, these conflicts must be resolved by comparing the Stage version/Development app with the hotfix changes side by side. Once all conflicts are addressed, the merge can proceed so that the Stage version or Development app can continue through the standard deployment to Production smoothly.

1. Production app: v3.0 (Hotfix is being applied, Function A has been modified)
2. Stage versions: v4.0, v5.0, v5.1

Function A is also modified in Stage versions 4.0 and 5.1, resulting in conflicts.

Resolution Steps:

1. Version 4.0 - Conflict detected
   Publish v4.0 to the hotfix environment, compare it against the hotfix changes, and resolve the conflict in Function A.
2. Version 5.0 - No conflicts
   V5.0 has no conflicts. However, since it falls between two conflicted versions, it is automatically included to maintain version order integrity when publishing v5.1.
3. Version 5.1 - Conflict detected
   Publish v5.1 to the hotfix environment and resolve the conflict in Function A.

Once all conflicts are resolved, the hotfix changes are merged back into Stage and the versions continue through the standard deployment to Production.

3. Use case

Consider an employee onboarding application in which a form workflow, Access Provisioning, triggers when a new employee record is submitted. The workflow reads the employee’s department and sends an API call to provision the appropriate system access based on their role. Following a Production app release in Environments, new employees in the Contract department are onboarded without any system access being provisioned. This blocks them from starting work, while all other departments are unaffected.

Issue in the workflow - The workflow was written and tested against existing department values in Stage. The Contract department was added to the field Department in Production after the Stage testing cycle, so the conditional block in the form workflow has no matching branch for it. When a Contract employee record is submitted in the Production app, access_level is never assigned and the triggered API call fails silently.

Since Development is mid-cycle with unreleased changes, pushing a fix for this issue through the standard pipeline would delay onboarding for all incoming contract employees.

A hotfix is initiated with the link name Access_Provisioning_Fix and adds the onboarding app to the hotfix environment. The Access Provisioning workflow script is updated within the app builder to handle the Contract department addition and published directly to Production. All incoming contract employee records are now provisioned with system access accurately. The fix is then merged back to Stage and Development before the hotfix is marked complete.

4. Navigation guide

You can find Environments under the DEPLOY section on the left-side pane in the Admin Dashboard. From here, you can create a hotfix by clicking the ellipsis () icon next to the required production application.

5. Points to note

For hotfix creation:

1. If a Stage to Production publish is currently in progress, it must be completed before a hotfix can be created.
2. A hotfix requires at least one workflow or function to be present in the production app. If none exist, a hotfix cannot be created for that app.
3. If Stage and Production are on the same version, the issue can be resolved through the standard pipeline by editing the Development app directly, without initiating a hotfix.

During an ongoing hotfix:

1. Only one hotfix can be active at a time in a Creator account. A new hotfix can be created only after the ongoing one completes its full lifecycle, including the fix being merged back to Stage and Development.
2. A hotfix can be deleted only until changes are applied in the production app.
3. Once a fix is applied to Production, it cannot be rolled back. To complete the hotfix lifecycle, it must be merged back into Stage and Development.

6. Related topics

1. Configuring a hotfix for production apps in environments