There's lots of examples of folks packaging non-container-image things and stuffing them in a registry:

- cosign signatures, SBOMs, attestations: https://docs.sigstore.dev/cosign/overview/

- Istio wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensio...

- OPA bundles: https://www.openpolicyagent.org/docs/v0.13.5/bundles/

- Tekton bundles: https://github.com/tektoncd/resolution/tree/main/bundleresol...

There's even a demo (plug: in a talk I co-presented) of running a RISC-V emulator where its memory is stored in an OCI registry: https://www.youtube.com/watch?v=Xt_G-pUArTM

These all tend to include a CLI to collect/generate/validate resources and push/move/pull them, but the underlying implementation is roughly the same -- package content in a tarball, generate some JSON pointing to it, push that JSON to the registry (with auth).

The real benefit to this is that basically everyone has access to a registry these days -- in their cloud provider, on-prem, whatever -- with exactly the same APIs and mostly sane auth and client tooling.

If you're interested in exploring it for your use case let me know, I'd be happy to give you some pointers.

Note that with "Docker as package" style development, you lose the ability to specify dependencies. Consider building real packages, then installing them in shim Docker images. This gives you the best of both worlds: rich dependency specification, and "just run the thing" facility with Docker.

I gave a very compressed lightning talk last year about this: https://youtu.be/ExyWAhS2zBA

I can't find the code anymore but I originally saw this in docker/compose.

I forget what they were using it for, but it boiled down to packing up a json file or two in a tarball and pushing it to the local daemon with a special suffix. Then it could pull that and unpack it on the next run.