Additionally, we can move the coder build to Dockerfile and build with dpot.dev 16 core 32 GB builder.

I think we should leave it how it is. We want to ship the same binary everywhere, so it'd be weird to rebuild it in the Docker image compared to the one we ship as a raw binary on github releases.

@deansheather, which one do you prefer? #11544 or this one?

@matifali The other one, you shouldn't need depot to build these. We only use depot to build the "base" image, which is built on every release and on a weekly basis and pushed to the base repo. The reason we need depot to build that is because it has RUN statements which cannot be cross-built from amd64. The non-base Dockerfile doesn't contain RUN statements and just has COPY and other statements that can be cross-built. So you should just do that.

@deansheather I understand, but our current approach requires pushing individual arch images to the registry and then pulling those back, creating a manifest, and pushing the manifest. Depot allows removing all that and makes it super easy to push multi-arch images.

After discussing with @deansheather, I am closing in favor of #11544. We do not benefit from the depot.dev as our multi-arch Dockerfile does not have any RUN commands.