Hey team, , are there any caveats to watch out for if process type worker is deployed in production ? Coz the docs page says this it typically used for getting started / testing purposes. Thanks!

Hey there, can you point me to the docs you’re looking at? There might be an opportunity for us to update it

Hey @Aditya N, you can use the process worker in production, but there is more responsibility that you’ll need to take on to ensure the worker remains active. For other work types (e.g., Kubernetes) the underlying infrastructure can make sure that the worker stays active and the infrastructure executing flow runs is more separate from the infrastructure running the worker. We recommend running the worker process with a running that will restart the worker process if it fails (e.g. systemd) and running it on infrastructure that can self-heal (e.g. an EC2 auto-scaling group). The process worker works well for local execution because it can be run locally without setting up any other infrastructure.

@alex thanks for the response. So I would be running the worker as a pod in an k8s cluster using (https://github.com/PrefectHQ/prefect-helm/blob/main/charts/prefect-worker/values.yaml) configuration to start with.

Are the flow runs for your deployment created by a schedule or are they event-driven?

@alex Would most likely involve a combination of both

Gotcham you can use the

--prefetch-seconds

flag on the

prefect worker start

command to specify the number of seconds in the future that a worker will poll for scheduled flow runs which can help account for the delay in spinning infrastructure. However, that will only work for scheduled flow runs. For ad-hoc flow runs you’ll need to use the process worker in order to get the lowest possible latency.

Right so I guess I could go ahead with the

process

worker for now