Every Prefect deployment needs an execution environment. Traditionally, that execution layer lives outside of Snowflake on infrastructure such as Kubernetes, Amazon ECS, or virtual machines. While these approaches are common and effective, they introduce additional operational responsibilities. Teams must provision and maintain compute resources, configure networking, manage credentials, and operate a separate platform alongside their data environment.

Snowpark Container Services (SPCS) offers a different approach. Instead of deploying Prefect workers on external infrastructure, organizations can run them directly within Snowflake. In this model, Prefect Cloud continues to provide orchestration, scheduling, observability, and automation, while Snowflake becomes the managed execution environment where workflows actually run.

This architecture is particularly appealing for teams that already rely on Snowflake as the center of their data platform. By colocating workflow execution with data, organizations can simplify infrastructure management while benefiting from Snowflake-native security, governance, and authentication capabilities.

In this guide, we will deploy a Prefect worker on Snowpark Container Services, connect it to Prefect Cloud, and execute a production-style workflow to demonstrate the pattern in practice. While the example workflow focuses on fraud detection and model retraining, the broader architecture applies equally well to data pipelines, operational automation, agent orchestration, and other workflow-driven use cases.

At a high level, Prefect Cloud remains the orchestration control plane. It is responsible for scheduling deployments, tracking flow state, managing automations, and providing visibility into workflow execution. The Prefect worker, however, runs inside Snowflake on Snowpark Container Services.

The worker continuously polls Prefect Cloud for work. When a deployment is triggered, the worker executes the corresponding flow within Snowflake's managed infrastructure. From there, the workflow can interact with Snowflake resources such as tables, stages, and Cortex services, while also communicating with approved external systems through Snowflake's networking controls.

This separation of responsibilities creates a clean operating model. Prefect Cloud handles orchestration and workflow management, while Snowpark Container Services provides the execution environment. The result is a familiar Prefect experience without the need to maintain a separate container platform or orchestration infrastructure.

Running Prefect workers on Snowpark Container Services offers several practical advantages beyond simply changing where containers run.

The first benefit is operational simplicity. Rather than managing Kubernetes clusters, virtual machines, or container services outside of Snowflake, teams can deploy workers using Snowflake-native infrastructure. This reduces the number of platforms that must be operated and monitored while keeping workflow execution close to the data it depends on.

Another advantage is authentication. Containers running on SPCS can receive Snowflake OAuth credentials automatically, eliminating the need to distribute passwords, rotate keys, or manage additional secrets for accessing Snowflake resources. This simplifies both development and ongoing operations while aligning with Snowflake's security model.

Network access is also tightly controlled. Through External Access Integrations, administrators can explicitly define which external services a worker is allowed to communicate with. This provides a clear governance model for workflows that need to interact with APIs, messaging platforms, or other external systems.

Finally, there is the concept of data gravity. Many workflows spend most of their time reading from and writing to Snowflake. Running workers inside Snowflake reduces the need to move data into external execution environments and allows workflows to operate closer to the systems they depend on.

Deploying a Prefect worker on Snowpark Container Services follows the same general pattern as deploying any containerized application on Snowflake.

The process begins by provisioning the required Snowflake infrastructure, including a compute pool to provide container resources and an image repository to store container images. Because the worker must communicate with Prefect Cloud, an External Access Integration is also configured to allow outbound connectivity to approved endpoints.

The compute pool provides the container resources used by the Prefect worker.

Snowflake image repositories store container images used by SPCS services.

Retrieve the repository URL:

The worker must communicate with Prefect Cloud. Create a network rule and External Access Integration to allow outbound connectivity.

Create a simple Docker image containing Prefect and the worker process.

Authenticate Docker with Snowflake and push the image:

Create an SPCS service that runs the Prefect worker.

After deployment, the worker registers with Prefect Cloud and begins polling for work. From Prefect's perspective, it behaves like any other worker. The difference is that execution now occurs entirely within Snowflake's managed container environment.

At this point, Snowpark Container Services has effectively become a managed execution layer for Prefect workflows.

To validate the deployment, this guide uses a fraud detection retraining workflow as an example. The workflow itself is not the primary focus of the guide; rather, it serves as a realistic workload that exercises several important orchestration capabilities.

The workflow begins by performing batch scoring against incoming transactions. It then evaluates model performance and checks for signs of drift. If drift is detected, a retraining process is initiated, producing a challenger model that is compared against the current production model. Depending on the outcome, the workflow may pause for human approval before promoting the new model into production.

At a high level, the workflow looks like this:

This sequence demonstrates several capabilities that are commonly required in production workflows, including retries, long-running execution, durable state management, human-in-the-loop approvals, and pause-and-resume behavior. These features are provided by Prefect, while the execution itself occurs on the worker running inside Snowpark Container Services.

Although fraud detection is the example used here, the same pattern applies to a wide range of workloads. Data engineering pipelines, reverse ETL processes, monitoring jobs, AI agents, and operational workflows can all be executed using the same architecture.

Once the workflow is triggered, execution can be observed through both Prefect Cloud and Snowflake.

Within Prefect Cloud, operators can monitor flow runs, inspect task states, review retries, and track approval pauses or other workflow events. The Prefect interface provides a complete view of orchestration state and execution history, making it easy to understand how a workflow is progressing.

At the same time, Snowflake provides visibility into the underlying service through container logs and operational monitoring tools.

View running services:

Inspect service status:

Retrieve service logs:

Together, Prefect Cloud and Snowpark Container Services provide visibility across both layers of the system: orchestration and execution.

Prefect Cloud and Snowpark Container Services complement each other naturally. Prefect provides the orchestration layer, including scheduling, state management, retries, automations, and observability. Snowpark Container Services provides the execution layer, allowing workflows to run within Snowflake's managed infrastructure while benefiting from Snowflake-native security, authentication, and governance.

The fraud detection workflow used in this guide is only one example of what can be built with this architecture. The same approach can support data pipelines, agent orchestration, reverse ETL workloads, monitoring systems, and a wide variety of operational workflows.

The key takeaway is straightforward: by running Prefect workers on Snowpark Container Services, organizations can keep their workflow execution layer inside Snowflake while continuing to leverage Prefect Cloud as their orchestration control plane.

For a complete, working example of the architecture described in this guide — including the Prefect worker configuration, deployment assets, and sample fraud detection workflow — see the companion repository. It contains the full implementation and can be used as a starting point for adapting the pattern to your own workloads.