velxio/docker-compose.yml

45 lines
1.4 KiB
YAML
Raw Normal View History

# Development Docker Compose — same image as production for full parity.
# Usage: docker compose up --build
# Access: http://localhost:3080
fix(install): unblock self-hosting + drop forced wokwi clones Resolves several install pain points reported by users (#108, #120) and removes the obligatory upstream-clone step that confused contributors and slowed down every Docker build. Install fixes: - nginx: server_name → catch-all default_server, drop Debian's stock site so reverse-proxied users no longer get the "Welcome to nginx" page. - entrypoint: auto-generate SECRET_KEY at first boot, persisted under data/.secret_key. backend/.env is now optional in docker-compose.yml. - backend: add greenlet>=3.0.0 (SQLAlchemy async dep that was missing on some Python builds — caused uvicorn startup failures on WSL). Wokwi libs come from npm: - @wokwi/elements 1.9.2, avr8js 0.21.0, rp2040js 1.3.2 are pinned in frontend/package.json. Vite aliases removed. - Dockerfile.standalone no longer clones avr8js / rp2040js / wokwi-elements / wokwi-boards. Frontend stage is just COPY + npm install + build:docker. - Board SVGs vendored under frontend/public/boards/ (10 deduped against existing files, 2 truly new). third-party/wokwi-* clones become reference- only credits — generate-component-metadata.ts skips gracefully when absent. Production config split out: - docker-compose.prod.yml, deploy/nginx.prod.conf, nginx-host-velxio*.conf, update-third-party.bat removed. Production deployment lives in its own repo: https://github.com/velxio/velxio-prod (host nginx + HTTPS + backups + pinned upstream commit). Verified locally: 1161 frontend tests pass, build:docker completes clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-04 10:04:11 +07:00
#
# backend/.env is OPTIONAL. If missing, the entrypoint generates a random
# SECRET_KEY so the app boots out-of-the-box. Create backend/.env (copy
# backend/.env.example) only when you need OAuth or want a fixed SECRET_KEY.
services:
velxio:
build:
context: .
dockerfile: Dockerfile.standalone
container_name: velxio-dev
restart: unless-stopped
ports:
- "3080:80"
env_file:
fix(install): unblock self-hosting + drop forced wokwi clones Resolves several install pain points reported by users (#108, #120) and removes the obligatory upstream-clone step that confused contributors and slowed down every Docker build. Install fixes: - nginx: server_name → catch-all default_server, drop Debian's stock site so reverse-proxied users no longer get the "Welcome to nginx" page. - entrypoint: auto-generate SECRET_KEY at first boot, persisted under data/.secret_key. backend/.env is now optional in docker-compose.yml. - backend: add greenlet>=3.0.0 (SQLAlchemy async dep that was missing on some Python builds — caused uvicorn startup failures on WSL). Wokwi libs come from npm: - @wokwi/elements 1.9.2, avr8js 0.21.0, rp2040js 1.3.2 are pinned in frontend/package.json. Vite aliases removed. - Dockerfile.standalone no longer clones avr8js / rp2040js / wokwi-elements / wokwi-boards. Frontend stage is just COPY + npm install + build:docker. - Board SVGs vendored under frontend/public/boards/ (10 deduped against existing files, 2 truly new). third-party/wokwi-* clones become reference- only credits — generate-component-metadata.ts skips gracefully when absent. Production config split out: - docker-compose.prod.yml, deploy/nginx.prod.conf, nginx-host-velxio*.conf, update-third-party.bat removed. Production deployment lives in its own repo: https://github.com/velxio/velxio-prod (host nginx + HTTPS + backups + pinned upstream commit). Verified locally: 1161 frontend tests pass, build:docker completes clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-04 10:04:11 +07:00
- path: ./backend/.env
required: false
environment:
- DATABASE_URL=sqlite+aiosqlite:////app/data/velxio.db
- DATA_DIR=/app/data
- IDF_PATH=/opt/esp-idf
- IDF_TOOLS_PATH=/root/.espressif
- ARDUINO_ESP32_PATH=/opt/arduino-esp32
perf(espidf): drop in ccache for ESP32 compiles (~10× warm speedup) Cold first compile per container is unchanged (cache empty). Subsequent compiles drop from ~5-7 minutes to ~30-60 seconds because every ESP-IDF base object (FreeRTOS, lwIP, esp_wifi, libsodium, soc, hal, …) hits the cache. The user's BMP280 example, which hangs on cold compile, completes near-instantly on the second attempt. Why a transparent cache is safe: ccache hashes the preprocessed source + flags + compiler. A cache hit only happens when the input is byte-for-byte identical to a prior compile. Different sketches with different libraries still get correct cache misses; there is no path where one project's output contaminates another. Changes - Dockerfile.standalone: install ccache, set CCACHE_DIR=/var/cache/ccache, IDF_CCACHE_ENABLE=1, configure 2 GB cap with compression. Compression (level 6) cuts cache disk usage by ~40% with negligible CPU overhead. - docker-compose.yml: named volume `ccache:/var/cache/ccache` so the cache survives `docker compose up -d --build` (without it, every image rebuild discards the cache). - backend/app/services/espidf_compiler.py: pass `-DCCACHE_ENABLE=1` to cmake when IDF_CCACHE_ENABLE is truthy. ESP-IDF's project.cmake (`set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)` on line 374) is what actually wires ccache in; without the cmake -D flag the env var alone has no effect because we don't go through idf.py. Escape hatch: set IDF_CCACHE_ENABLE=0 in compose env to disable without rebuilding the image. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 10:44:29 +07:00
# ccache for ESP-IDF compiles — the named volume below persists hits
# across container restarts and image rebuilds. Set IDF_CCACHE_ENABLE=0
# to disable without changing the Dockerfile.
- IDF_CCACHE_ENABLE=1
- CCACHE_DIR=/var/cache/ccache
volumes:
- ./data:/app/data
- arduino-libs:/root/.arduino15
perf(espidf): drop in ccache for ESP32 compiles (~10× warm speedup) Cold first compile per container is unchanged (cache empty). Subsequent compiles drop from ~5-7 minutes to ~30-60 seconds because every ESP-IDF base object (FreeRTOS, lwIP, esp_wifi, libsodium, soc, hal, …) hits the cache. The user's BMP280 example, which hangs on cold compile, completes near-instantly on the second attempt. Why a transparent cache is safe: ccache hashes the preprocessed source + flags + compiler. A cache hit only happens when the input is byte-for-byte identical to a prior compile. Different sketches with different libraries still get correct cache misses; there is no path where one project's output contaminates another. Changes - Dockerfile.standalone: install ccache, set CCACHE_DIR=/var/cache/ccache, IDF_CCACHE_ENABLE=1, configure 2 GB cap with compression. Compression (level 6) cuts cache disk usage by ~40% with negligible CPU overhead. - docker-compose.yml: named volume `ccache:/var/cache/ccache` so the cache survives `docker compose up -d --build` (without it, every image rebuild discards the cache). - backend/app/services/espidf_compiler.py: pass `-DCCACHE_ENABLE=1` to cmake when IDF_CCACHE_ENABLE is truthy. ESP-IDF's project.cmake (`set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)` on line 374) is what actually wires ccache in; without the cmake -D flag the env var alone has no effect because we don't go through idf.py. Escape hatch: set IDF_CCACHE_ENABLE=0 in compose env to disable without rebuilding the image. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 10:44:29 +07:00
- ccache:/var/cache/ccache
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 90s
volumes:
arduino-libs:
perf(espidf): drop in ccache for ESP32 compiles (~10× warm speedup) Cold first compile per container is unchanged (cache empty). Subsequent compiles drop from ~5-7 minutes to ~30-60 seconds because every ESP-IDF base object (FreeRTOS, lwIP, esp_wifi, libsodium, soc, hal, …) hits the cache. The user's BMP280 example, which hangs on cold compile, completes near-instantly on the second attempt. Why a transparent cache is safe: ccache hashes the preprocessed source + flags + compiler. A cache hit only happens when the input is byte-for-byte identical to a prior compile. Different sketches with different libraries still get correct cache misses; there is no path where one project's output contaminates another. Changes - Dockerfile.standalone: install ccache, set CCACHE_DIR=/var/cache/ccache, IDF_CCACHE_ENABLE=1, configure 2 GB cap with compression. Compression (level 6) cuts cache disk usage by ~40% with negligible CPU overhead. - docker-compose.yml: named volume `ccache:/var/cache/ccache` so the cache survives `docker compose up -d --build` (without it, every image rebuild discards the cache). - backend/app/services/espidf_compiler.py: pass `-DCCACHE_ENABLE=1` to cmake when IDF_CCACHE_ENABLE is truthy. ESP-IDF's project.cmake (`set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)` on line 374) is what actually wires ccache in; without the cmake -D flag the env var alone has no effect because we don't go through idf.py. Escape hatch: set IDF_CCACHE_ENABLE=0 in compose env to disable without rebuilding the image. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 10:44:29 +07:00
ccache: