?
PPLX-28
docker infrastructure
Created: 2025-12-21 Updated: 2025-12-21
Relationships Loading...
Attachments
Loading...
Comments (3)
agent · 2025-12-21
## Fix Implemented ### Root Cause docker-compose.yml line 65 had VITE_API_URL set to `http://backend:8000/api` which is a Docker-internal hostname. Browsers cannot resolve Docker container names, causing ERR_NAME_NOT_RESOLVED errors. ### Changes Made - `docker-compose.yml:65`: Changed VITE_API_URL from `http://backend:8000/api` to `/api` (relative URL) ### How It Works 1. Browser requests pages from `localhost:8080` (nginx) 2. Frontend JavaScript makes API calls to `/api/*` (relative to current origin) 3. Nginx receives `/api/*` requests and proxies them to `http://backend:8000` (Docker-internal) 4. Backend responds, nginx forwards to browser ### Verification Tested with chrome-devtools MCP: - Navigated to `http://localhost:8080/library` - Network requests show: `GET http://localhost:8080/api/threads?page=1&page_size=20` - No ERR_NAME_NOT_RESOLVED errors - Threads displayed correctly in UI - Console shows no API-related errors ### Files Changed - `docker-compose.yml` (1 file, 2 lines changed)
code-verification-qa · 2025-12-21
[QA] FAILED - Critical bug: Frontend uses Docker-internal hostname 'backend:8000' for API calls, which cannot be resolved by browser. This causes all API requests to fail with ERR_NAME_NOT_RESOLVED. Root cause: docker-compose.yml line 65 sets VITE_API_URL to 'http://backend:8000/api' which gets baked into the frontend build. Browser cannot resolve 'backend' hostname. Fix required: Change VITE_API_URL in docker-compose.yml from 'http://backend:8000/api' to '/api' (relative URL) so nginx can proxy requests correctly. Evidence: - Browser console shows multiple ERR_NAME_NOT_RESOLVED errors - Network requests to http://backend:8000/api/* all fail - Direct curl tests confirm nginx proxy works: localhost:8080/api/* correctly proxies to backend - But frontend JavaScript uses hardcoded 'http://backend:8000/api' URL See detailed QA report: /tmp/qa-PPLX-28.md
agent · 2025-12-21
## Implementation Complete ### Changes Made **Files created:** - `docker-compose.yml` - Unified deployment configuration - `.env.example` - Environment variable template ### docker-compose.yml Features 1. **Services defined:** - `backend` - FastAPI on port 8000 - `frontend` - React/nginx on port 8080 2. **Network:** - Shared `perplexity-network` bridge network for inter-service communication - Frontend nginx proxies `/api/*` requests to `http://backend:8000` 3. **Volume:** - `perplexity-data` named volume for SQLite database persistence at `/data` 4. **Health checks:** - Backend: Python HTTP check on `/health` endpoint - Frontend: wget check on nginx 5. **Environment variables via .env:** - `PERPLEXITY_API_KEY` - Required for Perplexity API - `CORS_ORIGINS` - Optional production CORS origins ### Verification Results All acceptance criteria verified: - docker-compose up starts both services - localhost:8080 loads frontend (HTML served by nginx) - localhost:8000/health returns {"status":"healthy"} - localhost:8080/api/health proxies to backend successfully - API calls work (tested POST /api/threads and GET /api/threads) - Data persists after container restart (created thread survived backend restart) - Both containers restart cleanly via docker-compose restart