Summary
VastCreateInstanceRequest exposes no way to send Vast's image_login field, so an instance can only be created from an image that is anonymously pullable. Any private registry (ACR, ECR, GHCR, private Docker Hub) is out of reach, and the failure happens on the host after the rental is created.
Why it matters
Vast's create instance API accepts image_login ("Docker registry credentials if needed"), which the official CLI surfaces as --login "-u <user> -p <password> <registry>".
For anyone running proprietary workloads this is the difference between usable and not: the alternatives are publishing the image or not using the library. There's no workaround from OnStart either, since that runs inside the container — after the pull has already failed.
Where
src/VastAI.NET/Models/VastCreateInstanceRequest.cs — the request has Image, TemplateHashId, RuntimeType, Environment, OnStart, DiskGb, Label, CancelUnavailable, but no registry-credential field.
Suggested fix
Add an optional property serialized to image_login, passed through untouched:
/// <summary>Optional Docker registry credentials, in Vast's docker-login argument form
/// (e.g. "-u user -p password myregistry.example.com"). Required for a private image.</summary>
public string ImageLogin { get; set; } = "";Additive and backwards-compatible — empty stays absent from the payload, so existing callers are unaffected.
A friendlier typed overload (registry/username/password formatted into the string by the client) would be nicer still, but the raw pass-through alone unblocks the scenario.
Version
VastAI.NET 1.0.3 (net10.0).
Note on a nearby doc nit
While reading the source: RuntimeType defaults to "ssh" and its doc comment says "This workflow uses SSH-capable containers." It took reading the source to establish that the property is freely settable — e.g. to "args" for entrypoint mode, which is what batch/run-to-completion workloads need. Worth a doc mention that non-SSH runtypes are supported, since the current wording reads as though the library is SSH-only.
Summary
VastCreateInstanceRequestexposes no way to send Vast'simage_loginfield, so an instance can only be created from an image that is anonymously pullable. Any private registry (ACR, ECR, GHCR, private Docker Hub) is out of reach, and the failure happens on the host after the rental is created.Why it matters
Vast's create instance API accepts
image_login("Docker registry credentials if needed"), which the official CLI surfaces as--login "-u <user> -p <password> <registry>".For anyone running proprietary workloads this is the difference between usable and not: the alternatives are publishing the image or not using the library. There's no workaround from
OnStarteither, since that runs inside the container — after the pull has already failed.Where
src/VastAI.NET/Models/VastCreateInstanceRequest.cs— the request hasImage,TemplateHashId,RuntimeType,Environment,OnStart,DiskGb,Label,CancelUnavailable, but no registry-credential field.Suggested fix
Add an optional property serialized to
image_login, passed through untouched:Additive and backwards-compatible — empty stays absent from the payload, so existing callers are unaffected.
A friendlier typed overload (registry/username/password formatted into the string by the client) would be nicer still, but the raw pass-through alone unblocks the scenario.
Version
VastAI.NET 1.0.3 (net10.0).
Note on a nearby doc nit
While reading the source:
RuntimeTypedefaults to"ssh"and its doc comment says "This workflow uses SSH-capable containers." It took reading the source to establish that the property is freely settable — e.g. to"args"for entrypoint mode, which is what batch/run-to-completion workloads need. Worth a doc mention that non-SSH runtypes are supported, since the current wording reads as though the library is SSH-only.