fly-atc

A SaaS toolkit for converting a personal application into a efficient, siloed, multi-tenant application, where each user of your application is assigned a dedicated virtual machine.

** Work in Progress **

Usage

Quickstart (single tenant):

bundle add fly-atc
bundle binstubs fly-atc

Replace thruster with fly-atc in Dockerfile.

Quickstart (multi-tenant):

bundle add fly-atc
bin/rails generate atc

Edit config/atc.yml as needed.

For approximately $1 US per month, you can run:

Vertical scaling can be achieved by adding more machines.

Motivation

I've been running my Showcase software for nearly three years. Things have changed over time that I now want to take advantage of. I want take the opportunity to package those changes in the form of a toolkit that others can take advantage of.

From Wikipedia description of SaaS:

SaaS customers have the abstraction of limitless computing resources, while economy of scale drives down the cost. SaaS architectures are typically multi-tenant; usually they share resources between clients for efficiency, but sometimes they offer a siloed environment for an additional fee.

The focus of this toolkit is efficient, siloed, multi-tenant applications with no changes to the application, taking advantage of:

That's a lot of moving parts. I've documented my current architecture and published a blueprint.

The goal of fly-atc is to enable you configure multiple tenants and then not worry about this further, enabling you to focus on your application.

Approach

For illustrative purposes consider a SaaS Calender application implemented in Ruby on Rails using SQLite3 as the database. (My showcase application is a bit more involved than a calendar, but those details aren't important).

Key concepts:

  • Each user/customer has a primarly location, and is assigned a single machine near that location. Such machines can be accessed from anywhere, but have lower latency near that location.
  • Each user can have multiple calendars. Each calendar is associated with a single tenant on the user's machine. Each tenant consists a running instance of the web server application with one (or more) databases.

With that in mind, consider the following URL paths:

  • /bellevue/2025/winter/
  • /bellevue/2025/summer-medal-ball/
  • /bellevue/2025/summer-showcase/
  • /boston/2025/april/
  • /boston/2025/mini-comp/
  • /boston/2025/october/
  • /livermore/2025/the-music-of-prince/
  • /livermore/2025/james-bond/
  • /raleigh/2025/disney/
  • /raleigh/2025/in-house/

The first segment of the path identifies the user, and therefore the machine. The next two segments combined identify the tenant on that machine. This is but a subset of the planned showcases, you can see a full list or even a map (click on the arrows under the map to move to different continents).

fly-atc's responsibilities are to:

  • Route requests to the correct machine
  • Ensure databases are present/restored from backup
  • Start/stop tenants as required
  • Hand off requests to tenants

Rails 8 introduces thruster. fly-atc is a replacement for thruster:

  • thruster requires no configuration, is limited to a single tenant.
  • fly-atc enables multiple tenants, based on your configuration.

Implementation

Based on:

Near term plans:

  • Remove certificate/https support
  • Add launch on request / shutdown on idle
  • Add fly-replay

On the radar:

  • Support for targets other than fly.io.
  • Support for platforms other than Rails, likely starting with Node, and focusing on popular ORMs: Prisma, TypeORM, and Sequelize.
  • Dashboard. One should be able to deploy new users and make other configuration changes using only your cell phone. I do this today with my showcase application.