Brief Description
The current PRs (see NethServer/sogo-server#12 and NethServer/ns8-sogo#81) propose switching the SOGo container base from Arch Linux to Debian Trixie, using a multi-stage build process.
Why/What is the purpose?
- Dramatic image size reduction: From 2GB to 400MB, making it lighter and more efficient for deployments.
- More familiar architecture: Debian-based containers are widely recognized and maintained in the community. This should make onboarding easier for new contributors and admins.
- Greater autonomy for updates: Moving away from the AUR allows maintainers to control and follow SOGo releases independently, reducing upstream dependency risk.
Proposed solution
Adopt the multi-stage build described in the referenced PRs:
- Use
debian:trixie and debian:trixie-slim as the build and runtime bases.
- Compile and stage only runtime artifacts, stripping unnecessary files and binaries for minimal footprint.
- Update services, paths, and configurations to follow Debian's conventions (Apache2, cron, library locations, etc.)
- Use multi-stage Docker/podman with build scripts that benefit from layer caching for faster builds.
Alternative solutions
- Retain the current Arch Linux/AUR-based workflow, acknowledging the tradeoffs (larger images, less common base OS, more upstream dependency risk).
- Explore Alpine Linux as another minimal container base, though Debian offers greater compatibility and support for SOGo and its ecosystem.
Additional context
See also
Brief Description
The current PRs (see NethServer/sogo-server#12 and NethServer/ns8-sogo#81) propose switching the SOGo container base from Arch Linux to Debian Trixie, using a multi-stage build process.
Why/What is the purpose?
Proposed solution
Adopt the multi-stage build described in the referenced PRs:
debian:trixieanddebian:trixie-slimas the build and runtime bases.Alternative solutions
Additional context
See also