mirror of
https://github.com/crewAIInc/crewAI.git
synced 2026-07-28 18:19:22 +00:00
* feat: adopt directory-based docs versioning with Edge channel Switch docs.crewai.com from navigation-only versioning (every version selector entry rendered the same docs/<lang>/* source files) to Mintlify's directory-based versioning so each version selector entry renders its own snapshot. Add an "Edge" channel under docs/edge/<lang>/* that always reflects main HEAD for unreleased work, eliminating pre-release leakage onto frozen release labels. External links to canonical /<lang>/* URLs are preserved via wildcard redirects that always land on the current default version. Layout: - docs/edge/<lang>/* rolling source (you edit here) - docs/edge/enterprise-api.*.yaml - docs/v<X.Y.Z>/<lang>/* frozen, immutable snapshots - docs/v<X.Y.Z>/enterprise-api.*.yaml - docs/images/ shared, append-only - docs/docs.json nav + redirects URLs follow the Mintlify-idiomatic shape: /edge/<lang>/<page> for Edge, /v<X.Y.Z>/<lang>/<page> for every frozen snapshot. The wildcard redirects /<lang>/:slug* -> /<default>/<lang>/:slug* keep stale links working, and every freeze rewrites them (plus all per-section/per-page redirects) so destinations always resolve to the current default without depending on a second redirect hop. Release flow integration (devtools release): - New module crewai_devtools.docs_versioning.freeze() materialises docs/v<X.Y.Z>/ from docs/edge/, rewrites openapi: refs inside the snapshot, inserts the version into every language block in docs.json, and refreshes all redirect destinations. - _update_docs_and_create_pr() in cli.py now calls that freeze during Phase 2 of devtools release. Edge changelogs are updated first (so the snapshot freeze picks them up), then the snapshot is staged alongside docs.json, branched as docs/freeze-v<X.Y.Z>, and the PR is titled [docs-freeze] docs: snapshot and changelog for v<X.Y.Z> — the title prefix the new CI guard reads. - The PR still gates tag, GitHub release, PyPI publish, and the enterprise release as before; no new PRs are added. - Pre-releases (1.X.YaN, 1.X.YbN, ...) skip the snapshot — they ride Edge — and the docs PR title omits the [docs-freeze] prefix. - docs_check (AI-generated docs scaffolding) writes to docs/edge/<lang>/* so newly-generated unreleased docs land in Edge and never accidentally touch a frozen snapshot. Migration scripts (one-shot): - scripts/docs/freeze_historical_versions.py reconstructs all 16 historical snapshots (v1.10.0 .. v1.14.7) from git tags via git archive | tar, rewriting openapi: MDX refs so each snapshot reads its own enterprise-api YAML rather than the live one. - scripts/docs/prefix_version_paths.py one-shot-migrates docs.json: rewrites every page path in 16 versioned blocks to point under docs/v<X.Y.Z>/, inserts a new Edge entry per language, tags v1.14.7 as Latest (default), prunes pages whose target file doesn't exist in the snapshot (e.g. docs/ar/ didn't exist before v1.12.0), and writes the wildcard + per-section redirects. - scripts/docs/freeze_current_edge.py is now a thin CLI wrapper around docs_versioning.freeze for manual one-off freezes (e.g. retroactively snapshotting a forgotten release). CI guards (.github/workflows/docs-snapshots.yml): - Frozen snapshots under docs/v[0-9]*/ are immutable; only PRs whose title contains [docs-freeze] (i.e. release-cut PRs generated by devtools release or the manual wrapper) may modify them. - Images under docs/images/ are append-only since snapshots share a single image directory. Deleting or renaming an image breaks every historical snapshot that still references it. Restored docs/images/crewai-otel-export.png from PR #3673; it was deleted in PR #4908 but v1.10.0 / v1.10.1 snapshots still reference it. Restoring instead of editing the snapshots preserves historical rendering fidelity and validates the new append-only rule retroactively. Tests: - lib/devtools/tests/test_docs_versioning.py covers the freeze: file copy, openapi rewrite, version insertion, default demotion, redirect upserts, per-section redirect rewriting, idempotency, and invalid inputs. Verified locally with mintlify broken-links: 0 broken links across the full site (Edge + 16 frozen versions, 4 locales). AGENTS.md (repo root) is the contributor guide for the new model; RELEASING.md is the release-cut runbook; README's Contribution section links to both. Co-authored-by: Cursor <cursoragent@cursor.com> * style: resolve linter issues --------- Co-authored-by: Cursor <cursoragent@cursor.com>
312 lines
9.1 KiB
Plaintext
312 lines
9.1 KiB
Plaintext
---
|
|
title: "Prepare for Deployment"
|
|
description: "Ensure your Crew or Flow is ready for deployment to CrewAI AMP"
|
|
icon: "clipboard-check"
|
|
mode: "wide"
|
|
---
|
|
|
|
<Note>
|
|
Before deploying to CrewAI AMP, it's crucial to verify your project is correctly structured.
|
|
Both Crews and Flows can be deployed as "automations," but they have different project structures
|
|
and requirements that must be met for successful deployment.
|
|
</Note>
|
|
|
|
## Understanding Automations
|
|
|
|
In CrewAI AMP, **automations** is the umbrella term for deployable Agentic AI projects. An automation can be either:
|
|
|
|
- **A Crew**: A standalone team of AI agents working together on tasks
|
|
- **A Flow**: An orchestrated workflow that can combine multiple crews, direct LLM calls, and procedural logic
|
|
|
|
Understanding which type you're deploying is essential because they have different project structures and entry points.
|
|
|
|
## Crews vs Flows: Key Differences
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Crew Projects" icon="users">
|
|
Standalone AI agent teams with `crew.py` defining agents and tasks. Best for focused, collaborative tasks.
|
|
</Card>
|
|
<Card title="Flow Projects" icon="diagram-project">
|
|
Orchestrated workflows with embedded crews in a `crews/` folder. Best for complex, multi-stage processes.
|
|
</Card>
|
|
</CardGroup>
|
|
|
|
| Aspect | Crew | Flow |
|
|
|--------|------|------|
|
|
| **Project structure** | `src/project_name/` with `crew.py` | `src/project_name/` with `crews/` folder |
|
|
| **Main logic location** | `src/project_name/crew.py` | `src/project_name/main.py` (Flow class) |
|
|
| **Entry point function** | `run()` in `main.py` | `kickoff()` in `main.py` |
|
|
| **pyproject.toml type** | `type = "crew"` | `type = "flow"` |
|
|
| **CLI create command** | `crewai create crew name` | `crewai create flow name` |
|
|
| **Config location** | `src/project_name/config/` | `src/project_name/crews/crew_name/config/` |
|
|
| **Can contain other crews** | No | Yes (in `crews/` folder) |
|
|
|
|
## Project Structure Reference
|
|
|
|
### Crew Project Structure
|
|
|
|
When you run `crewai create crew my_crew`, you get this structure:
|
|
|
|
```
|
|
my_crew/
|
|
├── .gitignore
|
|
├── pyproject.toml # Must have type = "crew"
|
|
├── README.md
|
|
├── .env
|
|
├── uv.lock # REQUIRED for deployment
|
|
└── src/
|
|
└── my_crew/
|
|
├── __init__.py
|
|
├── main.py # Entry point with run() function
|
|
├── crew.py # Crew class with @CrewBase decorator
|
|
├── tools/
|
|
│ ├── custom_tool.py
|
|
│ └── __init__.py
|
|
└── config/
|
|
├── agents.yaml # Agent definitions
|
|
└── tasks.yaml # Task definitions
|
|
```
|
|
|
|
<Warning>
|
|
The nested `src/project_name/` structure is critical for Crews.
|
|
Placing files at the wrong level will cause deployment failures.
|
|
</Warning>
|
|
|
|
### Flow Project Structure
|
|
|
|
When you run `crewai create flow my_flow`, you get this structure:
|
|
|
|
```
|
|
my_flow/
|
|
├── .gitignore
|
|
├── pyproject.toml # Must have type = "flow"
|
|
├── README.md
|
|
├── .env
|
|
├── uv.lock # REQUIRED for deployment
|
|
└── src/
|
|
└── my_flow/
|
|
├── __init__.py
|
|
├── main.py # Entry point with kickoff() function + Flow class
|
|
├── crews/ # Embedded crews folder
|
|
│ └── poem_crew/
|
|
│ ├── __init__.py
|
|
│ ├── poem_crew.py # Crew with @CrewBase decorator
|
|
│ └── config/
|
|
│ ├── agents.yaml
|
|
│ └── tasks.yaml
|
|
└── tools/
|
|
├── __init__.py
|
|
└── custom_tool.py
|
|
```
|
|
|
|
<Info>
|
|
Both Crews and Flows use the `src/project_name/` structure.
|
|
The key difference is that Flows have a `crews/` folder for embedded crews,
|
|
while Crews have `crew.py` directly in the project folder.
|
|
</Info>
|
|
|
|
## Pre-Deployment Checklist
|
|
|
|
Use this checklist to verify your project is ready for deployment.
|
|
|
|
### 1. Verify pyproject.toml Configuration
|
|
|
|
Your `pyproject.toml` must include the correct `[tool.crewai]` section:
|
|
|
|
<Tabs>
|
|
<Tab title="For Crews">
|
|
```toml
|
|
[tool.crewai]
|
|
type = "crew"
|
|
```
|
|
</Tab>
|
|
<Tab title="For Flows">
|
|
```toml
|
|
[tool.crewai]
|
|
type = "flow"
|
|
```
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
<Warning>
|
|
If the `type` doesn't match your project structure, the build will fail or
|
|
the automation won't run correctly.
|
|
</Warning>
|
|
|
|
### 2. Ensure uv.lock File Exists
|
|
|
|
CrewAI uses `uv` for dependency management. The `uv.lock` file ensures reproducible builds and is **required** for deployment.
|
|
|
|
```bash
|
|
# Generate or update the lock file
|
|
uv lock
|
|
|
|
# Verify it exists
|
|
ls -la uv.lock
|
|
```
|
|
|
|
If the file doesn't exist, run `uv lock` and commit it to your repository:
|
|
|
|
```bash
|
|
uv lock
|
|
git add uv.lock
|
|
git commit -m "Add uv.lock for deployment"
|
|
git push
|
|
```
|
|
|
|
### 3. Validate CrewBase Decorator Usage
|
|
|
|
**Every crew class must use the `@CrewBase` decorator.** This applies to:
|
|
|
|
- Standalone crew projects
|
|
- Crews embedded inside Flow projects
|
|
|
|
```python
|
|
from crewai import Agent, Crew, Process, Task
|
|
from crewai.project import CrewBase, agent, crew, task
|
|
from crewai.agents.agent_builder.base_agent import BaseAgent
|
|
from typing import List
|
|
|
|
@CrewBase # This decorator is REQUIRED
|
|
class MyCrew():
|
|
"""My crew description"""
|
|
|
|
agents: List[BaseAgent]
|
|
tasks: List[Task]
|
|
|
|
@agent
|
|
def my_agent(self) -> Agent:
|
|
return Agent(
|
|
config=self.agents_config['my_agent'], # type: ignore[index]
|
|
verbose=True
|
|
)
|
|
|
|
@task
|
|
def my_task(self) -> Task:
|
|
return Task(
|
|
config=self.tasks_config['my_task'] # type: ignore[index]
|
|
)
|
|
|
|
@crew
|
|
def crew(self) -> Crew:
|
|
return Crew(
|
|
agents=self.agents,
|
|
tasks=self.tasks,
|
|
process=Process.sequential,
|
|
verbose=True,
|
|
)
|
|
```
|
|
|
|
<Warning>
|
|
If you forget the `@CrewBase` decorator, your deployment will fail with
|
|
errors about missing agents or tasks configurations.
|
|
</Warning>
|
|
|
|
### 4. Check Project Entry Points
|
|
|
|
Both Crews and Flows have their entry point in `src/project_name/main.py`:
|
|
|
|
<Tabs>
|
|
<Tab title="For Crews">
|
|
The entry point uses a `run()` function:
|
|
|
|
```python
|
|
# src/my_crew/main.py
|
|
from my_crew.crew import MyCrew
|
|
|
|
def run():
|
|
"""Run the crew."""
|
|
inputs = {'topic': 'AI in Healthcare'}
|
|
result = MyCrew().crew().kickoff(inputs=inputs)
|
|
return result
|
|
|
|
if __name__ == "__main__":
|
|
run()
|
|
```
|
|
</Tab>
|
|
<Tab title="For Flows">
|
|
The entry point uses a `kickoff()` function with a Flow class:
|
|
|
|
```python
|
|
# src/my_flow/main.py
|
|
from crewai.flow import Flow, listen, start
|
|
from my_flow.crews.poem_crew.poem_crew import PoemCrew
|
|
|
|
class MyFlow(Flow):
|
|
@start()
|
|
def begin(self):
|
|
# Flow logic here
|
|
result = PoemCrew().crew().kickoff(inputs={...})
|
|
return result
|
|
|
|
def kickoff():
|
|
"""Run the flow."""
|
|
MyFlow().kickoff()
|
|
|
|
if __name__ == "__main__":
|
|
kickoff()
|
|
```
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
### 5. Prepare Environment Variables
|
|
|
|
Before deployment, ensure you have:
|
|
|
|
1. **LLM API keys** ready (OpenAI, Anthropic, Google, etc.)
|
|
2. **Tool API keys** if using external tools (Serper, etc.)
|
|
|
|
<Info>
|
|
If your project depends on packages from a **private PyPI registry**, you'll also need to configure
|
|
registry authentication credentials as environment variables. See the
|
|
[Private Package Registries](/en/enterprise/guides/private-package-registry) guide for details.
|
|
</Info>
|
|
|
|
<Tip>
|
|
Test your project locally with the same environment variables before deploying
|
|
to catch configuration issues early.
|
|
</Tip>
|
|
|
|
## Quick Validation Commands
|
|
|
|
Run these commands from your project root to quickly verify your setup:
|
|
|
|
```bash
|
|
# 1. Check project type in pyproject.toml
|
|
grep -A2 "\[tool.crewai\]" pyproject.toml
|
|
|
|
# 2. Verify uv.lock exists
|
|
ls -la uv.lock || echo "ERROR: uv.lock missing! Run 'uv lock'"
|
|
|
|
# 3. Verify src/ structure exists
|
|
ls -la src/*/main.py 2>/dev/null || echo "No main.py found in src/"
|
|
|
|
# 4. For Crews - verify crew.py exists
|
|
ls -la src/*/crew.py 2>/dev/null || echo "No crew.py (expected for Crews)"
|
|
|
|
# 5. For Flows - verify crews/ folder exists
|
|
ls -la src/*/crews/ 2>/dev/null || echo "No crews/ folder (expected for Flows)"
|
|
|
|
# 6. Check for CrewBase usage
|
|
grep -r "@CrewBase" . --include="*.py"
|
|
```
|
|
|
|
## Common Setup Mistakes
|
|
|
|
| Mistake | Symptom | Fix |
|
|
|---------|---------|-----|
|
|
| Missing `uv.lock` | Build fails during dependency resolution | Run `uv lock` and commit |
|
|
| Wrong `type` in pyproject.toml | Build succeeds but runtime fails | Change to correct type |
|
|
| Missing `@CrewBase` decorator | "Config not found" errors | Add decorator to all crew classes |
|
|
| Files at root instead of `src/` | Entry point not found | Move to `src/project_name/` |
|
|
| Missing `run()` or `kickoff()` | Cannot start automation | Add correct entry function |
|
|
|
|
## Next Steps
|
|
|
|
Once your project passes all checklist items, you're ready to deploy:
|
|
|
|
<Card title="Deploy to AMP" icon="rocket" href="/en/enterprise/guides/deploy-to-amp">
|
|
Follow the deployment guide to deploy your Crew or Flow to CrewAI AMP using
|
|
the CLI, web interface, or CI/CD integration.
|
|
</Card>
|