Bring your image
A container image contains your code and everything that the code needs to run. You send the image to Hangar once, and then run the image on a GPU or CPU as many times as you want.
Hangar stores the image in Sydney, under the key of your organisation. A job costs the price of its GPU or CPU. This page covers the image format, the job file, hangar upload, and how Hangar pins the image by digest when the booking locks.
A public image on Docker Hub, GitHub Container Registry, NVIDIA NGC, Amazon ECR Public or Quay needs no push and no Docker on your machine. Give the image by digest, and Hangar fetches the image into Sydney (Images from your registry).
Pushing from CI with a request key
A CI job pushes the image that its jobs use. The job uses a request key that has the capability uploads. An owner makes the key once:
$ hangar keys create --name ci --capability jobs --capability uploads --spend-limit 200 --save ci.key
The job sets HANGAR_KEY_ID to the key's id and HANGAR_KEY_FILE to the secret's file, mode 0600. The job then pushes:
$ docker buildx build --platform linux/amd64 --output type=oci,dest=trainer.oci.tar .
$ hangar upload --image ./trainer.oci.tar --name trainer:v1
The key signs every request. The push credential, the records and the image show the key as the pusher, in the pushed_by field of GET /v1/images. Hangar checks the image before the image runs, as Hangar checks every image.
A job of an image that your policy does not list waits for a person's approval, and a key never approves. Hangar refuses a key without uploads with key_capability_missing. Hangar refuses a tenant's key with tenant_mismatch, because the registry belongs to your organisation.