Repository navigation
Docker image with every release: the Linux app as a container for the SuperCloud #41
Description
Goal
Publish a Docker image with every release in which the Linux build of this tool runs and is viewable in the browser. The OpenAEC SuperCloud gives each user their own Linux environment on the server, with one container per tool, so the tool opens as a regular Linux program instead of loading in the browser.
This is the regular graphical app streamed to the browser, not a headless API or library.
The common contract for all OpenAEC tools is OpenAEC-Blueprint#61. Open PDF Studio follows the same model in open-pdf-studio#863. The Blueprint provides a ready template in templates/docker/ (Dockerfile, start script, container test and the release-workflow steps; in review on the Blueprint branch feat/docker-image), so this tool only says which package goes in and which program starts.
Requirements
- Name and version:
ghcr.io/openaec-foundation/open-pointcloud-studio:<YYYY.W.N>pluslatest, same version as the release.linux/amd64for now. - Built from the release itself: install the release's
.deb(or the extracted AppImage,--appimage-extract, so no FUSE is needed). No separate build of the app. - One app, no desktop: the container starts only this tool, full screen, in a minimal graphical session, streamed to the browser on one HTTP port (
3000). - Fixed folders:
/openaecfor the user's files (mounted from outside; open/save dialogs start here) and/configfor the app's settings (volume, persisted). - No root: runs as a regular user; no
--privileged, no FUSE, no GPU in the first version. - Configuration via environment variables, documented in the README (language, theme, optional file to open on start).
- Health: a
HEALTHCHECKand an endpoint (GET /gezond) that only reports OK when the app is actually running. - Network: no outgoing connections beyond those documented in the README; update checks off in the container (updates come with a new image).
- AI integration (if the tool has one): the tool's MCP server runs in the same container on its own port, for the internal network only.
- Light at rest: the memory use of the container with no file open goes in the release notes.
- Signed: image signed with cosign (keyless via GitHub OIDC), with a build attestation and an SBOM, like the other release files.
- Tested before publishing: in the release workflow the container starts, becomes healthy, the app process runs and a screenshot of the stream can be taken.
- README: a short "Docker" section with
docker run -p 3000:3000 -v <folder>:/openaec ghcr.io/openaec-foundation/open-pointcloud-studio:latestand the variables the tool supports.
How
- Copy the files from the Blueprint's
templates/docker/unchanged topackaging/docker/in this repository. - Put tool-specific preparation (for example writing a theme or language from an environment variable to the settings file) in
packaging/docker/setup.d/*.sh. - Take over the
dockerjob and the image steps of thepublishjob from the Blueprint's.github/workflows/release.yml, with this tool's package name, program and description.
Activity
boazeggs commentedon Nov 5, 2026
Implementation prepared in #58 (draft while final native checks run).
Add the supported native SuperCloud route B described by the current Blueprint contract. Managed windows honour OPENAEC_MAP, OPENAEC_TAAL and OPENAEC_THEMA without overwriting desktop preferences, and handle SIGTERM through the normal application exit path. A separate --mcp-http process exposes the exact desktop MCP operations under pointcloud_ names, including pointcloud_open and pointcloud_opslaan, with bearer authentication, Origin refusal, bounded sessions/calls, cancellation and a health endpoint that checks the GUI command path. Stdio MCP names remain compatible.
The Linux package matrix now exercises the extracted AppImage under headless labwc/Wayland with Mesa lavapipe, without FUSE or a GPU. The repeatable probe checks authentication, session lifecycle, 166 tool definitions, opening/saving 1,000 points, screenshots, SIGTERM and unhealthy status after exit.
Validation so far:
Refs #41 and #52; neither is automatically closed. The current central-image contract supersedes #41's per-tool Docker image request. Browser-only route A and recovery of arbitrary unsaved point edits are outside this implementation. SIGTERM flushes the existing drawing project and cancels background work, but does not invent a persistent scan-edit project format. Deployment and platform-side TLS/mount isolation remain to be verified in the actual host.
boazeggs commentedon Nov 6, 2026
PR #58 staat nu samen met de overige wijzigingen in integratie-PR #53. De gecombineerde native GUI is daadwerkelijk getest via 167 desktop-MCP-tools: 1.000 punten openen en opslaan, authenticatie/Origin-weigering, afsluiten via SIGTERM en ongezonde status na afsluiten. Ook een belangrijke combinatie is opgelost en getest: wanneer de gebruiker MCP pauzeert, blijven opdrachten geblokkeerd terwijl de draaiende GUI gezond blijft. Hiervoor gebruikt
/gezondeen afzonderlijke GUI-heartbeat. Beide modi zijn aangesloten op de Linux-pakketcontroles.De native app gebruikte lokaal ongeveer 250 MiB in rust met software-Vulkan; dit is het app-proces, geen meting van een gedeployde container. De volledige gecombineerde Rust-workspace heeft 1.424 geslaagde tests zonder fouten.
Dit issue blijft open voor de daadwerkelijke SuperCloud-host/Docs-koppeling en deploymentacceptatie. De implementatie volgt de ondersteunde native route B en het huidige gedeelde Blueprint-contract zoals in #58 beschreven; er wordt geen ondersteunde browsereditie of reeds uitgevoerde clouddeployment geclaimd.