☒ Thanks for the catch. I've updated the show notes to reflect this.

 ☒ you might be able to check if the string contains a UUID and escape the generate_slug method.

 ☒ That is a pretty annoying error. You can enable Swap memory on the VM which will prevent things from crashing. This will create a 4GB Swapfile and enable it. 

# .ebextensions/swap.config
commands:
  000_swap:
    ignoreErrors: true
    test: test ! -f /swapfile
    command: dd if=/dev/zero of=/swapfile bs=1M count=4096 && mkswap /swapfile && swapon /swapfile

Side note: People say that enabling Swap in production is horrible and bad practices. My take is that it's bad practice to have your app "randomly" crash and take down the site. Have proper monitoring in place for when you're approaching OOM and hitting swap and address the issues, but don't let the server crash.

 ☒ Do you have any kind of configurations for web_console? You may want to wrap those in a conditional block

unless Rails.env.production?

On one of your screenshots, it looks like it's getting referenced somewhere, but when beanstalk does the deployments, it's excluding the development and test gems. 

It also looks like at one point the bundler gem isn't installed when it's trying to do something. In the same place where you created the swap, also add a line for bundler.

commands:
  000_swap:
    ignoreErrors: true
    test: test ! -f /swapfile
    command: dd if=/dev/zero of=/swapfile bs=1M count=4096 && mkswap /swapfile && swapon /swapfile
  000_bundler:
    ignoreErrors: true
    command: gem install bundler -v 2.2.16

 ☒ I haven't tried deploying separate EC2 instances in the same environment but running different commands (rails app and then another set of instances running sidekiq). My thought is that this would go against their best practices as it could eventually lead to some issues with the load balancer. The health checks that occur will test to see if a EC2 instance is healthy or not and this could end up causing your background workers to die often.

You're probably best off creating a separate worker environment but use the same database. In these cases where you have two different environments for the same application, I would create the database separately from Beanstalk and make the appropriate routings.

For deploying to these two different environments, I would create a bin/deploy function. That way, you have one command that will deploy to both environments.

For connecting to a RDS database outside of the beanstalk network
https://www.driftingruby.com/episodes/aws-security-groups-and-deploying-rails-6-to-beanstalk

For creating bin functions
https://www.driftingruby.com/episodes/bin-functions