Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Prefect Community

is there a doc for setting up controlflow to work w/ prefect cloud?

hi <@U07NWDR0T5G>, im not sure there is but all you have to do is change the server you're talking to

`prefect cloud login` should do it

or setup a profile and switch to your cloud profile

<https://docs.prefect.io/v3/develop/settings-and-profiles#configure-settings-for-the-active-profile>

thanks <@U02GMEZU18B>. we're starting with controlflow (not current users of prefect flows) but now curious to see if it makes more sense to adopt prefect as the orchestration layer that includes cf flows but other steps as well.  are there any small simple examples that demontrate this?

> are there any small simple examples that demontrate this?
can you be more specific about what type of examples you're looking for? for example, i have:
• a getting started w prefect yt <https://www.youtube.com/playlist?list=PLWkgBUKPlwvCV5FdBGsDE16K2DSelOy9i|playlist> 
• a template <https://github.com/zzstoatzz/prefect-pack|repo> with common boilerplate for making deployments
• an <https://github.com/PrefectHQ/ControlFlow/blob/ca314f87ffe8a286ba070100ad6aa1763c6306b9/examples/read_hn.py|example> of deploying prefect flows that happen to call cf code (pattern I recommend)

in the example you have, why wasn't it entirely a cf flow with a hn tool?

actually, let me back up a bit. I'll read through the general prefect docs since i can get my questions answered for general purpose workflow. the immediate problem we're trying to solve is actually an ephemeral prefect server that's being spun up (we're exclusively only using CF right now for agent flows) and is causing some serious memory footprint issues in our deployments

i think i could invert the question: why would it be? in my mind there's no good reason for it to be, because what I want from `prefect.flow` is just to encapsulate my work and then deploy that thing as the entrypoint using normal prefect

this is the mental model I would recommend bc its resilient in the sense that if next week you decided to switch from controlflow to pydantic-ai

you'd still be doing the same thing

```@prefect.flow
def do_ai_stuff():
   # a bunch of ai stuff

do_ai_stuff.deploy()```

so my thought was naturally to sign up for cloud and set the PREFECT_API_URL so the CF flows can be remotely managed

right, its interesting b/c we have an existing other workflow engine (not prefect)

so our case is actually inverted from yours

ideally, if it was all prefect driven, i agree

the tension here is now we have 2 workflow solutions to contend with

b/c we started with CF as a _fully contained_ solution for LLM driven flows

&gt; so my thought was naturally to sign up for cloud and set the PREFECT_API_URL so the CF flows can be remotely managed
makes sense, not going to discourage you from cloud :slightly_smiling_face: but i'd also mention you can

start an open source server
```docker run -p 4200:4200 -d --rm prefecthq/prefect:3-latest -- prefect server start --host 0.0.0.0```
or more simply, just `prefect server start` in another terminal

then wherever you run controlflow you can set `PREFECT_API_URL=<http://localhost:4200/api>`

or instead if you go cloud route you can do `prefect cloud login`

&gt; the tension here is now we have 2 workflow solutions to contend with
this is a common tension. I would just try prefect in greenfield  / low stakes situations and see what you think. i will say that people often say prefect is easy to incrementally adopt, so that could ease some of the tension