Failed to start remote builder heartbeat: server returned a non-200 status code: 500

You can build a Dockerfile using a local Docker daemon with fly deploy --local-only:

--local-only Perform builds locally using the local docker daemon. The default is --remote-only.

This option is also mentioned in the Deploy via Dockerfile documentation:

By default, fly deploy builds the image using a remote builder. If you have Docker running locally and want to build locally, then run fly deploy --local-only . Once your container is built, it’s deployed!

1 Like

I confirm that --local-only works, but if you encounter “Error response from daemon: dockerfile parse error line XX: Unknown flag: link”, then you need to enable the BuildKit mode:

DOCKER_BUILDKIT=1 fly deploy --local-only

I hope that the remote build issue will be resolved soon.

1 Like

It works again!

Still same error when trying to deploy to AMS region

I have still a problem to deploy an app…

Platform: machines
✓ Configuration is valid
→ Verified app config
==> Building image
WARN Failed to start remote builder heartbeat: server returned a non-200 status code: 500

Error: failed to fetch an image or build from source: error connecting to docker: server returned a non-200 status code: 500

Experiencing the same as above still. Experienced it 2 weeks ago too alongside the original replies, if that helps

I was finally able to deploy an app this afternoon… but when I tried it now I get the same error again. What is going on?

Still the same error when deploying to CDG

same issue occured today. tho i been redeploying my app for quite few times last 2 days.
and here i see it’s been happening for a while already.

so i followed and destroyed machines . now it’s the same but down…

Having the same issue with a go project

Another datapoint here (can’t use a remote builder, getting the same error as in this thread and in this thread (Unable to deploy due to builder 500 error - #11 by joeynelson), the status page is green, but something is wrong here.

-help
how to destroy the builder machine? so it gets created on deploy again

  1. Run fly apps list, and you should see the remote builder name (it starts with fly-builder-).
  2. Run fly apps destroy <REMOTE_BUILDER_NAME>.
1 Like

thnx. i have destroyed the builder, then new builder was created on deploy. builder status changed from suspended to deployed.
the error on fly deploy has changed from: failed to fetch an image or build from source: error connecting to docker: server returned a non-200 status code: 500
to: failed to fetch an image or build from source: error connecting to docker: failed building options: failed probing “personal”: context deadline exceeded.

what can be done to fix this?

upd: it somehow has gone through. all rocking. everyone happy. thnx

upd2: so it did one deployment created 2 machines for the app, and on second deployment refused to update machines saying : reached maximum number of machines.
so i destroyed one machine (as i did previously to work around that issue)

but :
⠸ Updating …968 [app]

Error: failed to update VM …968: You have reached the maximum number of machines for this app.

hope this helps

1 Like

This worked for me!
after destroying the builder flyctl deploy --remote-only was working again

1 Like

Getting this issue as well and destroying the builder didn’t help.

all works, just retry

Detroyed the apps, but still cannot deploy an app.

Error code:
WARN Failed to start remote builder heartbeat: failed building options: failed probing “personal”: context deadline exceeded.

Error: failed to fetch an image or build from the source: Failed to connect to Docker: failed build options: failed probing “personal”: context deadline exceeded.

apparently time helps with that. i mean it helped in my case, i experienced the same error over and over since i destroyed the builder and then after some time on another try it just did it.
so if there is a key, i’m unaware of it. i wrote to this topic tho, i fave a feeling it’s got some magic power that solves mysteries

Waiting and trying is not an option for me, there must be a solution for me and others who have the same problem.

I chose fly.io because the deploying is very comfortable for me, but if I can not provide a single app here for days, then I have to look for an alternative. Currently it is very frustrating.

1 Like