Can oci-archive use a network location?

[kolotaev]

Hello 👋

Is it possible to make image work with network locations?

Example is:

    task "my-http" {
      driver = "podman"
      config {
        image = "oci-archive:http://10.211.55.9:9999/uploads/myhttp.tar"
      }
    }

Where myhttp.tar is an archive that I serve via HTTP.

I created it via podman save --format oci-archive -o /tmp/uploads/myhttp.tar myhttp:latest.

Note, that podman itself supports getting archive be it filesystem or a network location. Consider this:

podman load -i http://10.211.55.9:9999/uploads/myhttp.tar
Getting image source signatures
Copying blob 99cf8ab899fa skipped: already exists  
Copying blob 41cbe294e54d skipped: already exists  
Copying blob 870027e70bc9 skipped: already exists  
Copying blob fc8a6b71fc5e skipped: already exists  
Copying config 58e9d534e8 done  
Writing manifest to image destination
Storing signatures
Loaded image: myhttp:latest

[mcpherrinm]

As a workaround, I think you can use an artifact block to fetch it, but then note #389 on the image path to pass to podman

[tgross]

Just a heads up that I took a look at this and wasn't able to make it work by passing that oci-archive transport like this. The error you get is like the following:

2025-09-17T16:26:43.070-0400 [ERROR] client.alloc_runner.task_runner: running driver failed: alloc_id=819866eb-1f6d-433d-8d35-3ca5f3ba8d0a task=http error="rpc error: code = Unknown desc = failed to create image: oci-archive:http://192.168.1.194:9999/busybox.tar: invalid image reference oci-archive:http://192.168.1.194:9999/busybox.tar: Invalid image //192.168.1.194:9999/busybox.tar"

That's bubbling up from the image parse in upstream's oci_util.go. If I had to guess, podman is providing their own upstack abstraction at that point. But something worth thinking about doing here so folks can avoid having to use artifact. Will mark it for roadmapping.