Machine images

Objective

Read this page to pick an image and to find its login user. Using the wrong user produces a permission-denied that looks exactly like a broken key, and costs an hour.

official vendor cloud image, downloaded from the vendor’s own URL and imported into the image service. We build none of them, and we modify none of them.

The shelf

Name	Login user	Minimum root disk	Format
`debian-12`	`debian`	4 GiB	qcow2
`debian-13`	`debian`	4 GiB	qcow2
`ubuntu-22.04`	`ubuntu`	8 GiB	qcow2
`ubuntu-24.04`	`ubuntu`	8 GiB	qcow2
`rocky-9`	`rocky`	10 GiB	qcow2
`alma-9`	`almalinux`	10 GiB	qcow2
`fedora-42`	`fedora`	10 GiB	qcow2
`opensuse-leap-15.6`	`opensuse`	10 GiB	qcow2
`arch`	`arch`	10 GiB	qcow2
`talos-v1.13.9`	— none, Talos has no SSH	10 GiB	raw (xz)

Every instance type’s root disk is at least 20 GiB (Instance types), so the minimum root disk column never blocks a launch. It matters if you shrink a root disk through a block device mapping.

There is no Windows image, and no licence to sell one.

The login user is not `root`

Cloud images disable password login and root SSH, and create one unprivileged user with your key in ~/.ssh/authorized_keys and passwordless sudo. Which user that is, is set by the distribution — not by us.

ssh debian@<public ip>       # not root@, not ubuntu@

DescribeImages states the login user in the image description for exactly this reason.

Talos

talos-v1.13.9 is Talos Linux, and it is not like the others:

No SSH, no shell, no login user. It is an API-driven Kubernetes OS; you talk to it with talosctl.
Shipped as a raw image, xz-compressed, from the Talos image factory.
The schematic id in its URL names its extensions: this build carries the Tailscale extension, which is why it is the build on the shelf.
It expects machine configuration through the cloud-init user-data channel, the same channel RunInstances --user-data writes.

Pick it when you are running Kubernetes and you want the node OS to be immutable. Pick Debian when you want a machine you can SSH into.

Names roll

An image name points at the newest build we have imported. Re-running the importer moves the name to the newer upstream build and the ami- id changes.

If you	Then
Write `ubuntu-24.04` in Terraform via a `data "aws_ami"` lookup	You get whatever we imported most recently, which is usually what you want
Write a literal `ami-…` id	You get that exact build, until it is deregistered
Need immutability across months	Record the image checksum, not the id

This is deliberate: the vendors publish rolling latest URLs (Debian, Ubuntu, Rocky, Alma, openSUSE, Arch all do), and re-running the play is how the offer stays patched. The one exception is Fedora, which publishes no stable latest URL — fedora-42 is pinned and bumped by hand.

[!warning]

Image immutability is an open gap. our internal readiness list gap 7 asks for a recorded fingerprint per image id, or dated ids. Until it is done, an ami- id you stored is not guaranteed to mean the same bytes it meant last month. Pin by checksum if that matters to you.

What is not offered

No public or shared images from other accounts. Every image DescribeImages returns is one we published.
No customer-built images. CreateImage, RegisterImage, CopyImage and DeregisterImage are OPEN (Michael) on the actions page — they are the difference between customers using our images and customers building their own, and that decision has not been taken.
No marketplace, no paid AMIs, no bring-your-own-licence.

Finding one

aws --endpoint-url https://ec2.shelfcs.com --region hel1 \
  ec2 describe-images --filters Name=name,Values=debian-13

data "aws_ami" "debian" {
  most_recent = true
  filter {
    name   = "name"
    values = ["debian-13"]
  }
}

Through the cloud platform directly, the same images are in the image service at https://image.shelfcs.com:

cloud image list

Go further

Image and catalogue actions — DescribeImages itself
Instance types
Key pairs
RunInstances