Skip to main content
Version: v2 ⚡



OpenFn can be used as a secure, stable, scalable cloud-hosted offering or deployed locally—with both managed and un-managed options. Regardless of which path you choose, you can configure OpenFn so that no sensitive data is kept outside your country's borders.


Because of OpenFn's portability specification and open-source deployment tools you can transition between these various pathways at any time. We're committed to a no vendor lock-in experience.

PathwayFreeStandardDedicatedDo-it-yourself (DIY)
DescriptionGo live today on for small scale projectsScale up and down, pay only for what you needA dedicated, unrestricted OpenFn installation anywhere in the world on our servers or yoursDeploy and manage your own solutions with OpenFn
LicenseFree forever with usage limitationsSaaS plans; contact for custom/invoice agreementsSDaaS includes deployment, maintenance, security patches, upgrades, and troubleshooting as a service; contact enterprise@openfn.orgLGPLv3 means use freely as part of any closed or open-source solution, but make all derivative works open source
LocationSecure global cloud infrastructureSecure global cloud infrastructureLocal (in-country) or Global infrastructureWherever you want
DeploymentClick to start at OpenFn.orgClick to start at OpenFn.orgContact enterprise@openfn.orgRead this docs page and visit our GitHub
Setup & ConfigurationYour choice to setup yourself, with a certified implementer, or with the teamYour choice to setup yourself, with a certified implementer, or with the teamYour choice to setup yourself, with a certified implementer, or with the teamYour choice to setup yourself, with a certified implementer, or with the team
SupportGive & receive support via the communityVarious levels from support@openfn.orgVarious levels from support@openfn.orgGive & receive support via the community

Sample Local Deployment Plan

This is just an example

Your requirements will vary, but this is an example plan for achieving a large-scale, high-sensitivity local deployment.

If you're considering a large-scale/high-sensitivity implementation of OpenFn on local/government-managed servers, you might:

  1. Run a proof-of-concept, prototype, or time-bound production solution using the cloud hosted offering while determining fit and value. (It's a more secure, less expensive, and faster way to prove out the value and viability of the solution itself.)
  2. While the first phase is running, assess the value and begin preparations:
    1. Assess the value of the solution itself—is it solving the problems you thought it would?
    2. Asses your data residency requirements—do you need to run this solution in country?
    3. Assess your team’s technical DevOps capacity—how are other local deployments of DPGs going?
    4. Assess your countries computing, storage, and networking infrastructure—what options* are available for servers and network connectivity?
    5. Determine if a "zero-persistence" cloud solution or a locally deployed solution is best for your ministry—with the data above run a cost-benefit analysis on both options.
  3. Engage with or a certified partner to practice deployment, migration, rollback, restart, backup, etc.
  4. Using OpenFn’s portability tools, run a cloned local version of your cloud-hosted solution to assess the readiness of your local deployment.
  5. Establish a fail-over protocol with OpenFn to “fail to cloud” for critical systems.
    1. How often should the implementation configuration (not the sensitive data) be backed up to the hosted cloud?
    2. What credentials and/or test environments should the cloud backup have access to?
    3. Establish a plan for switching between cloud and local.
  6. Establish a support retainer with OpenFn-certified local vendors and/or the OpenFn core team to help maintain the local deployment in case of issues.
  7. Transition fully to your local deployment and maintain capacity to support or redeploy your solution to other cloud or local servers.
  8. Monitor & adjust your strategy as and when required by your country’s usage and data sovereignty requirements evolve over time.

*Head over to the Requirements page for more information on recommended server specifications.

Moving from cloud to local (v1 or v2)

For users that are planning a self-hosted implementation, we recommend developing and testing the initial solution on the OpenFn SaaS (v1 or v2, possibly on a free tier) and then exporting for use in Lightning (v2).

This allows the implementer to focus on ironing out the business and technical requirements of the automation before incurring deployment costs. Focus on the solution, not the deployment. Your OpenFn solution can then be migrated to a local deployment of Lightning once it has been piloted, its value has been proven, and you're ready to scale it up.

A user journey for locally deployed OpenFn

  1. Build and test your workflows on
  2. Export your OpenFn project as code using the "export" button or deployment CLI.
  3. Deploy your local instance of OpenFn/Lightning.
  4. Import your project (from step #2) to your local OpenFn/Lightning instance using the deployment CLI.
  5. Re-configure your credentials (credential secrets will not be included in the export).
  6. Test your locally deployed project.

Technical Guidelines

For detailed deployment documentation instructions, head to the Lightning developer docs page, paying special attention to several sections:

  1. Getting Started
  2. Deployment Considerations
  3. Benchmarking