Files
crewAI/docs/edge/en/enterprise/guides/monorepo-deployments.mdx
Lucas Gomide a237ebabba feat: adopt directory-based docs versioning with Edge channel (#6202)
* 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>
2026-06-17 11:56:59 -04:00

230 lines
6.5 KiB
Plaintext

---
title: "Monorepo Deployments"
description: "Deploy a Crew or Flow from a subfolder in a larger repository"
icon: "folder-tree"
mode: "wide"
---
<Note>
Use a working directory when your Crew or Flow lives inside a larger
repository. CrewAI AMP validates, builds, tests, and runs the automation from
that subfolder instead of the repository root.
</Note>
## When to Use This
Monorepo deployments are useful when one repository contains multiple
automations, shared packages, or other application code:
```text
company-ai/
|-- uv.lock
|-- packages/
| `-- shared_tools/
`-- crews/
|-- support_agent/
| |-- pyproject.toml
| |-- crew.jsonc
| `-- agents/
| `-- support_agent.jsonc
`-- research_flow/
|-- pyproject.toml
`-- src/
`-- research_flow/
`-- main.py
```
To deploy `support_agent`, set the working directory to:
```text
crews/support_agent
```
AMP still pulls or uploads the whole repository, but it treats the selected
folder as the automation project root.
## What the Working Directory Controls
When a working directory is set, AMP uses that folder for:
- Project validation, including `pyproject.toml`, JSON crew files, and any classic Crew or Flow entry point
- Dependency installation with `uv`
- The running process working directory
- The `CREW_ROOT_DIR` environment variable
Leaving the field empty keeps the existing behavior and uses the repository
root.
## Supported Sources
You can set a working directory when creating a deployment from:
- A connected GitHub repository
- A Git repository configured in AMP
- A ZIP upload
<Info>
Configure working directories in the AMP web interface. The
`crewai deploy create` CLI flow does not prompt for this field.
</Info>
You can also add or change the working directory on an existing deployment from
the deployment's **Settings** page. The change takes effect on the next deploy.
<Warning>
Working directories and auto-deploy cannot be used together. If a deployment
has a working directory, auto-deploy is disabled for that deployment. Turn
auto-deploy off before setting a working directory.
</Warning>
## Configure a New Deployment
<Steps>
<Step title="Open Deploy from Code">
In CrewAI AMP, create a new deployment and choose your source: GitHub, Git
Repository, or ZIP upload.
</Step>
<Step title="Select the repository, branch, or ZIP file">
Choose the repository and branch that contain your monorepo, or upload a ZIP
file whose root contains the monorepo contents.
</Step>
<Step title="Open Advanced settings">
Expand the **Advanced** section in the deploy form.
</Step>
<Step title="Enter the working directory">
Enter the path from the repository root to the Crew or Flow project:
```text
crews/support_agent
```
Do not include a leading slash.
</Step>
<Step title="Deploy">
Add any required environment variables, then start the deployment.
</Step>
</Steps>
## Configure an Existing Deployment
<Steps>
<Step title="Open the deployment settings">
Go to your automation in AMP and open **Settings**.
</Step>
<Step title="Turn off auto-deploy if needed">
If auto-deploy is enabled, disable it first. The working directory field is
unavailable while auto-deploy is on.
</Step>
<Step title="Set the working directory">
In **Basic settings**, enter the subfolder path, such as:
```text
crews/support_agent
```
</Step>
<Step title="Redeploy">
Save the setting and redeploy the automation. The new working directory is
used on the next deploy.
</Step>
</Steps>
## Path Rules
The working directory must be a relative path inside the repository or ZIP root.
| Rule | Example |
|------|---------|
| Use a relative path | `crews/support_agent` |
| Do not start with `/` | `/crews/support_agent` is invalid |
| Do not use `.` or `..` path segments | `crews/../support_agent` is invalid |
| Use only letters, numbers, dashes, underscores, dots, and forward slashes | `crews/support agent` is invalid |
| Keep the path at 255 characters or fewer | Longer paths are rejected |
AMP trims leading and trailing whitespace, collapses repeated slashes, and
removes trailing slashes. A blank value uses the repository root.
## Lock Files and UV Workspaces
The selected folder must contain the automation's `pyproject.toml` and the
project files for its type:
- JSON-first crew: `crew.jsonc` or `crew.json`, plus `agents/`
- Classic crew or Flow: `src/` with the expected Python entry point
A `uv.lock` or `poetry.lock` file can live either in the selected folder or at
the repository root.
This supports both common lock-file layouts:
<Tabs>
<Tab title="Project lock file">
```text
company-ai/
`-- crews/
`-- support_agent/
|-- pyproject.toml
|-- uv.lock
|-- crew.jsonc
`-- agents/
`-- support_agent.jsonc
```
</Tab>
<Tab title="Workspace lock file">
```text
company-ai/
|-- uv.lock
|-- packages/
| `-- shared_tools/
`-- crews/
`-- support_agent/
|-- pyproject.toml
|-- crew.jsonc
`-- agents/
`-- support_agent.jsonc
```
</Tab>
</Tabs>
<Tip>
If your automation imports shared packages from elsewhere in the monorepo,
declare those packages in `pyproject.toml` using UV workspace, path, or source
configuration. AMP runs the automation from the selected folder, so shared
code should be installed as a dependency instead of relying on the repository
root being on the Python path.
</Tip>
## Troubleshooting
### Working Directory Not Found
Check that the path is relative to the repository or ZIP root. For ZIP uploads,
the ZIP contents must include the working directory path exactly as entered.
### Missing pyproject.toml
The working directory should point to the Crew or Flow project folder, not just
to a parent folder that contains several projects.
### Missing uv.lock or poetry.lock
Commit a lock file either in the selected project folder or in the repository
root. For UV workspaces, keeping `uv.lock` at the workspace root is supported.
### Auto-Deploy Is Unavailable
Auto-deploy is disabled while a working directory is set. Use manual redeploys
or trigger redeployments from CI/CD with the AMP API instead.
<Card title="Deploy to AMP" icon="rocket" href="/en/enterprise/guides/deploy-to-amp">
Continue with the deployment guide after choosing your monorepo working
directory.
</Card>