Should every App have entries in the Registry?

[halfer]

I have three apps, sequoia-proto, sequoia-distributor, and sequoia-browser-test. The first two have images in their registries, but the third does not. I know there’s at least two in there, tagged small and large, because I’m pulling them in a CI pipeline for automated tests.

Would someone with backend access see why this is? This app is stopped by design, as it is only started up for temporary processing, but I can’t see why that would affect the registry.

Update

I notice also that flyctl releases -a sequoia-browser-test --image is empty, which I find confusing. I assume that I must have used flyctl deploy in the past, as I’ve only just started building locally and pushing to the Fly registry for this app.

[mayailurus]

Hi… This is weird but normal. Unfortunately, the dashboard only displays a subset of images (notwithstanding the Registry name for that panel—which strongly suggests otherwise):

@roadmr

Did you by any chance build these images locally and pushed them directly to the Fly registry?

Images uploaded this way can be used to deploy (referred to by tag, for example) but they won’t show in registry or releases unless they were built as part of a fly deploy run; this is because only a fly deploy-generated image is tracked in the database that powers registry and releases.

In the past, I’ve been able to enumerate the real, full set with lower-level utilities like skopeo list-tags, and presumably this would also work with the corresponding command in the Docker CLI.

(These talk to registry.fly.io itself, as opposed to the separate database that @roadmr mentioned.)

Hope this helps a little!

[halfer]

Super, that helps; thanks.

I’ve tried flyctl auth docker, and this does write to ~/.docker/config.json. This works for things like docker push and docker pull, but I don’t think that Docker has a remote list feature built into its command-set. I tried this (with the auth token snaffled from the config file):

curl -H "Authorization: Bearer xxx" https://registry.fly.io/v2/sequoia-browser-test/tags/list

And I receive:

{"errors":[{"code":"UNAUTHORIZED", "message":"not allowed"}]}

Maybe this is the value of utilities like Skopeo; I wonder if it can use Docker auth, rather than requiring its own? Some sources of help indicate that auth is a multi-step process, but I am rather hoping that a freshly-generated token from flyctl means there is only one step pending, which is just the Docker operation I want.

[mayailurus]

I just used the output of fly tokens create deploy --expiry 2h. The Bearer style is inherently the older, pre-Macaroons one, if I understand correctly, and that may no longer be honored these days, …

$ skopeo list-tags --creds "x:$MACAROON" 'docker://registry.fly.io/app-name'

The $MACAROON includes the FlyV1 prefix, and x is just a username placeholder (which I think the remote system is mostly ignoring).

Maybe try Authorization: FlyV1 ... in your curl attempt? I seem to recall that working in other, closely related contexts…

[halfer]

Ah, I don’t think I need to list tags after all. Here is my thought process.

App sequoia-distributor starts up instances of sequoia-browser-test, currently just on the latest tag. Increasingly I am finding this unsustainable because of incompatibilities between the two services.

I had wondered if a build process in CI would need to list tags in order to obtain a new incrementing release number, but development always starts at my laptop, by definition. So I think, at least for now, I can create my own incrementing scheme for sequoia-browser-test locally, e.g. large-2025-10-19-v1, and then embed that in a committed configuration in sequoia-distributor.

Then, as long as I push the image with that special tag to the Fly registry, it can be pulled by remote CI processes, and can be checked for in a deployment pipeline (i.e. don’t deploy a new sequoia-distributor if dependent images are not available).

It doesn’t feel completely clean to rely on a local build, and to not have a clean remote build mirroring it. Maybe Git tags should be used instead; I will ponder.

[halfer]

Thanks for the notes on Skopeo; I tried a couple of times to build it, in the last hour, and several times it failed, either because my Linux is too old, or I don’t have Go installed, or whatever other thing. The several reports in the GitHub issues page have been summarily closed, so I wonder if getting this working would turn into a non-trivial side-quest

[halfer]

@mayailurus

fly tokens create deploy --expiry 2h

Ah, perfect; that worked with Docker! Thank you. The token from that slotted straight into curl -H "Authorization: xxx" https://registry.fly.io/v2/sequoia-browser-test/tags/list and a JSON list of tags is output. Yes, the FlyV1 prefix seems to be needed.

Interestingly, most of the tags are labelled as deployment-*, which makes me wonder what exactly a deployment is, if these are not shown in the registry.

[mayailurus]

@halfer

Thanks for the notes on Skopeo […]

Yeah, it’s pretty nice in that it doesn’t require an almighty superuser daemon, or anything like that. Very lightweight.

I’d suggest trying it out in a Debian Bookworm image in a temporary Fly.io Machine (apt-get update && apt-get install --no-install-recommends skopeo man-db).

You can give it just a token for that one app—and not the entire keys to the kingdom…

[halfer]

Oh, I am a daftie; it’s in my local Mint distro already:

apt-cache search skopeo
skopeo - Tooling to work with remote images registries

Not sure why I didn’t check that! Nevermind; since I can do it in Docker, an extra tool is unnecessary.