HomeCloud v0.5.0

Trust and operations: signed releases, safe upgrades with rollback, backups that restore everything, Prometheus metrics and a status page, and Testcontainers for Java and Node.

• Signed releases: the release workflow signs checksums.txt with Sigstore keyless signing (cosign, GitHub OIDC; published as checksums.txt.sigstore.json), attaches an SPDX SBOM for each binary, and records GitHub build provenance for the archives. The container image is signed with cosign and carries an SPDX SBOM attestation and build provenance. Third-party actions in the release workflow are pinned to commit SHAs. Verification commands are in SECURITY.md.
• homecloud upgrade verifies the release signature against the release workflow's identity before trusting checksums.txt, and refuses unsigned releases; releases up to v0.4.1, published before signing, install only with --allow-unsigned (with a warning). The install scripts verify the signature when cosign is installed and fall back to the checksum with a message otherwise; install.ps1 now verifies the checksum too.
• Safer upgrades: homecloud upgrade saves the data directory's state (state, config, credentials, master key, DynamoDB, queue files) to <data-dir>/upgrade-backups/<version>-<time>/ and keeps the previous binary as <binary>.previous; the last 3 backups are kept. homecloud upgrade --rollback (server stopped) restores the previous binary and, if the new version already ran on the data, the saved state.
• The data directory records the newest HomeCloud version that used it (data-version.json), and homecloud serve refuses to start on data written by a newer version, with a message suggesting homecloud upgrade or --rollback (--allow-newer-data overrides). homecloud backup leaves upgrade backups out.
• After homecloud restore onto a host without the containers, RDS and ElastiCache instances are recreated from their restored data volumes at start (same engine, version, class, endpoint, address, password, groups) instead of showing failed; stopped ones stay stopped. Load balancers whose container is gone are re-provisioned, and EC2 container instances come back stopped with their volumes instead of being terminated (which deleted their volumes) (#106).
• Prometheus metrics at GET /metrics on the API port: requests by API (native or AWS), service and operation (route patterns and AWS operation names, never IDs), errors by code, latency histograms, in-flight requests, authentication failures, managed containers by service and state, Docker reachability, MinIO/ECR/DNS/IMDS helper state, data directory and volume disk use, background loop last-run age, Lambda environments and cold/warm starts, process metrics and build info. It requires the IAM action homecloud:GetMetrics (an access key as a bearer token or HTTP basic auth, so Prometheus can scrape it); --metrics-addr 127.0.0.1:9464 adds an unauthenticated listener, loopback-only unless --metrics-addr-insecure.
• GET /api/v1/system/status (IAM action homecloud:GetSystemStatus) reports each subsystem's health, versions, uptime, Docker details, disk use and recent errors; the console shows it on a new System status page with a copyable Prometheus scrape config. GET /api/v1/health is unchanged.
• docs/monitoring.md: scrape configs, a least-privilege Prometheus user, a Grafana dashboard (docs/grafana/homecloud.json) and alert rules.
• Testcontainers modules for Java (io.github.solinode:testcontainers-homecloud, integrations/testcontainers-java) and Node.js (testcontainers-homecloud on npm, integrations/testcontainers-node): start HomeCloud from a JUnit or Node test, get the endpoint, credentials and ready AWS SDK clients or client config, and remove every container HomeCloud started on stop. Release workflows publish them to Maven Central and npm from testcontainers-java/v* and testcontainers-node/v* tags.