Files
bambuddy/slicer-api/docker-compose.yml
T
maziggy d120a804ff fix(slicer): name the sidecar service in the update command (#2802)
The "update your sidecar image" advice told users to run a bare
`docker compose pull`. bambu-studio-api is declared with
`profiles: [bambu]`, and compose skips profile-gated services silently,
so the pull was a no-op for exactly the users the message was written
for -- and `restart: unless-stopped` kept the old container serving.
The reporter pulled, restarted, set MAX_MODEL_UPLOAD_MB and got the same
100 MB rejection, because the image never changed.

Name the service in both commands instead. Naming enables the profile
implicitly, for pull and up alike. `--profile bambu` would also work but
downloads the 220 MB Bambu image on an OrcaSlicer-only host and then
starts a sidecar the user never asked for.

Same correction in the sidecar README, the compose header and the
changelog entry, which all carried the bare form.
2026-08-11 08:35:23 +02:00

75 lines
2.6 KiB
YAML

# Optional slicer-API sidecar stack for Bambuddy.
#
# Both services are HTTP wrappers around a slicer CLI: the same Node code
# (`maziggy/orca-slicer-api`, `bambuddy/profile-resolver` branch) bundled
# with a different binary in each image. Bambuddy talks to them via the
# URLs configured in Settings -> Slicer.
#
# bambu-studio-api → host port 3001 (BambuStudio CLI)
# orca-slicer-api → host port 3003 (OrcaSlicer CLI)
#
# Bambuddy's virtual-printer feature reserves host ports 3000 and 3002,
# which is why the OrcaSlicer sidecar sits on 3003. Override either port
# in `.env` (see `.env.example`) if you don't run Bambuddy on this host.
#
# Usage:
# cd slicer-api/
# docker compose up -d # starts OrcaSlicer only
# docker compose --profile bambu up -d # starts both
#
# Updating: `docker compose pull` skips profile-gated services, so a bare
# pull silently leaves bambu-studio-api on its old image (and restart:
# unless-stopped keeps it serving). Use `docker compose --profile bambu pull`,
# or name the service: `docker compose pull bambu-studio-api`.
#
# First start pulls pre-built images from GHCR (~110 MB OrcaSlicer,
# ~220 MB BambuStudio). No local build, no git in the BuildKit worker,
# works on QNAP / Synology / Container Station out of the box.
#
# Both images are linux/amd64 only. OrcaSlicer's ARM64 path is on hold
# pending an upstream extraction fix; BambuStudio doesn't publish ARM64
# at all.
services:
orca-slicer-api:
image: ghcr.io/maziggy/orca-slicer-api:${SIDECAR_TAG:-latest}
container_name: orca-slicer-api
restart: unless-stopped
ports:
- "${ORCA_API_PORT:-3003}:3000"
volumes:
- ./data/orca:/app/data
environment:
NODE_ENV: production
PORT: "3000"
# Largest model accepted for a slice, in MB. See .env.example.
MAX_MODEL_UPLOAD_MB: "${MAX_MODEL_UPLOAD_MB:-512}"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 5s
start_period: 10s
retries: 3
bambu-studio-api:
image: ghcr.io/maziggy/bambu-studio-api:${SIDECAR_TAG:-latest}
container_name: bambu-studio-api
restart: unless-stopped
ports:
- "${BAMBU_API_PORT:-3001}:3000"
volumes:
- ./data/bambu:/app/data
environment:
NODE_ENV: production
PORT: "3000"
# Largest model accepted for a slice, in MB. See .env.example.
MAX_MODEL_UPLOAD_MB: "${MAX_MODEL_UPLOAD_MB:-512}"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 5s
start_period: 10s
retries: 3
profiles:
- bambu