Build reusable, testable, and maintainable Nextcloud container images

[vitormattos]

Goal

Create a common and reusable foundation for the Nextcloud container images used by LibreCode and LibreSign environments.

Today, some build rules are specific to one Nextcloud version, image conventions are not always consistent, and different environments can define similar runtime logic in different ways.

We want to reduce this duplication and make the container architecture easier to update, test, secure, and reuse.

Objectives

• Provide reusable Nextcloud base images for development, testing, production, and application-specific environments.
• Keep stable images based on the official Nextcloud container images whenever possible.
• Provide a reusable way to follow the current Nextcloud Server master without creating a new version-specific build for every development cycle.
• Keep development images close enough to Nextcloud master to support applications, such as LibreSign main, that follow changes in the Nextcloud public APIs without waiting for an alpha, beta, or release candidate.
• Reuse official Nextcloud build and release processes where possible, and keep LibreCode-specific changes small and clear.
• Make image builds reproducible and traceable to their upstream sources.
• Define consistent image naming and tagging rules.
• Make automated testing and security checks part of the normal image lifecycle.
• Reduce duplicated Docker and runtime configuration between LibreCode repositories.
• Allow Docker Compose environments to reuse and extend common image foundations instead of rebuilding the same runtime in different ways.
• Prepare a common base that can later support simple deployment recipes for different hosts and cloud providers, including small and low-cost environments.
• Provide clear repository guidance for contributors and AI tools.

Architecture direction

nextcloud-docker should provide generic and reusable Nextcloud runtime foundations.

LibreSign-specific code, development tools, and environment-specific configuration should be added by the environments that need them instead of becoming part of the generic Nextcloud base image.

Stable and development images may use different upstream sources, but they should follow the same rules for reuse, testing, security, traceability, and maintenance.

Development and deployment environments should extend these common foundations whenever possible.

The architecture must continue to work when Nextcloud development moves from one major version to the next, without adding another version-specific implementation.

Expected result

LibreCode should have a predictable container image lifecycle for stable and development versions of Nextcloud.

Development, testing, LibreSign, and future deployment environments should be able to share the same runtime foundations and add only what each environment needs.

Changes must be introduced step by step. Existing environments must continue working until their replacements are tested and ready.

This work should reduce maintenance between repositories and provide a safe base for future automated and one-click deployment options.

Principles

• Prefer upstream solutions over custom replacements.
• Keep generic Nextcloud images independent from LibreSign-specific requirements.
• Reuse and extend existing image foundations instead of duplicating runtime definitions.
• Keep final runtime images focused on what is required to run the service.
• Treat security, testability, reproducibility, and traceability as default requirements.
• Do not replace a working environment before its replacement is tested and ready.