Deployment
A notebook kickoff is not a product. Users need auth, a job id, progress, and a place the logs go.
A restaurant: the dining room never walks into the kitchen. A ticket rail sits in between.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Scroll inside the frame to explore · use + / − to zoom up to 200%
Key Takeaways
- 1.Ship CrewAI like any Python service: FastAPI in front, Flow or Crew behind, tools below, a database beside. kickoff is often too slow for the request thread — run it as a background job and poll status.
- 2.Docker, env vars, persistence, and monitoring are the deploy checklist. The frontend talks to your API, not to CrewAI.
- 3.POST /jobs starts the crew on a worker. Persist job id.
- 4.Secrets only in env. One Docker image.
- 5.CrewAI is a library inside the worker, not a server you expose.
Learn elsewhere
- →AG-UI — Phase 22
- →Production — Phase 21
- →Build a Research Crew
Real Example
Scenario
User types a topic in the app → API enqueues a research crew → UI shows researcher then writer → report.md when the job succeeds.
What you would do
In CrewAI, apply Deployment to this scenario: User types a topic in the app → API enqueues a research crew → UI shows researcher then writer → report. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
API in frontCrew on a workerPersist job stateDo not expose CrewAI
Cheat Sheet
Quick recap
quick ref- •BFF + worker
- •Env secrets
- •Job id
- •Monitor the run
Common Mistakes
- ✕Skipping evaluation for Deployment before production
- ✕No logging or tracing around crewai deployment steps
- ✕Ignoring cost and latency implications