I’ve been trying to deploy for the past 30 min and it always hang during this stage. I have waited for over 700 seconds in one of the attempts so I think there’s definitely an issue.
Is there a way for me to switch the assigned remote builder to see if that fixes the issue?
Hi, build finally finished in 4136.0s. Before this incident it used to be consistently less than 2 min if I remember correctly tho.
I’m going to try a few more times throughout the day.
for your reference, here is my dockerfile
# syntax = docker/dockerfile:1
# Adjust NODE_VERSION as desired
ARG NODE_VERSION=20.6.1
FROM node:${NODE_VERSION}-slim as base
LABEL fly_launch_runtime="Remix"
# Remix app lives here
WORKDIR /app
# Set production environment
ENV NODE_ENV="production"
# Throw-away build stage to reduce size of final image
FROM base as build
# Install packages needed to build node modules
RUN apt-get update -qq && \
apt-get install -y build-essential pkg-config python-is-python3
# Install node modules
COPY --link package-lock.json package.json ./
RUN npm ci --include=dev
# Copy application code
COPY --link . .
# Build application
RUN npm run build
# Remove development dependencies
RUN npm prune --omit=dev
# Final stage for app image
FROM base
# Copy built application
COPY --from=build /app /app
# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD [ "npm", "run", "start" ]
Check your .dockerignore file. If it is missing, or doesn’t include node-modules, you will be uploading a large number of files. Here’s an example you can use as a starting point:
This is not normal, nor what I or others are seeing. My current theory remains that you have some file or set of files that are large that you are uploading. One way to test this is to create a file by the name of Dockerfile.test, with the following contents:
FROM ubuntu
WORKDIR /app
COPY . .
Then run the following command:
fly console --dockerfile Dockerfile.test -C bash
If my theory is correct, that will take a while. Once you get a command prompt from the ephemeral machine that this creates, you can find where the problem is with the following command:
It was the unused images that were getting pushed to the remote builder.
Of course, since fly.io uses a remote builder, it should grab everything from my project, as it doesn’t have any context of which assets would eventually get imported by my code.
I’m not entirely sure if this was the sole issue when this happened, since it only cut down the total size by <30% (<300mb). I guess this process doesn’t scale linearly with the total size?
But I do not have issues with the remote builder anymore.