Rails Deployment - "Failed due to unhealthy allocations - no stable job version to auto revert to"

Hello :wave: this morning, I tried deploying my Rails and React (Vite) application here using Fly.io with GitHub Actions, and I encountered this issue -

2023-02-09T16:40:14Z   [info]2023/02/09 16:40:14 listening on [fdaa:1:16ad:a7b:a3:6716:ad44:2]:22 (DNS: [fdaa::3]:53)
Failure #1

--> v0 failed - Failed due to unhealthy allocations - no stable job version to auto revert to and deploying as v1 

--> Troubleshooting guide at https://fly.io/docs/getting-started/troubleshooting/
Error abort

Here’s the log, which has more details - Set Up Fly Deployment · PureChart/purechart-website@b7123e8 · GitHub.

I read in another post using .NET that this may have something to do with the way ports are set, but I’m not sure what I should change and how as I’m relatively new to Rails. Any suggestions? Thank you!

Not a rails person, but did you get a chance to read this guide? Minimal Rails application · Fly Docs It is pretty comprehensive.

A first look of the app’s Dockerfile, CMD /bin/rails console stands out being different to what’s being done in the docs above (CMD /bin/rails server). The second thing I’d look at is fly.toml; in particular, increasing grace_period to 15s or whatever is approp given the app’s start-up time, and increasing timeout to 5s, may be?

Exec fly status --all -a <app-name> to see if it reveals anything useful about the app’s health-check / deployment failure.

@ignoramous Huh, no I didn’t. I just followed the existing Rails application instructions and hoped it would work… I’ll check that out and see what I can dig up. Thank you!

And for those that do know more about Rails, could it be possible that this is happening because I declined to set up Postgres or Redis after running fly launch? I didn’t use either of them explicitly, but maybe Rails requires them to be set up to run? Apologies if it’s a very simple question.

Edit - Did some research and found a way to create a Rails application w/o a database or remove it from an existing application. I’ll try that as well and see what happens.

It could mean that, but in this case it doesn’t. What the error message is trying to say (rather poorly, and we are working to improve it) is that we ran the instructions in the Dockerfile expecting it to start a rails server listening on port 3000 (where 3000 comes from the value of internal_port in fly.toml, but that never happened and we gave up.

Looking at your Dockerfile, it doesn’t attempt to start a rails server at all. Instead it starts a rails console. That’s not going to cut it.

You can generate a new Dockerfile using the following command:

bin/rails generate dockerfile

Let it overwrite your current files - you’ve committed them already to git so you can always recover them later if you need to.

At this point, you should be able to launch your rails application. The build will install the dependencies that vite will use, but at the moment it won’t do anything more. I see that in development you are launching two servers. But what you probably want is a vite build step, as outlined here:

But before I proceed further, I would like to see if you can start your rails server, and hear what you expect to happen when running vite in production.

1 Like

Thank you @rubys, that makes a lot of sense and is most likely my problem. I took a closer look at my Docker file and you’re completely right. I’ll take some time later today to get it working and get back to you.

I did some testing, and the following change to package.json might be all it needs to get vite working as well as rails:

diff --git a/package.json b/package.json
index 713fb99..32462be 100644
--- a/package.json
+++ b/package.json
@@ -4,6 +4,7 @@
     "vite-plugin-ruby": "^3.1.3"
   "scripts": {
+    "build": "vite build --outDir public",
     "dev": "bin/vite dev"
   "dependencies": {

1 Like

@rubys Thanks! I tried using bin/rails generate dockerfile but it seems like the file it generated isn’t working. When I try building the image or running the action on GitHub, I get an error about python-is-python3 not being found -

E: Unable to locate package python-is-python3

Here’s my new generated Dockerfile for reference -

# syntax = docker/dockerfile:1

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version and Gemfile
FROM ruby:$RUBY_VERSION-slim as base

LABEL fly_launch_runtime="rails"

# Rails app lives here
WORKDIR /rails

# Set production environment
ENV RAILS_ENV="production" \
    BUNDLE_PATH="vendor/bundle" \

# Update gems and preinstall the desired version of bundler
RUN gem update --system --no-document && \
    gem install -N bundler -v ${BUNDLER_VERSION}

# Throw-away build stage to reduce size of final image
FROM base as build

# Install packages needed to build gems and node modules
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y build-essential curl node-gyp pkg-config python-is-python3 unzip

# Install Node.js
RUN curl -fsSL https://fnm.vercel.app/install | bash && \
    /root/.local/share/fnm/fnm install $NODE_VERSION
ENV PATH=/root/.local/share/fnm/aliases/default/bin/:$PATH

# Install application gems
COPY Gemfile Gemfile.lock ./
RUN bundle _${BUNDLER_VERSION}_ install && \
    bundle exec bootsnap precompile --gemfile

# Install node modules
COPY package.json package-lock.json .
RUN npm install

# Copy application code
COPY . .

# Precompile bootsnap code for faster boot times
RUN bundle exec bootsnap precompile app/ lib/

# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
RUN SECRET_KEY_BASE=DUMMY ./bin/rails assets:precompile

# Final stage for app image
FROM base

# Copy built application from previous stage
COPY --from=build /rails /rails

# Deployment options

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start the server by default, this can be overwritten at runtime
CMD ["./bin/rails", "server"]

You can also see the workflow run (which failed for the same reason). I don’t think I changed anything here after it was generated. However, I did add the build script you mentioned! Any thoughts?

Congratulations, you found a bug! Thanks!

I’ve pushed out a fix. Update dockerfile-rails to version 1.0.13 (bundle update should do the trick), and rerun bin/rails generate dockerfile.

I’ve found some additions that vite adds to .gitingore that should also be made to .dockerignore. I’ll be adding those changes and anything else it takes to get you up and running to future versions of dockerfile-rails.

Thank you for taking the time to help me @rubys! I still had some issues (something about Nokogiri not working because GLIBC_2.29 couldn’t be found) so I decided to create a brand new Rails project using the latest stable version of Ruby and Rails. Deploys perfectly now (at least from my computer, I’ll need to test the GitHub action now but I feel like it should work with no problems).

I still need to install Vite again and see if it works but I think I can take care of that on my own because it’s more of a containerization problem than a Fly problem - I won’t bother you with it anymore. Thanks again!

Good call on upgrading Ruby and Rails.

It’s not a bother! Take a look at the dockerfile-rails project: GitHub - rubys/dockerfile-rails: Provide Rails generators to produce Dockerfiles and related files. ; my goal is to get people with Rails applications up and running.

What this means is that I want to be able to provide full support for vite/rails applications. And if you compare the results of a minimal rails application (without vite) and a rails application with vite, you will see that there are significant differences needed in the Dockerfile:

My latest commit even makes the change to package.json for vite:

I’d appreciate it if you kept me informed as you make progress so that I can make better Dockerfiles for future vite/rails developers.

Will do :saluting_face: I hope this generator becomes official eventually as it would be super helpful, similar to the way Vapor automatically generates a Dockerfile when you initialize new projects.