Trust and reliability
We're constantly monitoring OpenFn so that you don't have to.
OpenFn is packed with enterprise security features—many driven by the demands of our customers, the world's most rigorous international development organizations, over the last 10 years. For us, however, being enterprise grade is actually about something else... it's being Secure, Reliable, Stable, and Standardised.
We pride ourselves in our ability to protect your data without compromising on service availaility, regulation and platform stability. These commitments enables OpenFn to deliver the same entreprise-grade security, availability and stability for our customers, even when their usage grows 100x in 24 hours.
Taylor Downs
Founder, OpenFn
Trusted by leading impact organizations worldwide
Security
Security comes first
OpenFn runs on Google Cloud Platform (GCP), an infrastructure protected by more than 500 top experts in information, application, and network security. OpenFn recognizes that our core competency is integration— not data security — and we made a strategic choice to run on GCP, a platform specifically designed to protect customers from threats. GCP applies security controls at every layer, isolates customer applications and data, and rapidly deploys security updates without customer interaction or service interruption. In short, you're in good hands.
Learn about security on GCP
Connections to the OpenFn environment are via TLS cryptographic protocols ensuring that our users have a secure connection from their browsers to our service at all times. Individual user sessions are identified and re-verified with each transaction, using a unique token created at login.
We routinely backup our databases to Google Cloud Storage. Google Cloud Storage is designed for 99.999999999% durability. It stores multiple copies redundantly across multiple locations, with automatic checksums to ensure data integrity. All connections to the databases use SSL.
Learn about security on GCP24/7 Monitoring
Every 60 seconds our message persistance, triggers, and job runners are tested from independent infrastructure.
Stats are posted to the monitoring site so you can assess our availability and processing times in real-time.
Encryption
Encryption in layers
First, we user a security-oriented Cloud SQL product for data storage that guarantees 256-bit encryption at rest and we only allow connections with TLS/SSL.
For customers that choose to store input/output data on OpenFn for reprocessing, those data must be readable to our application and the users that you authorize. Encrypting the data internally would deny you the ability to use these powerful transformation tools. With that in mind, our datastores and runtime environments leverage the security of our infrastructure, provided by Google. Our datastores are accessible only by our system and nothing enters or exits our infrastructure without being encrypted. Credentials, used to grant OpenFn API access to your various technologies, are encrypted at rest so that, in the unlikely event of a database breach, without access to multiple, independently secured boxes an attacker would be unable to read your authentication information.
Connections to your destination applications are only made over HTTPS, using SSL and basic authentication in most cases—with the technical connection specifications being determined by the REST endpoint of the application to which you are connecting. Technical documentation for individual adaptors can be found in their respective repositories on Github.
Our Encryption:
256-bit Advanced Encryption Standard
SSL/TLS encryption in transit
Credentials/secrets encrypted on disk
Security
Stability where it counts
We've got state-of-the-art infrastructure maintained by a leading global provider and our code base is highly fault-tolerant, making use of the battle-tested Erlang VM. Even though our community develops new enhancements rapidly, you can "version lock" your jobs once they are built to ensure that they run exactly as you wrote them until you decide to build a new version. It's hard enough to maintain an integration between multiple evolving systems, and OpenFn allows you to rest assured that your job script and the supporting architecture never move under your feet.
Scalability
Scalable for any demands
Thanks to Kubernetes (an automated container deployment, scaling, and management system), load-balancing, and automated health checks, OpenFn.org actually monitors the status of its own servers (which always run with several layers of redundancy) and spins up new copies of the application whenever we sense an increased load. Being able to detect shifts in our customers usage and deliver more power—only when needed—allows us to provide a remarkably robust service and at affordable price for the international development sector. Redundancy, automated health checks, auto-scaling, and auto-healing are the key principles of our Kubernetes delivery strategy.