March 22, 2024

Enhanced Deployment Flexibility with OpenFin's Fallback Manifests

By Steven Mocarski, OpenFin CTO

At OpenFin, we make digital work frictionless and delightfully productive, wherever you are. While we are coming out with some exciting new capabilities to make your OpenFin content usable directly in traditional browsers, many customers today enjoy the additional capabilities that come from using the desktop runtime. One challenge developers face when deploying to desktops they do not control is that policies may be quite different from group to group. To address this, we quietly introduced Fallback Manifests in RVM 9 — a feature designed to provide flexibility and control when deploying to target desktops that may require variations in your application configuration.

The Challenge for Complex External Deployments

Variation in customer desktop configuration due to customer preference or policy concerns can be a headache for developers. Inside your company, you have one set of standards and you can build to this but what if you need the application to run on a diverse range of configurations? For example, a given runtime may not yet be available or an old runtime may be restricted for security reasons. A new version of application features may be unreachable or prevented from starting for a variety of reasons. Fallback Manifests allow platform teams to specify a hierarchy of preferred manifests such that if a user's system does not support the primary version, the RVM automatically selects the next best available version. This feature simplifies your rollout, even in the most complex situations, ensuring compatibility and performance across different environments.

How to use Fallback Manifest as Part of your Deployment Strategy

Integrating Fallback Manifests into your deployment strategy is seamless. By specifying alternative manifests, developers can ensure their applications always run on the optimal runtime version. Consider the following example, which demonstrates how to specify fallback versions for an application targeting runtime version 36, with alternatives for versions 34 and older:


If the application url could not load for any reason (404, the required runtime version was not available, etc), RVM would fallback to the manifest referenced above, which would look similar and perhaps use a different runtime (v34 in this case):


Note that we don’t need a fallback manifest block in the manifest above since we have one in the latest (first) version above. As a side note, were a fallback manifest listed here, it would be ignored since we just use the primary (first) manifest to determine fallbacks (they are not recursive). As with the v6 example, were v5 to fail to load for any reason, we would fallback to the next manifest url, v4 in our example and so on.

This configuration ensures that the RVM selects the best compatible version, streamlining application deployment across varied runtime environments.

Migrating Cache Across Versions With Ease

In the example above, we use a static URL for our "latest" version of our example headphonesOn app and anyone updating from version v5 to v6 of our app (moving from runtime v34 to v36 in this example) would have their cache migrated normally, regardless of their RVM version or whether or not they use fallbackManifest option.

The first time a given manifest URL is run inside a runtime, the RVM will check to see if the cache needs to be migrated. This is important because without migrating the cache, something like user settings stored in the local IndexedDB would be lost when changing runtimes. Prior to the release of fallbackManfiest, the RVM would only migrate the cache if the manifest URL was unchanged, so you could not have a versioned URL of your manifest for upgrades. Fallback manifests helps here as well because it allows you to explicitly identify these fallbackManfiest as the same app, and the RVM will trigger migration when you want it to.

Cache migration is a big topic and we have some exciting things in the works to make this even easier coming later this year.

The Bigger Picture with OpenFin

Fallback Manifests are part of OpenFin's broader toolkit designed to empower developers. Our platform's capabilities are aimed at simplifying the deployment and management of desktop applications at scale, allowing businesses to deliver complex, high-performance platforms efficiently.

OpenFin's commitment to development flexibility and efficiency is embodied in our continuous platform evolution, with Fallback Manifests highlighting our dedication to solving modern deployment challenges. We encourage our developer community to engage with us, sharing insights and questions as we forge the future of platform development together.

Enjoyed this post? Share it!

Related Posts

All Posts ->


ING Integrates OpenFin for Salesforce to Optimize Workflows

Tiberiu Zulean, Engineering Manager at ING, chatted with our Chief Digital Officer, Vicky Sanders, to discuss how ING is leveraging the capabilities of Salesforce and OpenFin to optimize workflows for their employees.

Thought Leadership


OpenFin + AWS Bedrock

OpenFin as an AI Solution? As AWS Partners we explore the simplicity and flexibility of implementing Bedrock’s GenAI workflows with OpenFin Workspace.

Thought Leadership