Simple Rails 8 & Sqlite3 Deployment Example / Article Request

, , , ,
1

It would be amazing if there was an official and up to date article for deploying a simple rails app using sqlite3 with solid_queue.

Deploying to a single machine with a single volume is very straight forward and the new launch command is amazing - the automatic setup there is flawless, great work!

Where I think there is some confusion is setting up multiple machines to avoid fly host failures ( as fly will always suggest doing once you have deployed a single machine app ).

We are not trying to add complexity to “scale” and get read replication at the edge, simply handle host outages on fly with min 2 machines.

Thanks!

1 Like
4

This is literally what I am working on right now. It won’t get you all the way there, but will get you closer.

Some background reading/viewing I recommend meanwhile: Supercharge the One Person Framework with SQLite: Rails World 2024.

Specifically, I’m looking into automatically setting up Litestream with Tigris.

3 Likes
5

Ah looking forward to this article @rubys!

Backups with litestream to Tigre’s sounds great, would this article also mention a way to have multiple machines / processes running at the same time using SQLite.

Some examples I see are:

  1. A web process with multiple worker processes.
  2. multiple web processes for host failures running min: 1.
  3. Bonus, multiple web processes running in multiple data centers to benefit from read replication at the edge, while processing jobs on multiple worker processes in the primary region.

Thanks!

6

If you want read replication, you might want to look into LiteFS - Distributed SQLite · Fly Docs . My current focus is on LiteStream which can work with LiteFS, but is focused on a different use case.

SQLite is an embedded database which only supports linear writes, so only one machine can be active at one time. What I am looking into at the moment is enabling single machine with failover capabilities, and to be clear, initially not even automated failover.

1 Like
7

Manual-only failover would still be a big step forward—just as my own 2¢.

Many people can tolerate the site itself being down for 18 hours, without being able to stomach that corresponding amount of data loss, :fried_egg:…

Maybe there would need to be an entire subsection pointing out the subtle distinctions, though, given that the platform (probably wisely) always nudges people toward two machines (as mentioned at the top)…

variant data durability automatic failover pitr dist. reads lightweight workers‡ horizontally scaled workers rails-friendly
SQLite (only) No No No No Yes No Yes
SQLite + Litestream Yes No Yes No Yes No Pending
SQLite + Litestream + neo-standby† Yes Yes Yes No Yes No Pending
SQLite + app-level gossip replication Yes Yes No Yes Yes Yes Very No?
LiteFS Yes Yes No Yes Yes No* No*
LiteFS + LiteFS Backup Yes Yes Yes Yes Yes No* No*

†The existing standby mechanism is restricted to machines without services, as I understand it.
‡All workers fitting on the same Machine as the main web app instance.
*Not impossible, just pretty far outside what people seem to expect from Rails idioms.

8

Working prototype here: GitHub - rubys/fly-atc: A SaaS toolkit for mutli-tenant production deployments with zero-config streaming backups

How this ties into the original request: while there is no automatic failover (yet?), if a volume or machine dies simply delete them and create a new set… even in a different region! When the new machine starts up, it will pick up where the original machine left off.

Try the demo.

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.