fix(api): multi-stage build, non-root user, add healthcheck

[pavsoss]

Closes #594

This PR addresses the security vulnerabilities in Dockerfile.api by:

• Using a multi-stage build: Compiles wheels in a builder stage and only copies them into the runtime image, keeping tools like build-essential and git out of the final container.
• Dropping privileges: Runs the container as a dedicated agentwatch non-root user (uid 10001) instead of root.
• Adding a Healthcheck: Implemented a native Python-based HEALTHCHECK (using urllib.request) to verify the API is up without needing to install curl.

Summary by CodeRabbit

• Bug Fixes

  • Improved container health monitoring with an explicit health check endpoint on port 8000.

• Security

  • Updated the container to run the application as a non-root user.

• Performance

  • Reduced runtime image size by using a multi-stage build and installing only prebuilt packages in the final image.

[vercel]

@pavsoss is attempting to deploy a commit to the sreerevanth's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e90b94c3-f404-4ff7-b9e9-24b567356606

📥 Commits

Reviewing files that changed from the base of the PR and between 5a05591 and efa9b96.

📒 Files selected for processing (1)

• Dockerfile.api

🚧 Files skipped from review as they are similar to previous changes (1)

• Dockerfile.api

---

📝 Walkthrough

Walkthrough

Dockerfile.api now uses a multi-stage build, installs prebuilt wheels in the runtime image, removes build-only packages, runs as agentwatch, exposes port 8000, and checks /health.

Changes

API container hardening

Layer / File(s)	Summary
Multi-stage runtime image Dockerfile.api	The builder stage creates wheel artifacts, while the runtime stage installs them without build tooling, switches to the non-root agentwatch user, exposes port 8000, and adds a /health health check.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

A rabbit hops through wheels so neat,
No root-run shell beneath its feet.
Port eight thousand hums alive,
/health checks that services thrive.
Build tools stay outside the door—
Safe carrots for the runtime floor!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main Dockerfile.api changes: multi-stage build, non-root user, and healthcheck.
Linked Issues check	✅ Passed	The PR matches #594 by using a multi-stage build, removing runtime build tools, dropping root, and adding a healthcheck.
Out of Scope Changes check	✅ Passed	The changes stay focused on the container security and healthcheck goals with no obvious unrelated additions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🧪 PR Test Results

Check	Result
Tests (pytest tests/)	✅ success
Lint (ruff check .)	❌ failure
Coverage (agentwatch)	74.67%

_{Python 3.12 · commit efa9b96}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

Dockerfile.api (1)

14-15: 🩺 Stability & Availability | 🔵 Trivial

Consider a longer --start-period for Python application startup.

The --start-period=5s grace window may be too short for a Python/FastAPI application that initializes database sessions, Redis connections, and other subsystems before the /health endpoint becomes responsive. If the app takes longer than 5 seconds to bind port 8000, the healthcheck will begin failing immediately, and orchestrators (e.g., Kubernetes, Docker Swarm) may mark the container unhealthy and restart it before it finishes starting. A value of 15s–30s is more typical for Python web applications.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Dockerfile.api` around lines 14 - 15, Increase the HEALTHCHECK --start-period
from 5s to a 15s–30s grace window, preferably 30s, so the Python application can
complete initialization before healthcheck failures count.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@Dockerfile.api`:
- Around line 14-15: Update the Dockerfile healthcheck’s urllib.request.urlopen
call to pass timeout=5, and wrap the request in exception handling that
suppresses HTTPError and other expected healthcheck failures while still exiting
non-zero. Keep successful /health responses passing and ensure failures complete
within Docker’s 10-second timeout without traceback output.

---

Nitpick comments:
In `@Dockerfile.api`:
- Around line 14-15: Increase the HEALTHCHECK --start-period from 5s to a
15s–30s grace window, preferably 30s, so the Python application can complete
initialization before healthcheck failures count.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99332262-2cd4-4a9b-bd9b-9545bbada46d

📥 Commits

Reviewing files that changed from the base of the PR and between a492da5 and 5a05591.

📒 Files selected for processing (1)

• Dockerfile.api

[sreerevanth]

The Dockerfile changes are a solid improvement, but the HEALTHCHECK should be made more robust before merging.

urllib.request.urlopen() is called without a timeout and will emit noisy tracebacks when /health returns a non-200 status. Please add a reasonable timeout (e.g. 5 seconds) and catch exceptions so the health check exits cleanly with a non-zero status instead of printing stack traces on every failed probe.

Once that's addressed, this should be good to merge.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agent-watch	Ready	Preview, Comment	Jul 14, 2026 5:56pm