Moving from Heroku is not going to be a fun task.
I have a handful of projects that I’ve built to play with over my years of development.
Out of all of these projects, I have 1 (yes 1) that I would like to keep going on another provider.
Overview
Migrating a bookmarking app that has a total of 1 User (me) but is used daily to find and categorise articles/links from across the web.
The current setup is based on Jumpstart. It has a Postgres database, Redis instance and 2 dynos running - 1 Rails server, and 1 worker.
It uses Sidekiq to manage the worker jobs and uses Redis to queue them. Redis also handles the ActionCable and Turbo Stream functionality.
Picking a provider
Picking a new service to host. Well…. fly.io seemed like the easiest. I started a new app and deployed it using their documentation within 30mins.
I then attempted to deploy the bookmarking app using the existing codebase.
This was fairly successful but a little tricky to get Redis and Sidekiq working fully.
Using an additional server with a worker would also contribute to usage stats, which was slightly concerning.
Slimming down
How can we make this easier?
I didn’t spend too much time looking for replacements however, the Good Job gem popped up and appeared to be a great replacement for Sidekiq.
Good Job allows your application to use a Postgres database to process jobs. 🎉
A quick dive into the ActionCable docs, explains that you can use Postgres as an adapter rather than Redis. This is not recommended for high workloads, but we have 1 User and that’s me 🥳.
The PR for switching the job handler to Good Job and the ActionCable adapter to use Postgres was very painless.
We still require the worker server due to Good Jobs default configuration.
The Good Job documentation shows that you can run the jobs in the Rails server (:async
) rather than a worker (:external
) server, however, this is not recommended for high workloads - we have 1 User and that’s me 🥳.
With the configuration for Good Job and ActionCable updated we can now remove the need for the worker server.
What’s left
We now have a single Rails server and a Postgres database.
Jobs are added to Postgres and processed by the Rails server.
ActionCable and Turbo Stream also get sent through Postgres.
Problems
Running out of memory
On the cheapest compute offering from fly.io, there is 256Mb or RAM.
My bookmarker app and another app both seem to level out at 300Mb of RAM which causes them to crash occasionally.
This also stops them from being deployed 🙁
The solution was to bump this up to the next level which is 512Mb however, this will presumably incur a cost
2022-10-05 Update
September -> October’s invoice came to $1.17 for the additional RAM used. Fly do not charge invoices under $5.00 so this was completly free 🎉