Publish Qortium Core container images and support TrueNAS SCALE

[QuickMythril]

Summary

Publish supported, versioned Qortium Core container images and provide a tested TrueNAS SCALE deployment path so operators can run a node without maintaining a full virtual machine or compiling Core locally.

This preserves the practical request from Q-Support record 0ed70b3130dc89f10c30dd76, “Qortal Core addition to TrueNAS Scale Apps Section.” The reporter was running Core in a TrueNAS SCALE VM and wanted a lower-overhead app with better visibility in the TrueNAS interface.

This is packaging and release-operations work, not a consensus change.

Current state

Qortium Core already provides:

• a multi-stage Docker build;
• a non-root runtime user;
• a persistent /qortium data volume;
• API health checking;
• public and internal Compose configurations; and
• restart and API/P2P/QDN binding controls.

It does not yet provide:

• a public pullable image in a container registry;
• a release-triggered image build and immutable digest;
• a Compose configuration that consumes a published image;
• a tested current TrueNAS SCALE Custom App recipe;
• container-specific upgrade, rollback, backup, and restore guidance; or
• an official TrueNAS community catalog app.

A Docker port-contract correction has been prepared locally as the first prerequisite. It aligns the example environment with Qortium ports 14891/14892/14894, makes Compose health checks follow a deliberately customized API port, and adds CI coverage for default and custom public/internal configurations. That work still needs its own PR and merge. No GHCR image or TrueNAS app has been published.

Phase 0: stabilize the container contract

• Merge the port-contract correction.
• Keep the API loopback-only by default.
• Verify persistent-volume permissions for the non-root runtime user.
• Test startup, health, restart, clean shutdown, and persistence.
• Document which settings must move with customized API/P2P/QDN ports.

Phase 1: publish release images to GHCR

• Publish linux/amd64 images initially at ghcr.io/qortiumdev/qortium-core.
• Trigger publication only from an approved stable GitHub release/tag.
• Use the repository GITHUB_TOKEN with least-privilege package permissions.
• Attach OCI source, revision, version, license, and description metadata.
• Publish exact-version tags and immutable digests; update latest only for stable releases.
• Link the public package to this repository.
• Pull the resulting image by digest and smoke-test health, persistence, restart, and shutdown.
• Retain a source-build Compose path for developers.

Phase 2: support a TrueNAS SCALE Custom App

• Provide a tested Compose/YAML recipe that pulls the published image.
• Persist /qortium in an explicitly created dataset or supported app volume.
• Expose P2P and QDN ports while making API exposure an explicit operator choice.
• Define CPU, memory, storage, ownership, and health settings.
• Test fresh install, initial sync, restart, Core upgrade, rollback, and backup/restore on current TrueNAS SCALE.
• Pin an exact release version or digest rather than silently following latest.

Phase 3: consider official catalog inclusion

After the Custom App path is stable, evaluate an official TrueNAS community catalog submission with the required app schema, templates, tests, icon, screenshots, documentation, version bumps, and named maintenance ownership.

Official catalog acceptance is not required for this issue to deliver the first usable no-VM TrueNAS deployment.

Acceptance criteria

• The port contract is merged and protected by CI.
• A public repository-linked GHCR image is available for an approved Core release.
• Published image tags resolve to documented immutable digests.
• A clean host can pull and run the image without cloning or compiling Core.
• Core health, persistent state, restart, shutdown, upgrade, rollback, and backup/restore behavior are verified.
• A current TrueNAS SCALE system successfully runs the documented Custom App configuration.
• API access remains private by default; P2P/QDN exposure and data ownership are explicit.
• Release and operator documentation identify the supported image, version policy, persistent paths, ports, resource guidance, and recovery procedure.