Snowflake Openflow Overview: Gen 2, Managed Token, and What’s Changed in 2026

Snowflake Openflow is an integration service that connects virtually any data source to any destination, using hundreds of processors that support both structured and unstructured data, including text, images, audio, video, and sensor data. Built on Apache NiFi, Openflow lets you run a fully managed service inside your own cloud environment, giving you complete control over your data operations while Snowflake handles the heavy lifting of managing the service itself (Snowflake Openflow documentation).

Since Openflow was first introduced, it’s moved well past initial availability. According to Snowflake’s official Openflow documentation, it’s now generally available for Snowflake Deployments across AWS, Azure, and GCP commercial regions, and BYOC deployments are available to all accounts in AWS commercial regions. A newer generation of the platform has also arrived, along with a more streamlined authentication model. Here’s an updated look at what Openflow is, how it’s architected, and where it fits.

Key Features and Benefits

Open and extensible Openflow is powered by Apache NiFi, giving developers the ability to build and extend processors connecting any data source to any destination. This makes it easy to adapt pipelines as business needs evolve, rather than being boxed in by a fixed connector catalog.

Unified data integration platform Openflow gives data engineers a single, fully managed service for complex, bi-directional data extraction and loading, deployable either inside your own VPC or within your Snowflake deployment.

Enterprise-ready Security, compliance, observability, and maintainability come built in, rather than bolted on. More on what that actually includes below.

High-speed ingestion of all data types One platform handles structured and unstructured data, in both batch and streaming modes, at virtually any scale, from source straight into Snowflake.

Continuous multimodal ingestion for AI Near real-time ingestion of unstructured data from sources like SharePoint and Google Drive means you can chat with that data almost as soon as it lands, a key building block for AI-driven workflows.

What’s New: Gen 1 and Gen 2

This is the biggest development since Openflow’s initial release. Per the Openflow documentation, Openflow deployments, both BYOC and Snowflake-hosted, now come in two generations:

• Gen 1 is the original model.
• Gen 2 (currently in public preview) introduces SQL-first management of deployments, runtimes, and connectors, meaning you can manage Openflow infrastructure using the same SQL-based workflows you already use elsewhere in Snowflake.

Which generation you get isn’t something you choose manually per deployment: accounts enabled for public preview features get gen 2 for any new deployment; everyone else is on gen 1. If you’re planning new Openflow work, it’s worth checking which generation your account will land on, since gen 2’s SQL-first approach changes how you’ll operationalize deployments and runtimes.

Deployment Types

Openflow supports two deployment models, and it’s worth being precise about what each one actually is (earlier coverage of Openflow has sometimes blurred this with “cloud or on-premises,” which isn’t quite accurate). Snowflake’s documentation lays out both models in detail on the About Openflow page:

Openflow: Snowflake Deployment Runs on Snowpark Container Services (SPCS), making it a self-contained, easy-to-deploy option that lives inside Snowflake itself. Because it’s natively integrated with Snowflake’s security model, authentication, authorization, and network security are largely handled for you: a convenient, cost-effective way to run data flows without standing up separate infrastructure.

Openflow: Bring Your Own Cloud (BYOC) The data processing engine (the “data plane”) runs inside your own cloud environment, while Snowflake manages the overall service and control plane. This is the right fit when you need to handle sensitive data preprocessing locally, within your organization’s own cloud boundary, before it ever reaches Snowflake.

Authentication: Snowflake Managed Token

One of the more significant additions since Openflow launched is Snowflake Managed Token, now the default and recommended way for Openflow runtimes to authenticate to Snowflake.

Why it matters:

• Simplified configuration: no more generating, storing, and rotating long-lived key pairs; Snowflake manages the token automatically.
• Consistent across deployment types: the same SNOWFLAKE_MANAGED authentication strategy works whether you’re running SPCS or BYOC.
• Better security posture: tokens are short-lived and refreshed automatically, shrinking the window of exposure if credentials ever leak.

Under the hood, the mechanism differs slightly by deployment type: Snowflake Deployments use SPCS session tokens natively, with no extra configuration needed, while BYOC deployments use workload identity federation, exchanging a cloud-provider identity (like an AWS IAM role) for a Snowflake token. BYOC deployments still support key-pair authentication if you need explicit credential management, but Managed Token is the recommended path for new configurations and for migrating off key pairs.

Security

Openflow’s security model has filled out considerably and now spans several concrete areas, as detailed in the Security section of Snowflake’s documentation:

• Authorization: fine-grained RBAC, with ACCOUNTADMIN required to grant privileges for creating deployments and runtimes.
• Encryption in transit: TLS across connectors and between Openflow deployments and the control plane.
• Secrets management: integration with Snowflake secrets across both deployment types, plus AWS Secrets Manager or HashiCorp Vault support for BYOC.
• Private connectivity: inbound AWS PrivateLink for BYOC, or outbound private connectivity for Snowflake deployments.
• Tri-Secret Secure support: for encrypting data written to Snowflake.

Taken together, this is a materially more detailed security story than “enterprise-ready” as a label, worth knowing if you’re building a case for Openflow with a security or compliance team.

Architecture

Openflow’s architecture breaks down into a few core pieces:

• Deployments: where your data flows actually execute, organized into individual runtimes. You’ll typically run multiple runtimes under one deployment to isolate different teams, projects, or SDLC stages.
• Control plane: the layer that manages and observes Openflow runtimes, including the service and API you interact with through the Openflow canvas.
• Runtimes: where data pipelines actually run, hosting both prebuilt Openflow connectors and custom pipelines built from NiFi processors and controller services.

A deployment agent installs and bootstraps the infrastructure in your VPC and keeps container images in sync with Snowflake’s system image registry, so once it’s set up, staying current doesn’t require much manual intervention.

Use Cases

Openflow is aimed at situations where you want to move data from any source to any destination with minimal management overhead, while inheriting Snowflake’s built-in governance and security. Per the documentation’s use cases section, in practice that shows up as:

• Ingesting unstructured data from sources like Google Drive and Box and making it chat-ready via Snowflake Cortex, or feeding it into your own custom processing.
• Replicating change data capture (CDC) from database tables into Snowflake for centralized reporting.
• Streaming real-time events from platforms like Apache Kafka into Snowflake for near real-time analytics.
• Pulling data from SaaS platforms, LinkedIn Ads is one example, into Snowflake for reporting and insights.
• Building custom dataflows from scratch using Snowflake and NiFi processors and controller services.

FAQ

Is Snowflake Openflow generally available? Yes. Openflow Snowflake Deployments are generally available to all accounts in AWS, Azure, and GCP commercial regions. Openflow BYOC deployments are generally available to all accounts in AWS commercial regions (Snowflake documentation).

What’s the difference between Openflow gen 1 and gen 2? Gen 1 is the original deployment model. Gen 2, currently in public preview, adds SQL-first management of deployments, runtimes, and connectors. Which one you get isn’t a manual choice: accounts enabled for public preview features get gen 2 for any new deployment, and everyone else stays on gen 1 (gen 1 vs. gen 2 comparison).

What’s the difference between Openflow Snowflake Deployment and BYOC? Openflow – Snowflake Deployment runs on Snowpark Container Services (SPCS) as a self-contained service inside Snowflake, with authentication, authorization, and network security natively integrated into Snowflake’s security model. BYOC (Bring Your Own Cloud) runs the data processing engine, or data plane, inside your own cloud environment, while Snowflake manages the overall service and control plane. Neither is an on-premises deployment option.

Does Openflow work with trial accounts? No. Openflow isn’t automatically available in trial accounts; you need to contact your Snowflake account team to enable it.

What authentication method should I use for Openflow? Snowflake Managed Token is the default and recommended method for Openflow runtimes to authenticate to Snowflake, and it works consistently across both SPCS and BYOC deployments. BYOC deployments can alternatively use key-pair authentication when explicit credential management is required.

Is Openflow suitable for unstructured data and AI workflows? Yes. Openflow supports near real-time ingestion of multimodal data, including unstructured sources like SharePoint and Google Drive, which can then be made available for AI processing, such as chat, through Snowflake Cortex.

Where can I find the authoritative, up-to-date details? Always check Snowflake’s own documentation, About Openflow, since features, availability, and preview status change over time.

Quick Summary

Openflow has grown up quite a bit since its initial release: it’s GA in more regions, has a second generation on the way with SQL-first management, and has a much more concrete security and authentication story than the early messaging suggested. If you evaluated it early and passed, or you’re building a fresh case for it now, it’s worth another look, particularly if SQL-first management (gen 2) or Managed Token authentication solves a pain point you were previously working around.