feat: add Docker containerization (#455) #489
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdds containerization and CI for backend and frontend: root and frontend .dockerignore files, multi-stage Dockerfiles (backend/frontend), nginx config, production docker-compose, GitHub Actions to build/push images, Docker deployment docs, and a small frontend cleanup. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Dev as Developer
participant GH as GitHub Actions
participant Reg as GHCR
participant Compose as Docker Compose
participant Front as Frontend (nginx)
participant Back as Backend (uvicorn)
rect rgb(240,246,255)
note right of GH: CI: build & push images
Dev->>GH: push / open PR
alt non-PR (main or tag)
GH->>GH: build backend (Buildx, cache)
GH->>Reg: push backend image (sha, latest)
GH->>GH: build frontend (Buildx, cache)
GH->>Reg: push frontend image (sha, latest)
else PR event
GH->>GH: build backend/frontend (no push)
end
end
rect rgb(246,255,240)
note right of Compose: Local/Prod startup
Dev->>Compose: docker compose up
Compose->>Back: start backend container
Back-->>Compose: /health responds (healthy)
Compose->>Front: start frontend (depends_on healthy)
Front->>Back: proxy /api, /health, /docs requests
Back-->>Front: API/docs responses
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @Harshit28j, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the deployability of AgenticFleet by introducing robust Docker containerization. It provides a streamlined way to run the entire application stack, including the Python backend and React frontend, using Docker Compose. The changes focus on creating efficient, production-ready Docker images, automating their publication, and offering clear guidance for users to deploy the application with ease. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive Docker setup for the AgenticFleet project, which is a fantastic addition for improving developer experience and deployment consistency. The use of multi-stage builds for both backend and frontend is a great practice for creating lean production images. The docker-compose.yml effectively orchestrates the services.
My review includes a few suggestions to enhance the setup further. I've pointed out a critical issue in the frontend Dockerfile's healthcheck that would cause container restarts. I've also suggested updating an outdated Jaeger image to mitigate security risks, improving reproducibility by pinning a dependency version, and removing some redundant configuration to keep the files clean and maintainable.
coderabbitai
bot
added
area: config
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive Docker containerization to AgenticFleet, enabling users to run the entire stack (backend, frontend, and optional Jaeger tracing) with docker compose up. The implementation includes multi-stage builds for optimized images, CI/CD integration for automated publishing to GitHub Container Registry, and deployment documentation.
Key Changes:
- Multi-stage Dockerfiles for backend (Python/uv) and frontend (Node/nginx) with production optimizations
- Docker Compose orchestration with service dependencies, health checks, and optional tracing profile
- GitHub Actions workflow for automated image building and publishing to ghcr.io
- Comprehensive deployment documentation with quickstart guide and environment variable reference
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 15 comments.
Show a summary per file
| File | Description |
|---|---|
| Dockerfile | Multi-stage backend build using uv for dependency management, non-root user, and health checks |
| src/frontend/Dockerfile | Frontend build with Vite, served via nginx alpine for minimal image size |
| src/frontend/nginx.conf | Nginx configuration for SPA routing, API proxying, and static asset caching |
| docker-compose.yml | Service orchestration for backend, frontend, and optional Jaeger tracing |
| .dockerignore | Build context optimization excluding unnecessary files |
| src/frontend/.dockerignore | Frontend-specific build context exclusions |
| .github/workflows/docker.yml | CI/CD workflow for automated image builds and GHCR publishing |
| docs/guides/docker-deployment.md | Deployment guide with quickstart, commands, and environment variable reference |
| README.md | Added Docker quickstart section linking to deployment guide |
| src/frontend/src/components/chat/chat-messages.tsx | Removed unused formatMessageContent helper function to fix production build |
| environment: | ||
| # Required | ||
| - OPENAI_API_KEY=${OPENAI_API_KEY:-} | ||
| # Optional API keys | ||
| - TAVILY_API_KEY=${TAVILY_API_KEY:-} | ||
| - AZURE_OPENAI_ENDPOINT=${AZURE_OPENAI_ENDPOINT:-} | ||
| - AZURE_OPENAI_API_KEY=${AZURE_OPENAI_API_KEY:-} | ||
| # Settings | ||
| - LOG_LEVEL=${LOG_LEVEL:-INFO} | ||
| # Tracing | ||
| - ENABLE_OTEL=${ENABLE_OTEL:-false} | ||
| - OTLP_ENDPOINT=http://jaeger:4317 | ||
| volumes: |
There was a problem hiding this comment.
Missing environment variable that may be expected by the application. The .env.example file includes DSPY_COMPILE=true as an important configuration option that controls DSPy supervisor compilation, but this environment variable is not passed through in the docker-compose.yml backend service. Users who set this in their .env file expecting it to be used in the Docker environment will find it has no effect.
| environment: | ||
| # Required | ||
| - OPENAI_API_KEY=${OPENAI_API_KEY:-} | ||
| # Optional API keys | ||
| - TAVILY_API_KEY=${TAVILY_API_KEY:-} | ||
| - AZURE_OPENAI_ENDPOINT=${AZURE_OPENAI_ENDPOINT:-} | ||
| - AZURE_OPENAI_API_KEY=${AZURE_OPENAI_API_KEY:-} | ||
| # Settings | ||
| - LOG_LEVEL=${LOG_LEVEL:-INFO} | ||
| # Tracing | ||
| - ENABLE_OTEL=${ENABLE_OTEL:-false} | ||
| - OTLP_ENDPOINT=http://jaeger:4317 | ||
| volumes: |
There was a problem hiding this comment.
Additional environment variables from .env.example are not exposed to the Docker container. The following variables defined in .env.example that may be needed by the application are not passed through: ENABLE_DSPY_AGENTS, LANGFUSE_SECRET_KEY, LANGFUSE_PUBLIC_KEY, LANGFUSE_BASE_URL, OPENAI_BASE_URL, AZURE_OPENAI_API_VERSION, Azure Cosmos DB settings, Azure AI Search settings, and Azure OpenAI model deployment names. Users configuring these features will be unable to use them in the Docker environment.
| docker pull ghcr.io/qredence/agentic-fleet:latest | ||
| docker pull ghcr.io/qredence/agentic-fleet-ui:latest | ||
| ``` |
There was a problem hiding this comment.
Documentation shows incorrect image registry path. The documentation states users should pull from ghcr.io/qredence/agentic-fleet:latest, but the actual image names in docker-compose.yml use lowercase repository names as set by the GitHub workflow (line 37 in .github/workflows/docker.yml converts to lowercase). The repository name should match the actual GitHub repository owner/name. Verify the correct registry path matches the GitHub repository.
|
|
||
| WORKDIR /app | ||
| COPY package*.json ./ | ||
| RUN npm ci --legacy-peer-deps |
There was a problem hiding this comment.
The npm ci command uses --legacy-peer-deps flag which may hide dependency conflicts. While this flag may be necessary for the build to succeed, it bypasses peer dependency validation which could lead to runtime issues or security vulnerabilities from incompatible package versions. Document why this flag is needed or investigate resolving the peer dependency conflicts properly.
| RUN npm ci --legacy-peer-deps | |
| RUN npm ci |
| # Jaeger Tracing | ||
| # -------------------------------------------------------------------------- | ||
| jaeger: | ||
| image: jaegertracing/all-in-one:1.59 |
There was a problem hiding this comment.
The Jaeger image version appears outdated and uses a different image name than the existing tracing setup. The existing docker/docker-compose.tracing.yml uses jaegertracing/jaeger:2.13.0, but this uses jaegertracing/all-in-one:1.59. The version 1.59 is significantly older than 2.13.0. Consider using the same image and version as the existing tracing configuration for consistency, or update to a newer version if there's a specific reason for the change.
| image: jaegertracing/all-in-one:1.59 | |
| image: jaegertracing/jaeger:2.13.0 |
| - name: Build backend | ||
| uses: docker/build-push-action@v6 | ||
| with: | ||
| context: . | ||
| push: ${{ github.event_name != 'pull_request' }} | ||
| tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }},${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest | ||
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max | ||
|
|
||
| - name: Build frontend | ||
| uses: docker/build-push-action@v6 | ||
| with: | ||
| context: ./src/frontend | ||
| push: ${{ github.event_name != 'pull_request' }} | ||
| tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}-ui:${{ github.sha }},${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}-ui:latest | ||
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max |
There was a problem hiding this comment.
Docker build tags are not properly configured for version tags. When a version tag like v1.0.0 is pushed (line 7), the workflow will tag images as both :latest and :${{ github.sha }} (lines 44, 53), but it won't tag them with the version number (e.g., :v1.0.0 or :1.0.0). This means users cannot pull specific versions of the images. Consider using docker/metadata-action to automatically generate appropriate tags based on git refs, including semantic version tags.
| proxy_set_header X-Real-IP $remote_addr; | ||
| proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; | ||
| proxy_read_timeout 300s; | ||
| proxy_buffering off; |
There was a problem hiding this comment.
Disabling proxy buffering for all API requests may impact performance. The configuration sets proxy_buffering off for all /api requests (line 27), which is necessary for Server-Sent Events and streaming responses but may reduce performance for non-streaming API endpoints. Consider only disabling buffering for streaming endpoints or using X-Accel-Buffering header control to let the backend decide when buffering should be disabled.
| proxy_buffering off; | |
| # Note: proxy_buffering is left enabled by default. | |
| # Streaming endpoints should send `X-Accel-Buffering: no` | |
| # from the backend to disable buffering when needed. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zachary BENSALEM <zachary@qredence.ai>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zachary BENSALEM <zachary@qredence.ai>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zachary BENSALEM <zachary@qredence.ai>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (9)
src/frontend/nginx.conf (3)
8-20: Consider adding security headers for production.Production nginx configurations typically include security headers such as
X-Content-Type-Options,X-Frame-Options,X-XSS-Protection, andReferrer-Policyto protect against common web vulnerabilities.Suggested security headers
server { listen 80; root /usr/share/nginx/html; index index.html; + + # Security headers + add_header X-Content-Type-Options "nosniff" always; + add_header X-Frame-Options "DENY" always; + add_header X-XSS-Protection "1; mode=block" always; + add_header Referrer-Policy "strict-origin-when-cross-origin" always; # Gzip gzip on;
21-32: Proxy buffering disabled for all API requests.Setting
proxy_buffering off(line 31) for all/apirequests is necessary for Server-Sent Events and streaming responses but may reduce performance for non-streaming endpoints. Consider letting the backend control buffering via theX-Accel-Bufferingheader.Alternative: backend-controlled buffering
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 300s; - proxy_buffering off; + # Note: proxy_buffering is left enabled by default. + # Streaming endpoints should send `X-Accel-Buffering: no` + # from the backend to disable buffering when needed. }
34-38: Health endpoint routing may cause confusion.The
/healthendpoint proxies to the backend (line 35), but the frontend Dockerfile's healthcheck (line 29 in src/frontend/Dockerfile) checkshttp://localhost/which serves the static frontend. While both work independently, accessing the frontend athttp://localhost/healthwill return backend health status, which may be unexpected.Consider separating frontend and backend health endpoints
+ # Frontend health endpoint (nginx/proxy) + location = /health { + return 204; + } + - # Health/docs endpoints + # Backend health/docs endpoints - location ~ ^/(health|ready|docs|redoc|openapi.json) { + location ~ ^/(ready|docs|redoc|openapi.json) { proxy_pass http://api; proxy_set_header Host $host; }src/frontend/Dockerfile (1)
10-10: Verify peer dependency usage.The
--legacy-peer-depsflag bypasses peer dependency validation, which could hide incompatible package versions. While this may be necessary for the current build to succeed, consider documenting why it's required or investigating resolution of the underlying peer dependency conflicts.If this flag is required due to specific dependency conflicts, please document the reason in a comment or in the frontend README.
docs/guides/docker-deployment.md (2)
42-43: Verify image registry path matches repository.The documentation specifies pulling from
ghcr.io/qredence/agentic-fleetandghcr.io/qredence/agentic-fleet-ui, but the GitHub workflow (line 37 in .github/workflows/docker.yml) converts the repository name to lowercase. Ensure these paths match the actual published images.#!/bin/bash # Verify the actual GitHub repository owner and name gh repo view --json nameWithOwner --jq '.nameWithOwner'
30-35: Environment variable table has inconsistent formatting.Line 35 describes
ENABLE_OTELas "Enable tracing" but doesn't mention the expected values (true/false) or default value, unlike typical boolean variable documentation.Suggested improvement
| Variable | Required | Description | |------------------|----------|--------------------------------------------------| | `OPENAI_API_KEY` | Yes | OpenAI API key | | `TAVILY_API_KEY` | No | Web search | | `AZURE_OPENAI_*` | No | Azure OpenAI config | -| `ENABLE_OTEL` | No | Enable tracing | +| `ENABLE_OTEL` | No | Enable tracing (`true`/`false`, default: `false`) |.github/workflows/docker.yml (1)
39-55: Version tags not included in Docker image tags.The workflow triggers on version tags (
v*on line 7) but only tags images with{sha}andlatest(lines 44, 53). Users cannot pull specific versions like:v1.0.0or:1.0.0.Consider using docker/metadata-action for automatic tag generation
+ - name: Docker metadata (backend) + id: meta-backend + uses: docker/metadata-action@v5 + with: + images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} + tags: | + type=ref,event=branch + type=ref,event=pr + type=semver,pattern={{version}} + type=semver,pattern={{major}}.{{minor}} + type=sha + - name: Build backend uses: docker/build-push-action@v6 with: context: . push: ${{ github.event_name != 'pull_request' }} - tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }},${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest + tags: ${{ steps.meta-backend.outputs.tags }} + labels: ${{ steps.meta-backend.outputs.labels }} cache-from: type=gha cache-to: type=gha,mode=maxApply similar changes for the frontend build.
docker-compose.yml (2)
69-77: Verify Jaeger image version alignment with existing tracing setup.Past comments noted that
docker/docker-compose.tracing.ymlusesjaegertracing/jaeger:2.13.0, while this usesjaegertracing/all-in-one:1.59. These are different image names and versions. Theall-in-oneimage is the correct choice for single-node deployments, but version 1.59 is older than the 2.x series available.What is the latest version of jaegertracing/all-in-one Docker image?
43-43: Document volume permission initialization in deployment guide or enhance entrypoint handling.The concern is valid: the Dockerfile creates
.var/withapp:appownership (line 41), but this depends on the volume initialization preserving image ownership. The troubleshooting guide explicitly lists permission checks for.var/logs/as a known issue, yet the docker-deployment.md guide omits this entirely. Additionally,make init-varonly creates directories—it doesn't fix permissions.Consider either:
- Adding a section to docker-deployment.md documenting this volume initialization concern and the troubleshooting steps
- Implementing an entrypoint script that explicitly ensures correct permissions on startup, rather than relying solely on the build-time
chown
🧹 Nitpick comments (2)
docker-compose.yml (1)
30-41: Consider exposing additional environment variables from.env.example.Several application features documented in
.env.examplewon't be configurable in the Docker environment:DSPY_COMPILE,ENABLE_DSPY_AGENTS, Langfuse keys, Cosmos DB settings, and Azure AI Search settings. Users enabling these features will need to manually add them.Based on retrieved learnings,
DSPY_COMPILEcontrols offline compilation of DSPy supervisors and may be important for production deployments.🔎 Suggested additions to environment section
# Settings - LOG_LEVEL=${LOG_LEVEL:-INFO} + - DSPY_COMPILE=${DSPY_COMPILE:-false} + - ENABLE_DSPY_AGENTS=${ENABLE_DSPY_AGENTS:-false} # Tracing - ENABLE_OTEL=${ENABLE_OTEL:-false} - OTLP_ENDPOINT=http://jaeger:4317Dockerfile (1)
52-52: Consider adding worker configuration for production.The current command runs uvicorn with default single-worker configuration. For production deployments with higher load, you may want to expose worker count as a configurable option.
🔎 Optional: Make worker count configurable
-CMD ["python", "-m", "uvicorn", "agentic_fleet.main:app", "--host", "0.0.0.0", "--port", "8000"] +CMD ["python", "-m", "uvicorn", "agentic_fleet.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "1"]Then users can override via
docker-compose.yml:command: ["python", "-m", "uvicorn", "agentic_fleet.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "4"]
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (10)
.dockerignore.github/workflows/docker.ymlDockerfileREADME.mddocker-compose.ymldocs/guides/docker-deployment.mdsrc/frontend/.dockerignoresrc/frontend/Dockerfilesrc/frontend/nginx.confsrc/frontend/src/components/chat/chat-messages.tsx
🧰 Additional context used
📓 Path-based instructions (6)
src/frontend/**/*
📄 CodeRabbit inference engine (CLAUDE.md)
Frontend must use config via
VITE_API_URLin.env(defaults tohttp://localhost:8000)
Files:
src/frontend/nginx.confsrc/frontend/src/components/chat/chat-messages.tsxsrc/frontend/Dockerfile
src/frontend/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
src/frontend/src/**/*.{ts,tsx}: React components must be organized by technical concern: UI Primitives incomponents/ui/, Domain Components incomponents/[domain]/, Pages inpages/, Hooks inhooks/
React custom hooks must always be placed inhooks/directory, never incomponents/
API calls must always go throughapi/hooks.ts, never direct fetch
Use React Query for server state management and Zustand for client state management in frontend
Files:
src/frontend/src/components/chat/chat-messages.tsx
src/frontend/src/components/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Domain Components must be reusable UI for specific domains (Chat, Message, Workflow, Layout) organized in
components/[domain]/
Files:
src/frontend/src/components/chat/chat-messages.tsx
{**/*.{ts,tsx,jsx,js},package.json,package-lock.json}
📄 CodeRabbit inference engine (AGENTS.md)
Use
npm(Vite + React 19 + Tailwind) for frontend tooling; do not usebun
Files:
src/frontend/src/components/chat/chat-messages.tsx
{src/agentic_fleet/api/**/*.py,src/agentic_fleet/workflows/**/*.py,**/*.{ts,tsx}}
📄 CodeRabbit inference engine (AGENTS.md)
Map workflow events through
agentic_fleet.api.events.mappingto UI-friendly categories (reasoning, routing, analysis, quality, agent output); keep SSE payloads and frontend workflow renderers in sync when adding new event kinds
Files:
src/frontend/src/components/chat/chat-messages.tsx
{.github/agents/agent-framework-spec.md,docs/**/*.md,src/agentic_fleet/agents/**/*.py}
📄 CodeRabbit inference engine (AGENTS.md)
For multi-agent expansion with OpenAI Agents SDK, treat Codex CLI as an MCP server and mirror roles from
.github/agents/agent-framework-spec.md; document new roles/prompts in.github/agents/agent-framework-spec.mdanddocs/
Files:
docs/guides/docker-deployment.md
🧠 Learnings (22)
📓 Common learnings
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/{package.json,package-lock.json,*.lock} : Use `npm` as the package manager for the frontend (see root `Makefile` targets)
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Avoid committing artifacts from `.var/` (logs, caches, compiled DSPy outputs) to version control
Applied to files:
.dockerignore
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Follow the layered FastAPI-first architecture: API → Services → Workflows → DSPy → Agents with code organized under `src/agentic_fleet/`
Applied to files:
README.mdsrc/frontend/nginx.confdocker-compose.ymldocs/guides/docker-deployment.mdDockerfile
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Frontend renders the AgenticFleet chat UI and consumes backend REST endpoints under `/api/v1`
Applied to files:
README.mdsrc/frontend/nginx.confdocker-compose.ymlsrc/frontend/Dockerfile
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Run backend CLI via `make run` (agentic-fleet Typer console); use `make dev` for full dev servers (backend :8000, frontend :5173) or `make backend`/`make frontend-dev` individually
Applied to files:
README.mddocker-compose.yml
📚 Learning: 2025-12-29T04:44:01.340Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/developers/internals/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:01.340Z
Learning: Applies to docs/developers/internals/src/agentic_fleet/**/*.py : Treat `src/agentic_fleet/` as the source of truth for workflow behaviour—adjust configuration through YAML helpers and `AgentFactory` instead of hardcoding values
Applied to files:
README.mdDockerfile
📚 Learning: 2025-12-29T04:44:01.340Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/developers/internals/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:01.340Z
Learning: Applies to docs/developers/internals/src/agentic_fleet/cli/**/*.py : CLI commands must be modular with separated command implementations; the `--fast` flag must automatically enable `pipeline_profile="light"` for latency-optimized workflow execution
Applied to files:
README.md
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Applies to {.github/agents/agent-framework-spec.md,docs/**/*.md,src/agentic_fleet/agents/**/*.py} : For multi-agent expansion with OpenAI Agents SDK, treat Codex CLI as an MCP server and mirror roles from `.github/agents/agent-framework-spec.md`; document new roles/prompts in `.github/agents/agent-framework-spec.md` and `docs/`
Applied to files:
README.md
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Applies to src/agentic_fleet/api/**/*.py : Place FastAPI web layer code (routes, middleware, deps) under `src/agentic_fleet/api/`
Applied to files:
src/frontend/nginx.conf
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/src/features/chat/stores/chatStore.ts : Handle new streaming event types in `src/features/chat/stores/chatStore.ts` for event handling and mapping
Applied to files:
src/frontend/src/components/chat/chat-messages.tsx
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/src/features/chat/**/*.{ts,tsx} : Chat feature should include UI, store, and streaming UI components under `src/features/chat/`
Applied to files:
src/frontend/src/components/chat/chat-messages.tsx
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/src/features/chat/stores/chatStore.ts : Chat state management should create/select conversations, send chat requests over SSE, normalize stream events into message steps, and persist UI preferences (trace visibility, raw reasoning toggle)
Applied to files:
src/frontend/src/components/chat/chat-messages.tsx
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/src/api/types.ts : Update `src/api/types.ts` when backend adds new streaming event types
Applied to files:
src/frontend/src/components/chat/chat-messages.tsx
📚 Learning: 2025-12-22T04:13:38.415Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-22T04:13:38.415Z
Learning: When adding streaming event types, update backend mapping in `src/agentic_fleet/api/events/mapping.py`, add `ui_routing:` entry in workflow_config.yaml, update frontend types in `src/frontend/src/api/types.ts`, and handle in `src/frontend/src/stores/chatStore.ts`
Applied to files:
src/frontend/src/components/chat/chat-messages.tsx
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Applies to .env* : Copy `.env.example` to `.env` and set required `OPENAI_API_KEY` and optional `TAVILY_API_KEY`, Cosmos settings, and `DSPY_COMPILE` environment variables
Applied to files:
docker-compose.yml
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Applies to {src/agentic_fleet/dspy_modules/**/*.py,config/workflow_config.yaml} : Treat DSPy compilation as offline-only via `agentic-fleet optimize` (cached under `.var/logs/compiled_supervisor.pkl`); set `dspy.require_compiled: true` in config to fail-fast if artifacts are missing
Applied to files:
docker-compose.yml
📚 Learning: 2025-12-29T04:44:01.340Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/developers/internals/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:01.340Z
Learning: Applies to docs/developers/internals/**/*.yaml : Required environment variable `OPENAI_API_KEY` must be set; optional variables (`OPENAI_BASE_URL`, `TAVILY_API_KEY`, `DSPY_COMPILE`, `ENABLE_OTEL`, `OTLP_ENDPOINT`) must be documented in configuration files
Applied to files:
docker-compose.ymldocs/guides/docker-deployment.md
📚 Learning: 2025-12-29T04:44:01.340Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/developers/internals/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:01.340Z
Learning: Applies to docs/developers/internals/**/.env : Load `.env` for local development; production deployments must inject secrets via managed stores instead of environment files
Applied to files:
docker-compose.yml
📚 Learning: 2025-12-29T04:44:19.392Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: docs/frontend/AGENTS.md:0-0
Timestamp: 2025-12-29T04:44:19.392Z
Learning: Applies to docs/frontend/src/frontend/{package.json,package-lock.json,*.lock} : Use `npm` as the package manager for the frontend (see root `Makefile` targets)
Applied to files:
src/frontend/Dockerfile
📚 Learning: 2025-12-17T10:03:22.041Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-17T10:03:22.041Z
Learning: Use Python dependencies via `uv` only; never use `pip` directly (see `Makefile`)
Applied to files:
Dockerfile
📚 Learning: 2025-12-22T04:13:38.415Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-22T04:13:38.415Z
Learning: Use `uv` for Python package management (mandatory, >0.8.0); never use pip directly
Applied to files:
Dockerfile
📚 Learning: 2025-12-22T06:44:16.454Z
Learnt from: CR
Repo: Qredence/agentic-fleet PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-22T06:44:16.454Z
Learning: Applies to **/*.py : Use `uv` for Python dependency and environment management (Python 3.12+); never activate venvs manually, always use `uv run ...`
Applied to files:
Dockerfile
🔍 Remote MCP
Here is a concise summary of relevant additional context about the AgenticFleet repository and ecosystem that would help in reviewing the given pull request, based on the information available from the sources parsed:
Relevant Context for Reviewing the Docker Containerization Pull Request (#489)
Overall AgenticFleet System
- AgenticFleet is a multi-agent orchestration system combining Microsoft Agent Framework for runtime and DSPy for intelligent task analysis, routing, and quality assessment.
- It implements a 5-phase execution pipeline: Analysis → Routing → Execution → Progress → Quality.
- The architecture is configuration-driven with all agents, tools, and workflows defined in
workflow_config.yaml. - Agents are specialized roles like Researcher, Analyst, Writer, Coder, Planner, etc., instantiated via an
AgentFactory. - DSPy reasoning modules are compiled offline and cached for production efficiency.
Docker Containerization Features in the PR
- Adds backend and frontend Dockerfiles with multi-stage builds optimized for production.
- Frontend is built using Node/Vite and served via Nginx with optimized caching and gzip compression.
- Introduces robust
docker-compose.ymlorchestrating backend, frontend, and optional Jaeger tracing service with network and volume sharing. - Adds
.dockerignorefiles to optimize Docker build contexts by excluding git data, logs, caches, notebooks, tests, and virtual environments. - Integrates Docker image build and publishing into GitHub Actions workflow at
.github/workflows/docker.ymltargeting GitHub Container Registry with appropriate caching and secrets management. - Extends documentation with
docs/guides/docker-deployment.mdexplaining quick start, commands, environment variables, and production usage with Docker. - Updates README with Docker quick start instructions.
- Fixes frontend source code build issues by removing unused helper functions hindering production build compatibility.
Infrastructure and CI/CD Integration
- Uses
uvfor Python dependency management andnpmfor frontend, with pinned versions inuv.lock. - CI/CD automates linting with Ruff, type checking with Ty, tests with pytest, frontend builds and tests with Vitest and Playwright, security scanning with Bandit and CodeQL.
- DSPy modules are compiled offline using GEPA optimizer, caching compiled artifacts under
.var/cache/dspy/. - The layered cache architecture optimizes routing decisions and agent responses.
- Observability integrates OpenTelemetry with optional Azure Monitor and Jaeger setups.
- Session management facilitates multi-tenant conversation and workflow state tracking, with Cosmos DB optional persistence backend.
- FastAPI backend serves API and websocket endpoints to the frontend React app.
Frontend Architecture
- React 19 app built with Vite, TypeScript, Tailwind CSS v4, Zustand for state management, and TanStack Query for server state.
- Chat UI components enable real-time visualization of agent workflow interactions, reasoning, and message streaming.
- Provides extensible UI routing and event mapping configurable via
workflow_config.yaml. - WebSocket and SSE clients handle streaming from backend via
/ws/chatand/api/chat/:id/stream.
Key Points for PR Review
- Dockerfiles follow multi-stage patterns with security best practices (non-root users, minimal base images).
- Docker-compose orchestrates multi-container deployment aligning with workflow architecture and observability needs.
- GitHub Actions workflow uses
buildxwith cache and secret management in line with GHCR requirements. - Integration with tracing and Jaeger for monitoring backend containers.
- Consistent
.dockerignorefiles enhance build performance by reducing context size. - Updates to frontend build process prevent known build issues.
- The documentation additions provide detailed end-user instructions aligning with config/environment variables used in deployment.
This context covers architecture, tooling, deployment, observability, and testing aspects relevant to the containerization changes introduced in this PR. It provides a holistic understanding of how the added Docker infrastructure integrates with AgenticFleet's existing systems and operational flows, aiding a thorough and informed review.
All information derived primarily from the DeepWiki source documents on AgenticFleet architecture, workflows, agent and tool systems, CI/CD, deployment, and frontend frameworks [::DeepWiki::].
🔇 Additional comments (12)
src/frontend/src/components/chat/chat-messages.tsx (1)
132-132: LGTM!The trailing newline formatting is correct. The removal of the unused
formatMessageContenthelper (mentioned in the PR summary) properly addresses the production build issue.src/frontend/.dockerignore (1)
1-4: LGTM!Standard and appropriate ignore patterns for frontend Docker build context. Excludes node_modules (installed in container), build artifacts, logs, and environment files.
README.md (1)
91-104: LGTM!The Docker quick-start section is clear and well-structured. The comment on line 95 appropriately guides users who already have the repository cloned, and the commands are properly separated for clarity.
.dockerignore (1)
1-41: LGTM!Comprehensive and well-structured ignore patterns for the root Docker build context. The exclusion of
src/frontend/(line 33) is appropriate since the frontend has its own Dockerfile and build context, and the .dockerignore correctly preserves.env.examplewhile excluding other environment files.src/frontend/Dockerfile (1)
19-21: LGTM!The
wgetinstallation (line 20) correctly addresses the healthcheck requirement, ensuring the container health can be properly monitored. Removing the default nginx config and replacing it with the custom configuration is the right approach.docker-compose.yml (3)
1-15: Clear and helpful usage documentation.The header comments provide useful context about the project architecture and quick usage examples. Good practice for discoverability.
60-62: Good use of health-based dependency.Using
condition: service_healthyensures the frontend only starts after the backend is ready to serve requests. This prevents race conditions during startup.
79-84: Network and volume definitions look good.Bridge network for inter-service communication and a named volume for backend data persistence are appropriate for this setup.
Dockerfile (4)
7-24: Well-structured builder stage with good caching strategy.The dependency-first copy pattern (
pyproject.tomlanduv.lockbefore source) optimizes layer caching. The two-phase sync (--no-install-projectthen full sync) is a good approach with uv. Version 0.8.0 aligns with the project'srequired-version = ">=0.8.0"constraint.
29-44: Clean runtime stage with security best practices.Good practices observed:
- Minimal base image with only necessary packages (curl for healthcheck)
- Non-root user (
app) for container execution- Proper ownership of copied files and created directories
- Single
RUNinstruction minimizes layers
49-50: Healthcheck configuration looks reasonable.The 15-second start period allows time for application initialization. Consider whether this is sufficient for DSPy module loading if
DSPY_COMPILE=truetriggers compilation at startup.
21-24: The configuration file is already included in the Docker image. SinceCOPY src/agentic_fleet ./src/agentic_fleetrecursively copies the entire directory, theworkflow_config.yamlatsrc/agentic_fleet/config/workflow_config.yamlis automatically included in the build.Likely an incorrect or invalid review comment.
2 participants
fixes #455
Description
Adds production-ready Docker containerization for AgenticFleet, enabling users to run the full stack with a single
docker compose upcommand. This includes multi-stage builds for optimized image sizes, CI/CD integration for automated image publishing, and comprehensive deployment documentation.Type of Change
Related Issues
Fixes #455
Changes Made
uv, non-root user, and health checkformatMessageContentfunction in chat-messages.tsx that blocked production buildTesting
uv run pytest)uv run ruff check .)Test Commands Run