# Machines OpenAPI spec omissions

**URL:** <https://community.fly.io/t/machines-openapi-spec-omissions/27255>\
**Category:** General\
**Tags:** wishlist, docs, machines, certificates\
**Created:** [February 28, 2026, 5:54pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255 "2026-02-28T17:54:05Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![dangra](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/dangra/32/4413_2.png) [@dangra](https://community.fly.io/u/dangra)\
**Post date:** [September 22, 2026, 11:08pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/22 "2026-09-22T23:08:30Z")

</div>

@praneetloke the changes went live:

1. `current_version` docs updated ([link](https://docs.machines.dev/machines/Machines_update?s-highlight=current_version&path=body%00%23%2Fcomponents%2Fschemas%2FUpdateMachineRequest#request-body.applicationjson.body)).
2. `PATCH` and `PUT` were doing the same operation because of legacy reasons. PUT is deprecated now. [Docs](https://docs.machines.dev/machines/Machines_update_metadata) were also updated to reflect what it does to keys that aren’t mentioned.
3. There is no intention (yet) to convert PUT to “replace all metadata” op

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [September 23, 2026, 2:08pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/23 "2026-09-23T14:08:44Z")

</div>

@dangra @nullhypothesis thank you for making the updates. I’ll review them asap!

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [September 24, 2026, 3:11am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/24 "2026-09-24T03:11:16Z")

</div>

@dangra @nullhypothesis I’ve looked at the changes. Here are my thoughts on the current state of the `Update Machine` endpoint:

1. Rename the `current_version` to `version` in the request body so it lines up with the request body of the `Create Machine` endpoint. One could take the response from the `Create Machine` endpoint, tweak the config and update the machine without having to set a new `current_version` property.

2. As for the second thing…I [previously brought this up](https://community.fly.io/t/machines-openapi-spec-omissions/27255/15) and lilian explained that it is `POST` because the endpoint is _creating_ a new version. I’d argue that the `Update Machine` endpoint acts as a “replace the configuration of the machine with this config if the version matches”. I think a `PUT` would be more appropriate since the user would essentially be replacing the entire configuration with a new one. If not, that’s fine and I can try to work around it. I figured I would give it another shot at proposing the change given other changes.

I would love to know what you think.

---

<div class="post-metadata">

**Author:** ![nullhypothesis](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/nullhypothesis/32/47869_2.png) [@nullhypothesis](https://community.fly.io/u/nullhypothesis)\
**Post date:** [September 25, 2026, 2:32am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/25 "2026-09-25T02:32:43Z")

</div>

I’d rather not rename attributes or change methods; not because I find your suggestions unreasonable (they’re actually good!) but because every change must be backwards compatible, which means that we’d have to deprecate the old stuff, introduce new stuff, and make sure that nothing breaks. It’s a bit of a hassle and I’d prefer to avoid it as much as possible, even if it means foregoing opportunities to make the API more consistent.

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [September 25, 2026, 8:43pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/26 "2026-09-25T20:43:32Z")

</div>

> It’s a bit of a hassle and I’d prefer to avoid it as much as possible, even if it means foregoing opportunities to make the API more consistent.

Fair enough. I had a feeling that was going to be the case. I’ve been there. I’ll work around those points I brought up about the Update Machine endpoint.

By the way, what is the purpose of the `Remove certificate` [endpoint](https://docs.machines.dev/tls-certificates/App_Certificates_delete)? I see that both Acme and custom certificates have a corresponding `Remove Acme` and `Remove custom` endpoint.

---

<div class="post-metadata">

**Author:** ![lillian](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/lillian/32/49616_2.png) [@lillian](https://community.fly.io/u/lillian)\
**Post date:** [September 25, 2026, 9:23pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/27 "2026-09-25T21:23:04Z")

</div>

> [@praneetloke](#):
>
> By the way, what is the purpose of the `Remove certificate` [endpoint](https://docs.machines.dev/tls-certificates/App_Certificates_delete)?

that’s for deleting all certificates on the app, whether ACME or custom. (both can be on the app at the same time)

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [September 26, 2026, 12:12am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/28 "2026-09-26T00:12:10Z")

</div>

Ah, got it. Thank you, @lillian!

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [September 26, 2026, 6:02pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/29 "2026-09-26T18:02:48Z")

</div>

I’ve made the repo public now that I have gotten a successful generation of Pulumi SDKs from the OpenAPI spec. I will test the SDK with my Fly account and once I confirm things to be working well, I’ll publish the SDKs to the respective registries.

> **[GitHub - cloudy-sky-software/pulumi-fly-machines: A Pulumi provider based on fly.io's Machines REST...](https://github.com/cloudy-sky-software/pulumi-fly-machines/)**
>
> A Pulumi provider based on fly.io's Machines REST API.

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 3, 2026, 4:24am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/30 "2026-10-03T04:24:49Z")

</div>

I have been testing the Pulumi provider. It mostly works. The following are a few of the observations I made.

### Network Policies

[Network policies API](https://docs.fly.io/machines/guides-examples/network-policies#api-summary) is listed in the docs here but it’s missing in the spec. I don’t see any other way to manage them.

Moreover, `POST /v1/apps/<app_name>/network_policies` is used for both create _and_ update. It would be great if there was a separate endpoint for updating a policy similar to the [DELETE endpoint](https://docs.fly.io/machines/guides-examples/network-policies#delete-a-policy): `DELETE /v1/apps/<app_name>/network_policies/<policy_id>`.

There is also no endpoint to fetch a single network policy by its id.

### Storage Objects

I am curious if there is any plan to add APIs to manage the following resources:

- [Fly.io](http://Fly.io) Storage (Tigris) Buckets to the Machines API?
- Fly Kubernetes Service

I realize it’s _Machines_ API, so maybe a separate “platform” API group?

### Rate Limits

The rate limit is easily triggered by the metadata endpoints. Trying to mutate (add/update/delete) multiple metadata keys for a machine will result in 429s. I can work around this by slowing-down the metadata requests for a machine but I wanted to mention it in case there is any room for easing the limits for certain endpoints. The alternate, of course, is that a user manages metadata as part of the machine config rather than using the dedicated `/metadata/{key}` endpoint. I am going to do more testing and part of it is to port something off Render.

---

<div class="post-metadata">

**Author:** ![lillian](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/lillian/32/49616_2.png) [@lillian](https://community.fly.io/u/lillian)\
**Post date:** [October 3, 2026, 5:16am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/31 "2026-10-03T05:16:31Z")

</div>

> [@praneetloke](#):
>
> - [Fly.io](http://Fly.io) Storage (Tigris) Buckets

tigris is a separate company and product; you can use their own APIs to manage storage buckets, the flyctl integration is mostly just a convenience.

> [@praneetloke](#):
>
> - Fly Kubernetes Service

this is deprecated and should no longer be used.

for metadata, raising the limits is probably not workable as each update is expensive on our end, maybe you can use the [bulk update endpoint](https://docs.fly.io/api/machines/machines/update-metadata-setremove-multiple-keys) instead?

I’m not personally familiar with network policies.

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 4, 2026, 3:56am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/32 "2026-10-04T03:56:34Z")

</div>

> the flyctl integration is mostly just a convenience.

Ah, that’s good to know. I wasn’t sure if there was a special thing with fly’s control plane.

> Fly Kubernetes Service
> 
> > this is deprecated and should no longer be used.

Got it! That’s simple enough 🙂

> for metadata, raising the limits is probably not workable as each update is expensive on our end, maybe you can use the [bulk update endpoint](https://docs.fly.io/api/machines/machines/update-metadata-setremove-multiple-keys) instead?

Hmm yeah I seem to have forgotten about this endpoint altogether. Thank you for pointing this out to me. I’ll think of a strategy to use this.

> I’m not personally familiar with network policies.

Do you know anyone who might be able to look into it?

Thank you as always!

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 13, 2026, 1:00am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/33 "2026-10-13T01:00:13Z")

</div>

I have established a release pipeline to publish the respective SDKs for the Pulumi provider to `npm`, `pypi` and `NuGet`. I’ve spent the last few days diving into the platform as a whole. The [basic example](https://github.com/cloudy-sky-software/pulumi-fly-machines/blob/main/examples/simple/index.ts) in the repo works if you want to give it a try as well.

Here are my notes about the API from trying to use the Pulumi provider and the Fly platform in general.

### Machine config

1. There are some parameters in the machine config that have no description. Morever, the relationship between `processes` and multi-containers (`containers` property) is quite confusing to me. Also it looks like multi-containers is only available to certain organizations, so I assume it’s a preview feature?
2. What is the [`statics`](https://docs.fly.io/api/machines/machines/create-machine#body-config-statics) property for? I mean, I am guessing it’s for serving static files but a description would be great. Specifically, I am not sure if this would automatically provision a Tigris storage bucket?

### Deleting a machine

1. I cannot delete a machine if it’s running unless I use the `force` query param or wait for it to transition to the stopped state automatically if `autostop` is enabled. I get a 412 Precondition Failed status code if I try to delete a running machine without the `force` query param. The behavior isn’t a problem but rather there is no mention of this requirement in any of the docs. It would be great if this is documented in the API specs or the core platform docs for Machines.

2. The response body contains a single boolean property called `ok` but the API spec says that the response body is supposed to be empty. The [platform docs](https://docs.fly.io/machines/api/machines-resource#delete-a-machine-permanently) shows what I am seeing. The mismatch in the response body isn’t a problem but I wanted to point out that one of them is incorrect. Either, it’s supposed to return a 204 NoContent without any response body as `DELETE` endpoints typically do, or, the API spec should be updated to match the correct response as shown in the platform docs.

On a somewhat related note, I was looking into volumes and was curious about SQLite replication with LiteFS, which led me to read about `fly consul attach/detach`. `fly consul ...` is another example of an important action that is core to the platform. While this is technically “out-of-scope” for the Machines API, I would **love** it if a dedicated REST API existed for these sorts of things.

There is also the issue with [Network Policies API](https://docs.fly.io/machines/guides-examples/network-policies#restricting-egress-traffic-to-http-https) I brought up [previously](https://community.fly.io/t/machines-openapi-spec-omissions/27255/30#p-106197-network-policies-1). I do think it’s important to include this in the Machines API spec as it deals with restricting network egress.

As always, thank you for your time!

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 15, 2026, 3:33am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/34 "2026-10-15T03:33:36Z")

</div>

I have hit a strange problem with app secrets.

The [endpoint](https://docs.fly.io/api/machines/secrets/create-or-update-secret) to create/update an app secret only [stages](https://docs.fly.io/apps/secrets#set-secrets) (as if `--stage` was passed) the secret waiting for the user to click Deploy Secrets which will cause a new machine to be created with the new secrets and the old one to be torn-down. This seems somewhat convenient if I was using `flyctl` to do everything. But it doesn’t make sense to do this the API.

The strange thing is, according to the docs, staged secrets would be deployed automatically the next time a machine is updated but that didn’t happen for me. I replaced the machine with a different image and yet the status of secrets in the app are showing as staged.

> the staged secret will be available only on Machines that are started or updated after the `fly secrets set` command was run.

And there’s another issue. Machines with volumes. Deploying secrets requires a new machine and if the existing machine has a volume attached to it, the deployment will refuse to proceed since it won’t automatically detach the volume. It would be nice if this was handled automatically by the control plane, i.e. suspend the current machine, detach volume, create a new machine, attach volume, delete old machine…sort of a rolling update. I understand this amounts to downtime if the user only has one machine running their app but I think that should be acceptable.

---

<div class="post-metadata">

**Author:** ![mayailurus](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/mayailurus/32/17593_2.png) [@mayailurus](https://community.fly.io/u/mayailurus)\
**Post date:** [October 15, 2026, 5:58am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/35 "2026-10-15T05:58:57Z")

</div>

> [@praneetloke](#):
>
> Also it looks like multi-containers is only available to certain organizations, so I assume it’s a preview feature?

It did start out that way, but it was opened up to everyone in [April 2025](https://community.fly.io/t/using-containers-with-flyctl/24729) (or earlier).

(There are still some rough edges in the multi-container Machines overall, though.)

> [@praneetloke](#):
>
> The strange thing is, according to the docs, staged secrets would be deployed automatically the next time a machine is updated but that didn’t happen for me. I replaced the machine with a different image and yet the status of secrets in the app are showing as staged.

Hm… I do see the new secret right after updating the Machine, actually, without any intervening steps via `flyctl` or in the dashboard…

```plaintext
$ curl <token-etc> "https://$API/v1/apps/uc15po/secrets/tuna" \
   --data '{"value": "FISH"}'
{"name":"tuna","value":"FISH","digest":"6f0bc02042fd2646",
 "version":123798940,"Version":123798940}
$ cat config-neo.json
{
  "config": {
    "image": "debian:trixie",
    "init": {
      "cmd": ["sleep", "inf"]
    },
    "min_secrets_version": 123798940
  }
}
$ curl <token-etc> "https://$API/v1/apps/uc15po/machines/<machine-id>" \
   --data @config-neo.json
$ fly ssh console
# printenv tuna
FISH

```

(Here `min_secrets_version` [matches](https://community.fly.io/t/flyctl-update-for-managing-secrets/25878) the value returned by the first `POST`, and the rest of `config-neo.json` is the same as when that Machine was originally created.)

How were you determining the status of the secrets? (Some methods of doing so may only be reliable for Machines managed by `fly deploy`, etc.)

---

<div class="post-metadata">

**Author:** ![lillian](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/lillian/32/49616_2.png) [@lillian](https://community.fly.io/u/lillian)\
**Post date:** [October 15, 2026, 7:47am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/36 "2026-10-15T07:47:12Z")

</div>

the idea behind Machines is to [not have a hosted control plane](https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator/). after you create a Fly Machine, you are talking directly to the physical server running that Machine; the “control plane” is really only a proxy that handles auth and forwards requests to the correct server.

in time we realised this is not what everyone wants; the dashboard now has a “deploy secrets” button that… spawns an ephemeral Fly Machine with flyctl and runs `fly secrets deploy`, lol.

it is odd that you are not seeing secrets be updated in your Machine after a machine update. can you ssh in and check the secret value? the display has historically been wrong sometimes. there definitely shouldn’t be a need to create an entirely new machine to update the secrets.

if you’re actually seeing secrets not being updated after a machine update while using `min_secrets_version`, please provide an example machine id so we can take a look.

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 15, 2026, 5:13pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/37 "2026-10-15T17:13:11Z")

</div>

@mayailurus @lillian setting the `min_secrets_version` on the machine was the key. I was missing that critical piece of information. Neither the Create/Update Machine endpoints have a description for `min_secrets_version` nor the [Create/Update App Secret](https://docs.fly.io/api/machines/secrets/create-or-update-secret) mentions this.

> in time we realised this is not what everyone wants; the dashboard now has a “deploy secrets” button that… spawns an ephemeral Fly Machine with flyctl and runs `fly secrets deploy`, lol.

Ah I see. That’s what I was seeing and it would fail for the machine in question because I have a volume attached to it.

> it is odd that you are not seeing secrets be updated in your Machine after a machine update. can you ssh in and check the secret value? the display has historically been wrong sometimes. there definitely shouldn’t be a need to create an entirely new machine to update the secrets.

Indeed. I think the dashboard is incorrect. Even after I set the `min_secrets_version`, the dashboard is still showing the app secrets as just staged, requiring a deployment with `fly secrets deploy`. But I can confirm that the container running in the machine does in fact have the secrets.

There is another thing I noticed with the dashboard. Despite pushing an image to `registry.fly.io/<app-name>` I don’t see it in the dashboard under `Apps > {my-app} > Registry`. The page is blank even though the machine is in fact running an image from the registry, which I know was pushed successfully.

By the way, I am using private networking to connect one App (exposed to the internet) to a private app (bound to `fly-local-6pn` as per the docs). The healthchecks for the publicly exposed app works fine. However, I can’t seem to get the healthchecks for the private app working no matter what I do. I tried the following things to no avail:

- top-level `checks` property
- the `config.containers[*].healthchecks` property with `http`, as well as an `exec.command` by using the `FLY_PRIVATE_IP` as well as the `fly-local-6pn` host explicitly.

I just can’t seem to get healthchecks for a private machine to work. I think I am missing some piece of information.

> the idea behind Machines is to [not have a hosted control plane](https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator/). after you create a Fly Machine, you are talking directly to the physical server running that Machine; the “control plane” is really only a proxy that handles auth and forwards requests to the correct server.

Got it. How does a machine handle scaling when a persistent volume is attached to it? Or does it not do that? I couldn’t find information about that in the docs that I read about [scaling machines](https://docs.fly.io/machines/overview#scaling-machines).

---

<div class="post-metadata">

**Author:** ![lillian](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/lillian/32/49616_2.png) [@lillian](https://community.fly.io/u/lillian)\
**Post date:** [October 15, 2026, 5:33pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/38 "2026-10-15T17:33:33Z")

</div>

I don’t know very much about the dashboard but I’ll poke the right folks.

healthchecks aren’t supported over 6pn, only on proxy services (using [flycast](https://docs.fly.io/blueprints/private-applications-flycast#run-private-apps-with-flycast) instead of a public ip if you want a private app).

> [@praneetloke](#):
>
> How does a machine handle scaling when a persistent volume is attached to it?

it does not. you need to create a new volume and attach it to a new machine. there is some info about that in this docs page: [Fly Volumes overview - Fly.io](https://docs.fly.io/volumes/overview)

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 15, 2026, 6:39pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/39 "2026-10-15T18:39:10Z")

</div>

> [@lillian](#):
>
> I don’t know very much about the dashboard but I’ll poke the right folks.

Great! Thank you.

> [@lillian](#):
>
> healthchecks aren’t supported over 6pn, only on proxy services (using [flycast](https://docs.fly.io/blueprints/private-applications-flycast#run-private-apps-with-flycast) instead of a public ip if you want a private app).

> [@lillian](#):
>
> it does not. you need to create a new volume and attach it to a new machine. there is some info about that in this docs page: [Fly Volumes overview - Fly.io](https://docs.fly.io/volumes/overview)

Ah gotcha. That’s what I suspected on both of those things based on what I was seeing. Thank you for confirming. It makes sense given that these are actual VMs and not containers, even though I am providing “container images” to run on these machines. So they are akin to an AWS EC2 instance with an EBS volume attached, correct? Except, these are fast, lightweight Firecracker VMs.

---

<div class="post-metadata">

**Author:** ![mayailurus](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/mayailurus/32/17593_2.png) [@mayailurus](https://community.fly.io/u/mayailurus)\
**Post date:** [October 18, 2026, 5:06pm UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/40 "2026-10-18T17:06:43Z")

</div>

> [@praneetloke](#):
>
> Despite pushing an image to `registry.fly.io/<app-name>` I don’t see it in the dashboard under `Apps > {my-app} > Registry`. The page is blank even though the machine is in fact running an image from the registry, which I know was pushed successfully.

These two older forum threads might be useful in the meantime…

[https://community.fly.io/t/cant-see-images-in-my-registry/25436/2](https://community.fly.io/t/cant-see-images-in-my-registry/25436/2)

[https://community.fly.io/t/should-every-app-have-entries-in-the-registry/26237](https://community.fly.io/t/should-every-app-have-entries-in-the-registry/26237)

My overall impression is that the dashboard is designed primarily for those who are using `fly deploy`; personally, I don’t mix it with Machines API operations, except for really basic things like start and stop of individual Machines. (Those are just mapped to direct calls to the Machines API, I’m pretty sure, without any extra metadata needing to be juggled.)

(It’ll be interesting to hear where the official dividing line is, though…)

---

<div class="post-metadata">

**Author:** ![praneetloke](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/praneetloke/32/14758_2.png) [@praneetloke](https://community.fly.io/u/praneetloke)\
**Post date:** [October 19, 2026, 1:30am UTC](https://community.fly.io/t/machines-openapi-spec-omissions/27255/41 "2026-10-19T01:30:43Z")

</div>

Thank you for sharing those links!

> [@mayailurus](#):
>
> These two older forum threads might be useful in the meantime…
> 
> [Can't see images in my registry - #2 by roadmr](https://community.fly.io/t/cant-see-images-in-my-registry/25436/2)
> 
> [Should every App have entries in the Registry?](https://community.fly.io/t/should-every-app-have-entries-in-the-registry/26237)

This matches with what I am seeing as well.

> [@mayailurus](#):
>
> My overall impression is that the dashboard is designed primarily for those who are using `fly deploy`; personally, I don’t mix it with Machines API operations, except for really basic things like start and stop of individual Machines. (Those are just mapped to direct calls to the Machines API, I’m pretty sure, without any extra metadata needing to be juggled.)
> 
> (It’ll be interesting to hear where the official dividing line is, though…)

Ah, gotcha.

[Previous page](https://community.fly.io/t/machines-openapi-spec-omissions/27255.md?page=1)

[Next page](https://community.fly.io/t/machines-openapi-spec-omissions/27255.md?page=3)