Snowflake Openflow: A Technical Overview

Estimated reading time: 6 minutes

Snowflake Openflow was unveiled at the Snowflake Summit in San Francisco on 2025 June 3rd. It is positioned as an open, extensible, and secure data integration platform. It was designed for real-time, scalable, and bidirectional data movement. The platform supports both structured and unstructured data, as well as streaming and batch processing. It aims to be a universal service connecting any source to any destination.  

Based on the well-regarded open-source solution Apache NiFi, originally developed by the NSA, Openflow inherits NiFi’s strengths in handling diverse data types and its foundational principles of observability and security. Snowflake contributes to the open-source NiFi community, intending to provide future improvements to the framework. Openflow builds upon NiFi, enhancing its capabilities and presenting it as a pure cloud-native solution with a simplified deployment and management experience through the Snowflake interface, Snowsight.  

Architecture

The Openflow architecture is designed around two main important components:

• Control Plane: This component is responsible for controlling the Deployment, monitoring activities, and providing visibility into data flows. It also houses the Connector Catalog, allowing users to browse available connectors, and includes observability layers to understand data flow performance. The Control Plane is deployed within Snowflake and its UI is integrated into the Snowsight UI. 
  
• Deployment: This is where the actual data processing and movement occur. It can be deployed either within the customer’s Virtual Private Cloud (VPC) or as a containerised service within the Snowflake infrastructure using SnowPark Container Service (SPCS). When deployed in the customer’s VPC, data access happens behind their firewalls. The Deployment hosts the runtime where connectors retrieve data from sources.  

This high-level architecture aims to simplify the deployment and configuration of NiFi, leveraging Snowflake’s ease of use. Traditionally, setting up a powerful system like NiFi requires significant expertise and effort.

Deployment Options and Future Plans

At launch, Openflow supports hybrid deployments with both Snowflake-hosted and Bring Your Own Cloud (BYOC) options. There are also plans for eventual on-premises support. Containerization is delivered natively as a managed service. This allows deployment in either the customer’s own VPC or in a Snowflake Container Service.  

Regarding regional and cloud support at launch, the Snowflake Control Plane requires a Snowflake account in any of the global AWS commercial regions (i.e: Canada (Central), South America (Sao Paulo), US West (Oregon), EU (Frankfurt), etc.). More AWS regions, Azure support, and Google Cloud Platform (GCP) support are expected soon and later in the year, respectively.  

The Openflow Deployment, however, can be run in any AWS region at launch. The goal is to enable management of Openflow infrastructure across any region from a single management pane within Snowflake Snowsight.  

Technical Requirements for Deployment

Snowflake Account Prerequisites:

• An existing Snowflake deployment is required. 
• An additional Snowflake account needs to be set up in one of the supported commercial AWS regions for the Control Plane. Setting up an additional account itself does not incur extra costs; costs are associated with compute usage. 
• The user setting up Openflow requires ORGADMIN permissions (to accept terms and conditions) and ACCOUNTADMIN permissions (for basic Snowflake setup). 
• Setting up Openflow involves defining new privileges at the Snowflake Account level, which are assigned to the ACCOUNTADMIN role by default. These include CREATE Deployment INTEGRATION to create and delete Deployment integration objects, and CREATE RUNTIME INTEGRATION (along with OWNERSHIP on the parent Deployment integration object) to create runtime integration objects. Additional privileges like OWNERSHIP and USAGE can be granted on Deployment integration and runtime objects for granular access control.  

AWS Account Prerequisites (for Deployment in customer VPC):

• An AWS account in any region is required for deploying the Deployment components. 
• Access to AWS CloudFormation, EC2, and ECS is necessary, with permissions to create and manage VPCs and set up infrastructure. 
• The Openflow agent facilitates communication and management between Snowflake and the AWS infrastructure. It is installed on a t3.medium EC2 instance (2 vCPUs, 4GB RAM) by default.

General Deployment Process

The deployment of Openflow is guided by a wizard within the Snowflake Snowsight UI. Users can access the Openflow section under the Data section in Snowsight.  

The process begins with creating a Deployment. The wizard guides the user through steps such as checking prerequisites, specifying the deployment location (initially AWS, with Azure and GCP on the roadmap), and naming the Deployment.  

A key step involves selecting the deployment option for the Deployment. Users can choose a managed VPC option, where a Snowflake agent creates and manages the VPC (the simplest option), or the Bring Your Own VPC option for more control and custom configuration.  

The outcome of this wizard-driven process is a CloudFormation template (a YAML file). This template can be downloaded and provided to an AWS administrator to automate the setup of the necessary AWS infrastructure, including VPCs, subnets, and the Openflow agent on an EC2 instance. The Openflow agent then pulls images containing different versions of Openflow and connectors from the Snowflake Image Repository. It simplifies both software management and upgrades.  

Once the Deployment is ready and the agent is running, users return to the Snowflake Control Plane in Snowsight to manage things through the UI. From here, they can create Runtimes, which represent clusters of Openflow runtime servers for executing flow definitions. For Kubernetes-based Deployments, runtimes represent a stateful set of Openflow Runtime containers and supporting components deployed in a namespace.  

Runtime configuration includes selecting node types (small, medium, large) with varying CPU and memory resources, and defining scalability settings with minimum and maximum node ranges (up to 50 nodes) to handle varying data volumes. The wizard and the automated setup process aim to significantly reduce the time and expertise traditionally required to deploy and configure complex data integration infrastructure.   

Discover how OpenFlow can help you unlock the full potential of your data with Snowflake in our article on unleashing data velocity.

Why is Devoteam excited about Snowflake Openflow? 

Much of my professional career has been spent as a data engineer, and I’ve used a wide variety of integration tools. However, my last three years have revolved around Snowflake’s AI Data Platform. While I was immediately impressed by its ease of use, power, and continuous new features, this phrase always crossed my mind: “it would only need its own integration tool to be perfect”. It’s still early to say if it is perfect, but for me, it feels very close to it. And it is Open Source, so, I can’t wait to see how the community starts to develop its own connectors. 

For more details on the partnership behind OpenFlow, read our news announcement about Devoteam’s collaboration with Snowflake.

Further explore how this technical foundation enables Snowflake OpenFlow to serve as a powerful, AI and agentic-ready data platform.