Files
b11a15f1c0 [Feature]: Server-Side Slicing on linux/arm64 systems (#1900)
* Add override file for ARM64 setups.

This commit adds an override file which explicitly specifies the container platform to be linux/amd64.
It forces docker to pull/build/run the amd64 image (even on arm64 hosts).
Assuming binfmt support is set up, this will run the amd64 applications via emulation.

* Add arm64 override file information to README.

Adds a section covering the experimental setup for
arm64 hosts to the README.

* Make the ARM64 override survive the next compose command (#1900)

The override only applies while both -f flags are on the command line, and
every other instruction in this README is written bare. An ARM64 user who
followed the update steps would drop the platform pin without noticing: a
manifest error today, and a silent switch off emulation once native ARM64
images ship. The quick start now writes COMPOSE_FILE into .env, so the rest
of the file works unchanged on ARM64 -- verified both ways, with and without
that line.

Two things the setup needs stated where it is read rather than one hop away
in the wiki: binfmt has to be registered on the host or the container dies
with "exec format error", and emulation costs roughly 3-6x native slice
time. Both now lead the section, and the separate-x86_64-box route stays the
recommendation it was -- emulation is the fallback for people who have no
second machine, not a replacement.

The compose file's own header said ARM64 was a dead end. It now points at
the override, for anyone who reads the stack instead of the README.

---------

Co-authored-by: MartinNYHC <martin@bambuddy.cool>
Co-authored-by: maziggy <mz@v8w.de>
2026-08-15 12:18:36 +02:00

78 lines
2.9 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. ARM64 hosts are best served by running the sidecar on a separate
# x86_64 box; failing that, `docker-compose.arm64.yml` in this directory
# runs these same images under QEMU emulation — experimental, ~3-6x slower,
# and it needs binfmt set up on the host. See the README.
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