Repository navigation
support plugins from an OCI registry #4480
Description
What do you want to change?
Proposal: support to pull wasm plugins from an OCI registry.
oci://registryfoo.com/my/plugin?tag=v1.5.6
Similar work was done with opentofu plugins: https://opentofu.org/docs/cli/oci_registries
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response
Activity
kyleconroy commentedon Aug 18, 2026
I think HTTPS support is fine for now. No plans to add OCI support.
bobdoah commentedon Oct 19, 2026
Apologies for not searching adequately, or adding any kind of justification.
For my use case, HTTPS not great. I think HTTPS is sufficient for public plugins but there is a gap for private plugins.
In my case, the repository requires authentication. As far as I can tell, sqlc's WASM plugin configuration doesn't support authentication headers or environment variable interpolation in URLs.
This makes private plugin distribution difficult. In particular, a GitHub Actions workflow cannot download a release asset from another private repository using its default GITHUB_TOKEN.
At the moment, this means, for me, a two-step process. I have to first download the plugin using a manually generated PAT.
OCI support and
docker/login-actionwould, in my opinion, make it easier for private plugins to be shared across repositories.It doesn't have to be OCI, environment variable or .netrc would make this workable. OCI just seemed like a good fit, looking at other examples I'd found such as Istio and wasmCloud
danielloader commentedon Oct 19, 2026
That's a fair point - in a private setting you often have a handful of permitted repositories for such things; AWS ECR, ghcr.io, Github self hosted enterprise etc.
Would be extra useful for me to use in Github Actions CI jobs where the plugins are in other private repositories in the same organization and not accessible easily without some laborious steps:
Where as having ghcr.io OCI as an intermediate shared package transport makes it trivial and easier to justify to security teams seeking to review (and block) any external access to potentially untrusted executables in CI jobs.
I appreciate this might not be what sqlc concerns itself with, so just thought I'd throw my two cents in on this as it's something I've just stumbled on myself.
kyleconroy commentedon Oct 19, 2026
@bobdoah what OCI registry / repository are you using?
@danielloader do you also need this? Or are you just speculating how it would be useful.
danielloader commentedon Oct 20, 2026
Found the issue looking for oci support for the above github actions testing using plugins. It's not critical but would be helpful!
bobdoah commentedon Oct 20, 2026
At the moment, Jfrog Artifactory