Not that I’m aware of. I upgraded my app to Rails 8 without issue. I’m using import map and sqlite3, you are using jsbundler and postgres; but neither of those should be an issue?
Have you seen those VIPS errors before with ActiveStorage? I’m just using Amazon S3 and I did on Rails 7.
Any hunches which files I should check for the site taking so long to load after the upgrade?
Here’s my production.rb
require "active_support/core_ext/integer/time"
Rails.application.configure do
# Settings specified here will take precedence over those in config/application.rb.
config.cache_classes = true
config.eager_load = true
config.action_controller.perform_caching = true
# Needed to get the 404 page to work
config.consider_all_requests_local = false
config.action_dispatch.show_exceptions = true
config.exceptions_app = self.routes
config.public_file_server.enabled = ENV.fetch("RAILS_SERVE_STATIC_FILES") { true }
config.assets.css_compressor = :sass
# Do not fallback to assets pipeline if a precompiled asset is missed.
config.assets.compile = true
config.assets.debug = true
config.active_storage.service = :amazon
config.active_storage.variant_processor
config.active_storage.logger = Rails.logger
config.log_level = :info
config.log_tags = [ :request_id ]
config.action_mailer.perform_caching = false
config.action_mailer.default_url_options = { :host => 'wherecanwedance.com' }
config.action_mailer.perform_deliveries = true
config.action_mailer.delivery_method = :postmark
config.action_mailer.postmark_settings = {
api_token: Rails.application.credentials.dig(:postmark, :api_token)
}
# POSTMARK
config.action_mailer.smtp_settings = {
address: 'smtp.postmarkapp.com',
port: 587,
user_name: Rails.application.credentials.dig(:postmark, :api_token),
password: Rails.application.credentials.dig(:postmark, :api_token),
authentication: :plain,
}
# Ignore bad email addresses and do not raise email delivery errors.
# Set this to true and configure the email server for immediate delivery to raise delivery errors.
config.action_mailer.raise_delivery_errors = true
# Enable locale fallbacks for I18n (makes lookups for any locale fall back to
# the I18n.default_locale when a translation cannot be found).
config.i18n.fallbacks = true
# Don't log any deprecations.
config.active_support.report_deprecations = true
config.action_view.preload_links_header = false
# Use default logging formatter so that PID and timestamp are not suppressed.
config.log_formatter = ::Logger::Formatter.new
# Use a different logger for distributed setups.
# require "syslog/logger"
# config.logger = ActiveSupport::TaggedLogging.new(Syslog::Logger.new "app-name")
if ENV["RAILS_LOG_TO_STDOUT"].present?
logger = ActiveSupport::Logger.new(STDOUT)
logger.formatter = config.log_formatter
config.logger = ActiveSupport::TaggedLogging.new(logger)
end
# Do not dump schema after migrations.
config.active_record.dump_schema_after_migration = false
end
Unfortunately, no hunches here. My upgrade went smoothly, and I’ve not heard of others experiencing slowdowns, so the only help I can provide here is to help you rule out a number of potential causes.
This will produce a Rails 8 style Dockerfile customized for your application. You will get options to see the diffs and accept or reject the changes.
You don’t need a new machine. If you are using git, commit all your files, run the command mentioned above, and then fly deploy. If that works, commit the updated files, if not, run git checkout . and rerun fly deploy.
Not directly related to Rails 8, but is your application configured to auto stop (that’s typically the default)? Check your fly.toml. If you are using fly postgres, you may need to do that for your database too: Scale to zero for Postgres Development projects · Fly Docs
