Sitefinity Cloud
Release Notes

What's new

Redis cache hosted within the project environment

The Redis cache used by Sitefinity Cloud now runs inside the project's own application hosting environment rather than as a separate managed service. Each environment gets its own dedicated Redis instance, deployed alongside the CMS and the renderer.

Because the cache now sits next to the applications that use it, round trips are shorter and cache traffic never leaves the project environment. The instance runs in a high availability configuration with automatic failover between replicas, and memory and persistence are sized per environment, so the cache can be tuned to the workload of each individual environment rather than to a fixed service tier. This backs both the CMS cache and the .NET Core Renderer output cache introduced in the previous sprint. The change is being rolled out gradually and requires no action on your side.

Access rule analytics

Access rules in the project sidebar now include an analytics view. For any rule, you can open the analytics panel to see how many requests the rule matched over the past day or the past seven days, plotted as a trend over time and compared against total traffic for the project.

The panel also breaks the matched traffic down by top source IP addresses, countries, networks, request paths, hosts, HTTP methods, and user agents, so you can quickly tell whether a rule is doing what you intended, whether it is too broad, and where the traffic it blocks is coming from. This removes the need to raise a support request to understand the effect of a rule before or after changing it.

Learn more about access rules here.

Skip environment stages in CI/CD runs

CI/CD pipelines now support skipping individual environment stages when you queue a run. Previously, deselecting an intermediate stage would prevent all downstream stages from running, because each stage required its predecessor to have completed successfully. A stage whose predecessor was intentionally skipped now proceeds as expected, while genuine upstream failures still stop the run.

This makes it possible to deploy directly to a later environment without running every preceding stage, for example when re-promoting a build that has already been validated.

Learn more about deploying code changes here.

What's improved

• Added Git Large File Storage support to CI/CD checkouts, so files tracked with Git LFS in the CMS, .NET Core Renderer, and Next.js Renderer repositories are restored in full during the build instead of being published as placeholders.
• Fixed deployment package extraction failing for repositories that contain files with non-ASCII names.
• Fixed the Sitefinity upgrade pipeline failing to detect the current ASP.NET Core Renderer version in some projects.
• Fixed a failure in the build step of the Sitefinity upgrade pipeline in some edge cases.
• Improved application startup after deployments and restarts, so the CMS becomes available faster and more consistently.
• Increased the wait time following an application restart so that restarts complete reliably on larger deployments.
• Improved the accuracy of monthly usage reports by excluding additional automated traffic from page view counts.