For the full list of changes, check out the Webiny 5.43.0external link release on GitHub.

Breaking Changes❗
anchor

Existing Amazon VPC Feature - Addressed Amazon OpenSearch Service Configuration Issue (#4532external link)
anchor

Prior to this release, when deploying a Webiny project with the existing Amazon VPCexternal link configuration in place, the Amazon OpenSearch service that Webiny deploys would not get correctly attached to the specified Amazon VPC (related subnets and security groups).

Because of the fact that, with this release, the VPC configuration now gets correctly attached to the Amazon OpenSearch cluster, redeploying an existing Webiny instance will cause the cluster to be DESTROYED AND RECREATED️, which means all data in the existing cluster will be lost

If you’re using the existing Amazon VPC configuration in your Webiny project, make sure to check out the 5.43.0 migration guide guide. For more information about the change itself, check out the dedicated changelog item below.

Folder Level Permissions - Editors Can Now Manage Folders (#4615external link)
anchor

Prior to this release, only users with Owner permissions could manage folders. With this update, users with Editor permissions can now also create, edit, and delete folders.

This change is a breaking one, as it modifies the existing permissions structure. If you have custom permissions set up, you may need to adjust them to accommodate this new functionality.

Make sure to check out the 5.43.0 migration guide guide in case this change affects you.

fastify4.29.0 (#4464external link)
anchor

While working on the TypeScript 5.3.3 upgrade, the fastifyexternal link NPM package was also updated to version 4.29.0.

In case your project contains custom code that directly interacts with fastify, you may need to update your code to be compatible with the new version. We recommend checking their official documentation for any breaking changes or updates that may affect your project.

Make sure to check out the 5.43.0 migration guide guide in case this change affects you.

Webiny uses fastifyexternal link to power its GraphQL and REST APIs. The fastify package is a high-performance web framework for Node.js, designed to be lightweight and efficient.

Advanced Content Organization (ACO)
anchor

This release brings a significant upgrade to how folders and folder-level permissions are processed. This is a major step forward in improving the performance and usability of Webiny, especially for projects with a large number of folders and complex permission structures.

In the following sections, we cover all of the key improvements and changes that come with this release.

To learn more about the Folder Level Permissions feature (FLP), please refer to the Folder Level Permissions documentation.

Improved Folder Loading Performance (#4615external link)
anchor

We’ve vastly improved the performance of the Advanced Content Organization (ACO) feature, specifically in how folders are loaded and managed.

Essentially, folders are now lazy-loaded, which means that only the folders you need to see are loaded at any given time. This greatly improves performance and scalability, especially for projects with a large number of folders.

We’ve been testing the new folder loading mechanism with projects that have over 10,000 folders, and the results have been very positive. The new system is designed to handle large numbers of folders efficiently, making it easier to manage complex content structures.

Overridable Inherited Permissions (#4630external link)
anchor

Inherited permissions can now be overridden at any folder level, giving you more granular control over access.

For example, a specific user might be granted Editor permissions on a specific folder, while still inheriting Viewer permissions from a parent folder. Vice versa, a user can have Viewer permissions on a folder but be granted Editor permissions on a child folder.

This flexibility allows for more complex permission structures, enabling you to tailor access to specific folders based on your project’s needs.

Editors Can Now Manage Folders (#4615external link)
anchor

Prior to this release, only users with Owner permissions could manage folders. With this update, users with Editor permissions can now also create, edit, and delete folders.

Breaking Change

This change is a breaking one, as it modifies the existing permissions structure. If you have custom permissions set up, you may need to adjust them to accommodate this new functionality.

Make sure to check out the 5.43.0 migration guide guide in case this change affects you.

Introducing the "No Access" Permission (#4624external link)
anchor

On top of the existing Viewer, Editor, and Owner permission, we have introduced a new No Access permission. As the name itself suggests, the new permissions allows users to explicitly deny access to a folder for a specific user or team.

Note that, once set, the No Access permission cannot be overridden. In other words, if a user has No Access permission on a folder, they will not be able to access it, regardless of any inherited permissions from parent folders. This is also the case for all folders that are children of the folder with No Access permission.

Folders -pathProperty and Enhanced Search Capabilities
anchor

ACO’s Folder entity now also includes a new path field, which is a string constructed from the folder’s slug and its parent folders’ slugs, creating a hierarchical representation of the folder’s location within the content structure. This field is automatically generated and updated whenever a folder is created or modified. A couple of examples of the path field values are:

  • /folder-1
  • /folder-1/folder-2
  • /folder-1/folder-2/folder-3

Which now also allows for more efficient searching and filtering of folders based on their paths. For example, via the listFolders GraphQL query, you can now filter folders based on their path value using the following operators:

The following example demonstrates how to use the path field in a GraphQL query to list all child folders of a specific folder:

ImprovedgetAncestorsMethod
anchor

Consequently, the getAncestors method has been optimized to leverage the new path field. Previously, this method would retrieve all folders to construct the ancestor tree, which could be inefficient for projects with a large number of folders.

Now, it uses the path value to directly fetch only the relevant folders, significantly improving performance—especially for systems with a large number of folders.

The following example demonstrates how to use the getAncestors method in a context plugin:

Headless CMS
anchor

Heartbeat-Based Timeout Introduced in Record Locking (#4583external link)
anchor

We’ve updated the Record Locking system to be more reliable and responsive.

Previously, records were unlocked using lifecycle-based triggers, which could lead to inconsistent behavior—especially if the client disconnected unexpectedly or didn’t clean up properly.

Now, the locking mechanism uses a heartbeat signal to determine if a user is still actively editing a record. If the system doesn’t receive a heartbeat for 30 seconds, the record is automatically unlocked and made available to others.

This change makes collaborative editing more robust and helps prevent records from remaining locked due to crashes, lost connections, or idle sessions.

In case you missed it, with the 5.40.0 release, we introduced a new Record Locking mechanism that allows multiple users to collaborate on the same record without conflicts. This feature is particularly useful for teams working on content-heavy projects, as it prevents overwriting changes made by others.

Deployments
anchor

Existing Amazon VPC Feature - Addressed Amazon OpenSearch Service Configuration Issue (#4532external link)
anchor

Prior to this release, when deploying a Webiny project with the existing Amazon VPCexternal link configuration in place, the Amazon OpenSearch service that Webiny deploys would not get correctly attached to the specified Amazon VPC (related subnets and security groups).

For example, the following configuration would not work as expected. Contrary to the expectation, the deployed Amazon OpenSearch cluster would not be attached to the specified OPENSEARCH_PRIVATE_SUBNETS subnets and OPENSEARCH_SECURITY_GROUPS security groups:

apps/core/webiny.application.ts

With this release, the underlying issue should no longer occur, and the above configuration will work as expected—with one minor change: instead of using elasticSearchDomainVpcConfig, users should now use opensearchDomainVpcConfig.

For more information on this change and also how to upgrade your existing Webiny project, please refer to the 5.43.0 migration guide guide.

Breaking Change

Because of the fact that, with this fix in place, the VPC configuration now gets correctly attached to the Amazon OpenSearch cluster, redeploying an existing Webiny instance will cause the cluster to be DESTROYED AND RECREATED️, which means all data in the existing cluster will be lost

If you’re using the existing Amazon VPC configuration in your Webiny project, make sure to check out the 5.43.0 migration guide guide.

Introducing thewebiny refreshCommand (#4552external link)
anchor

Multiple times in the past, we’ve seen users needing to run the pulumi refreshexternal link command in order to refresh the state of their Pulumi stacks.

Up until now, to do this, users had to run the following command:

To make this process a bit more straightforward, instead of the above command, users can now simply run:

Functionally, both commands do the same thing, but the new one is shorter and easier to remember.

Development
anchor

TypeScript 5.3.3 (#4464external link)
anchor

TypeScript has been upgraded from version 4.9.5 to 5.3.3.

Note that, at the time of this release, the 5.3.3 version is not the latest TypeScript version available. The latest version is 5.8.3, but we have decided to stay on 5.3.3 for now, as it is the latest version that is compatible with all of our dependencies.

fastify4.29.0 (#4464external link)
anchor

With the TypeScript upgrade, the fastifyexternal link NPM package was also updated to version 4.29.0.

In case your project contains custom code that directly interacts with fastify, you may need to update your code to be compatible with the new version. We recommend checking their official documentation for any breaking changes or updates that may affect your project.

Webiny uses fastifyexternal link to power its GraphQL and REST APIs. The fastify package is a high-performance web framework for Node.js, designed to be lightweight and efficient.

Webiny Packages Versions (#4628external link)
anchor

From now on, each time you run the Webiny CLI, it will check if all @webiny/* NPM packages in your project are using the same version. This is important because Webiny packages are tightly integrated, and having different versions can lead to unexpected issues.

The following screenshot shows an example of the CLI warning you about a version mismatch:

Webiny package versions checkWebiny package versions check
(click to enlarge)