feat: Add docker setup for easy setup #4
Conversation
feat: additional refinement
WalkthroughAdds Docker infrastructure files for containerizing a Node.js project. Includes .dockerignore for build optimization, a multi-stage Dockerfile for building and serving a static site, a separate Dockerfile.opencode for an opencode service, and docker-compose.yml orchestrating both services with inter-service dependencies and build-time arguments. Changes
Sequence DiagramsequenceDiagram
participant User
participant WebApp as Web<br/>(port 5173)
participant OpenCode as OpenCode<br/>(port 4096)
rect rgb(230, 245, 255)
Note over WebApp,OpenCode: Build Phase
User->>WebApp: docker-compose build
Note over WebApp: Builder stage:<br/>- Installs deps with bun<br/>- Builds dist<br/>- VITE_API_BASE_URL arg
OpenCode->>OpenCode: docker build<br/>with Dockerfile.opencode
Note over OpenCode: Install opencode-ai<br/>Configure HOST/PORT
end
rect rgb(245, 230, 255)
Note over WebApp,OpenCode: Runtime Phase
User->>OpenCode: docker-compose up
activate OpenCode
OpenCode->>OpenCode: Start opencode server<br/>Listen on 0.0.0.0:4096
deactivate OpenCode
activate WebApp
WebApp->>OpenCode: Connect to http://localhost:4096
Note over WebApp: Start serve<br/>Listen on 0.0.0.0:5173
deactivate WebApp
User->>WebApp: Access http://localhost:5173
WebApp->>OpenCode: API calls to http://localhost:4096
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
Dockerfile.opencode (1)
5-5: Consider pinning the opencode-ai package version.The
bun install -g opencode-aicommand installs the latest version without constraints. Pin it to a specific version to ensure consistent deployments and avoid unexpected breaking changes.-RUN bun install -g opencode-ai +RUN bun install -g opencode-ai@x.y.z # Pin to a known stable versionCheck the opencode-ai npm package for available versions.
docker-compose.yml (2)
1-31: Add docker-compose version specification.While not strictly required, explicitly specifying the docker-compose version improves clarity and ensures consistent behavior across different environments.
+version: '3.8' + services:Check the Compose Specification for available versions.
21-26: Document the VITE_API_BASE_URL assumption in docker-compose.yml.The build argument passes
http://localhost:4096as the API base URL. Add a comment clarifying this is for local development and document how to override it for other environments.web: build: context: . dockerfile: Dockerfile args: + # Note: localhost:4096 assumes local development. Override for production. + # Example: docker-compose.override.yml with different VITE_API_BASE_URL VITE_API_BASE_URL: http://localhost:4096Consider creating a
docker-compose.prod.ymlordocker-compose.override.ymlfile for non-development deployments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.dockerignore(1 hunks)Dockerfile(1 hunks)Dockerfile.opencode(1 hunks)docker-compose.yml(1 hunks)
🔇 Additional comments (2)
.dockerignore (1)
1-57: Well-structured .dockerignore.The ignore patterns are comprehensive and follow Node.js project conventions. This will effectively reduce the Docker build context size.
Dockerfile (1)
1-37: Excellent multi-stage build structure.The builder/runtime separation is well-designed with clear comments explaining layer caching strategy. The choice of
node:20-alpinefor the runtime stage is appropriate for minimizing image size. Good use ofservefor static file delivery.
| depends_on: | ||
| - opencode |
There was a problem hiding this comment.
Service readiness: depends_on does not guarantee service availability.
The depends_on constraint ensures the opencode container is started, but not that it's ready to accept connections. If the web service attempts to connect to opencode immediately on startup before opencode finishes initialization, requests will fail.
Consider implementing one of the following strategies:
- Health checks (recommended): Add a healthcheck to the opencode service and update depends_on to wait for it.
- Wait script: Implement a startup script in the web service that polls opencode before starting.
- Retry logic: Implement client-side retry logic in the web service for API calls to opencode.
Option 1: Add a healthcheck to opencode service:
services:
opencode:
build:
context: .
dockerfile: Dockerfile.opencode
environment:
- HOST=0.0.0.0
- PORT=4096
+ healthcheck:
+ test: ["CMD", "curl", "-f", "http://localhost:4096/health"]
+ interval: 10s
+ timeout: 5s
+ retries: 5
ports:
- "4096:4096"
restart: unless-stoppedThen update the web service to wait for it:
web:
...
depends_on:
- - opencode
+ opencode:
+ condition: service_healthyOption 2: Add a brief startup delay (simpler but less reliable):
web:
...
+ command: sh -c "sleep 5 && serve -l 5173 -s dist"Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docker-compose.yml around lines 30-31, the current depends_on only ensures
the opencode container starts but not that it is ready; add a proper readiness
strategy: preferred — add a healthcheck section to the opencode service
(curl/health endpoint or TCP check) and change the web service depends_on to
wait for condition: service_healthy; alternatively implement a startup wait
script in the web service that polls opencode until healthy before launching or
add robust client-side retry/backoff logic for connections to opencode. Ensure
the healthcheck command and interval/retries are tuned so the web service only
starts after opencode reports healthy.
| # Build stage - using Bun for fast builds | ||
| FROM oven/bun:latest AS builder |
There was a problem hiding this comment.
Pin the bun base image to a specific version.
Using oven/bun:latest creates reproducibility issues. Pin to a specific version tag to ensure consistent builds.
-FROM oven/bun:latest AS builder
+FROM oven/bun:1.x.y # Replace x.y with the desired versionCommittable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In Dockerfile lines 1-2, the base image is currently referenced as
oven/bun:latest which harms reproducible builds; change the FROM line to pin a
stable bun version tag (for example oven/bun:1.0.0 or the project-approved
semantic tag) and update any related build documentation; ensure the chosen tag
is committed here and, if needed, add a comment noting the pinned version and
rationale so future updates are explicit.
| RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/* | ||
|
|
||
| # Accept build argument for API base URL (this can change frequently) | ||
| ARG VITE_API_BASE_URL=http://localhost:4096 |
There was a problem hiding this comment.
Document the VITE_API_BASE_URL default and its limitations.
The default http://localhost:4096 assumes a local development environment and will not work for production deployments or other environments where localhost is not accessible. Consider adding a comment explaining this assumption and clarify the override process for other environments.
-ARG VITE_API_BASE_URL=http://localhost:4096
+# Note: This default is for local development only. Override for production environments.
+# Example: docker build --build-arg VITE_API_BASE_URL=https://api.example.com ...
+ARG VITE_API_BASE_URL=http://localhost:4096📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ARG VITE_API_BASE_URL=http://localhost:4096 | |
| # Note: This default is for local development only. Override for production environments. | |
| # Example: docker build --build-arg VITE_API_BASE_URL=https://api.example.com ... | |
| ARG VITE_API_BASE_URL=http://localhost:4096 |
🤖 Prompt for AI Agents
In Dockerfile around line 10, the ARG VITE_API_BASE_URL default points to
http://localhost:4096 which assumes a local dev environment and won't work in
production; add a one-line comment above this ARG stating that it's a
development-only default, list its limitation (not accessible outside the
container host) and document how to override it during build or runtime (e.g.,
docker build --build-arg VITE_API_BASE_URL=<url> and docker run -e
VITE_API_BASE_URL=<url>, or set a production value via your CI/CD pipeline or
environment-specific Dockerfile/compose).
| @@ -0,0 +1,15 @@ | |||
| FROM oven/bun:latest | |||
There was a problem hiding this comment.
Pin the bun base image to a specific version.
Using oven/bun:latest creates reproducibility issues and introduces the risk of unexpected failures if a new bun release contains breaking changes. Pin to a specific version tag instead.
-FROM oven/bun:latest AS builder
+FROM oven/bun:1.x.y # Replace x.y with the desired versionRun docker inspect oven/bun:latest or check Docker Hub to find the appropriate version tag.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In Dockerfile.opencode around line 1, the base image is using the mutable tag
oven/bun:latest which harms reproducibility; replace it with a specific version
tag (or an immutable digest) such as oven/bun:<version> (or
oven/bun@sha256:<digest>) found by running docker inspect oven/bun:latest or
checking the image tags on Docker Hub, then update the FROM line to that exact
tag/digest to pin the bun runtime.
1 participant
Setting up both server and UI in Docker was a bit painful. Submitting this to help others get setup and running quickly.
Summary by CodeRabbit