Docker instances reported most deployment fields as unknown. Report how
and when the container image was built, separately from how the
instance was deployed:
- Dockerfile: optional EDGE_EVER_BUILD_CREATED_AT, EDGE_EVER_BUILD_TRIGGER
and EDGE_EVER_BUILD_METHOD build args, empty by default.
- /api/health (self-hosted-bun only): optional buildCreatedAt and
buildProvenance. deploymentVersionCreatedAt and deployment keep their
meaning and stay runtime-supplied; Cloudflare responses are unchanged.
- docker-image.yml: official images record the build time and their
provenance. Draft-release builds dispatched with release_tag are
github_release, main pushes main_push, other dispatches manual.
The container test checks the health response for a metadata build
with runtime overrides and for a default self-build; the post-publish
audit checks the published image.
- Add an explicit `docker` deployment method. It is never inferred from
the runtime, and the registry source still comes only from
EDGE_EVER_CONTAINER_IMAGE.
- Web/desktop show "Image built at" and "Image build source" for Docker;
Android shows "Image built at". Older clients ignore the new fields.
- Document the build args and runtime variables in both Docker guides.
Co-authored-by: tianma-if <yingwaizhiying@gmail.com>
Official entries stay on the bundled registry. The instance returns a community file only when EDGE_EVER_COMMUNITY_REGISTRY_URL is set, and submission opens from its own marketplace entry.
NAS GUI upgrades that drop container environment variables could leave
login working while AI and object-storage credentials could no longer be
encrypted. Persist the encryption root on /data, generate one when an
existing instance has no secret, and stop the add-service form from
looking fillable when encryption is still unavailable.
Fixes#370
Let instance owners route new uploads to an external OSS while keeping
existing attachments on their original store. Secrets are encrypted with
EDGE_EVER_STORAGE_ENCRYPTION_KEY before being stored in D1.
