MODSetter/SurfSense

Which part? Desktop app What would you like? Step 14 of 14 of #2100: running SurfSense in Docker. Depends on #2113; start once it is merged. Every CUDA variant on both architectures, and image generation on the GPU. Design: GPU images, Where each runtime comes from What to change A nvidia/cuda:<version>-devel-ubuntu24.04 stage that compiles llama.cpp with -DGGML_CUDA=ON and GGML_CUDA_FA_ALL_QUANTS at the pinned commit, for -cuda on arm64 and -cuda126 on both. sd.cpp compiled with -DSD_CUDA=ON in every CUDA variant. Only the binaries and the CUDA runtime libraries reach the final image. docker-local.yml builds all six variant and architecture pairs, with a registry cache for each. Done when CI publishes the CPU, -cuda and -cuda126 tags for amd64 and arm64. On NVIDIA hardware, a chat turn and an image run on the GPU with each CUDA variant. Scope: code and tests only. Don't edit docs/ or AGENTS.md, except to fix a link this change breaks; the maintainers update the docs when the Doc

Which part? Desktop app What would you like? Step 13 of 14 of #2100: running SurfSense in Docker. Depends on #2112; start once it is merged. Stop the most common GPU mistake: starting a CUDA image without giving it the card, which silently runs on the CPU. Design: GPU images, A CUDA image with no GPU What to change surfsense_local/electron/src/headless/gpu-check.ts: on a CUDA image, run llama-server --list-devices before boot; with no CUDA device, exit with a message naming the fix. SURFSENSE_ALLOW_CPU=1 skips the refusal. Done when A -cuda image started without --gpus exits with the message. With SURFSENSE_ALLOW_CPU=1 it starts on the CPU. The CPU image never runs the check. CI checks both cases on a runner without a GPU. Scope: code and tests only. Don't edit docs/ or AGENTS.md, except to fix a link this change breaks; the maintainers update the docs when the Docker work ships. Why would it help? Each step leaves something that runs, so the Docker image is built and reviewed

Which part? Desktop app What would you like? Step 12 of 14 of #2100: running SurfSense in Docker. Depends on #2111; start once it is merged. Chat on an NVIDIA GPU, with the first CUDA variant. Design: GPU images, Variants What to change ARG VARIANT=cpu|cuda in the Dockerfile; the cuda runtimes stage downloads llama.cpp's bin-ubuntu-cuda-12.8-x64 and its cudart archive. Only one ggml backend per image. docker/local/docker-compose.gpu.yml with the NVIDIA device reservation. docker-local.yml builds and publishes -cuda for amd64. Done when On an NVIDIA machine with the Container Toolkit, the fit estimate shows the card's VRAM and a local chat runs on the GPU. CI publishes the -cuda tag. Scope: code and tests only. Don't edit docs/ or AGENTS.md, except to fix a link this change breaks; the maintainers update the docs when the Docker work ships. Why would it help? Each step leaves something that runs, so the Docker image is built and reviewed one piece at a time.

Which part? Desktop app What would you like? Step 11 of 14 of #2100: running SurfSense in Docker. Depends on #2110; start once it is merged. Encrypt the connection when the app is reached over a network. Design: Docker proposal, Caddy and access What to change SURFSENSE_DOMAIN: Caddy serves that domain with an automatic certificate. SURFSENSE_TLS=internal: Caddy's own CA, for a LAN. Compose publishes 443 when either is set. Done when With SURFSENSE_TLS=internal, https://<lan-host> works after trusting Caddy's CA. With a public domain pointed at the host, a certificate is issued. Both modes require the password from the previous step. Scope: code and tests only. Don't edit docs/ or AGENTS.md, except to fix a link this change breaks; the maintainers update the docs when the Docker work ships. Why would it help? Each step leaves something that runs, so the Docker image is built and reviewed one piece at a time.

Which part? Desktop app What would you like? Step 10 of 14 of #2100: running SurfSense in Docker. Depends on #2109; start once it is merged. Reach the app from other machines, behind a password. Design: Docker proposal, Caddy and access What to change docker/local/caddy/access-password.caddy: basic_auth, answering the hosts in SURFSENSE_ALLOWED_HOSTS, or any when it is empty. The headless entry hashes SURFSENSE_PASSWORD with caddy hash-password at start and picks the access file: password set means access-password, otherwise access-local. Compose and .env.example gain SURFSENSE_PASSWORD, SURFSENSE_ALLOWED_HOSTS and SURFSENSE_BIND. Done when With a password and SURFSENSE_BIND=0.0.0.0, another machine on the LAN gets a login prompt, and after it the app, chat streaming and live updates work. Without a password, the same request is refused. The password never appears in logs or in the generated config on disk. Scope: code and tests only. Don't edit docs/ or AGENTS.md, except to fix