Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions .dockerignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# Dependencies
node_modules
bun.lock

# Build outputs
dist
build
*.tsbuildinfo

# Development files
.env.local
.env.development.local
.env.test.local
.env.production.local

# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# Coverage directory used by tools like istanbul
coverage
*.lcov

# nyc test coverage
.nyc_output

# IDE
.vscode
.idea
*.swp
*.swo

# OS
.DS_Store
Thumbs.db

# Git
.git
.gitignore

# Documentation
README.md
docs/
*.md

# Misc
.eslintrc*
.prettierrc*
37 changes: 37 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Build stage - using Bun for fast builds
FROM oven/bun:latest AS builder
Comment on lines +1 to +2
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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 version

Committable 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.


WORKDIR /build

# Install git first (this layer rarely changes)
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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.

Suggested change
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).


# Copy local source code (this changes often)
COPY . .

# Install dependencies (changes when package.json changes)
RUN bun install

# Build (changes when source or ARG changes)
ENV VITE_API_BASE_URL=$VITE_API_BASE_URL
RUN bun run build

# Runtime stage - lightweight Node.js image
FROM node:20-alpine

WORKDIR /app

# Install serve to efficiently serve static files
RUN npm install -g serve

# Copy built application from builder stage
COPY --from=builder /build/dist ./dist

# Expose port 5173 (matches the dev server port used in docker-compose)
EXPOSE 5173

# Serve the built application
CMD ["serve", "-l", "5173", "-s", "dist"]
15 changes: 15 additions & 0 deletions Dockerfile.opencode
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
FROM oven/bun:latest
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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 version

Run 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.


RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

RUN bun install -g opencode-ai

WORKDIR /workspace

ENV HOST=0.0.0.0
ENV PORT=4096

EXPOSE 4096

# For server logs, add: "--log-level INFO --print-logs true"
CMD ["sh", "-c", "opencode serve --hostname $HOST --port $PORT"]
31 changes: 31 additions & 0 deletions docker-compose.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
services:
opencode:
build:
context: .
dockerfile: Dockerfile.opencode
environment:
- HOST=0.0.0.0
- PORT=4096
working_dir: /workspace
# volumes:
# # Mount to a project folder
# - .:/workspace
# # Optionally you can mount the opencode files to your system
# - ./opencode-data:/home/opencode/.local/share/opencode
# - ./opencode-config:/home/opencode/.config/opencode
# - ./opencode-state:/home/opencode/.local/state/opencode
ports:
- "4096:4096"
restart: unless-stopped

web:
build:
context: .
dockerfile: Dockerfile
args:
VITE_API_BASE_URL: http://localhost:4096
ports:
- "5173:5173"
restart: unless-stopped
depends_on:
- opencode
Comment on lines +30 to +31
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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:

  1. Health checks (recommended): Add a healthcheck to the opencode service and update depends_on to wait for it.
  2. Wait script: Implement a startup script in the web service that polls opencode before starting.
  3. 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-stopped

Then update the web service to wait for it:

   web:
     ...
     depends_on:
-      - opencode
+      opencode:
+        condition: service_healthy

Option 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.