MSRK logo vs Fly's balloon with boxing gloves
Image by Annie Ruygt

MRSK was introduced last month and it truly is a game changer. From the announcement:

It sits on top of basic Docker, and harvests all the benefits you get from isolated containers with a sliver of the complexity associated with most other solutions. Instead of sending the deployment pipeline off to servers in the cloud, it runs entirely on your own machine. Just like Capistrano did.

And it appears that the admiration is mutual:

DHH Praise Tweet

Aw, shucks. Makes me want to blush. I suspect that much of the admiration is due to the fact that shares more in common with your local data-center than with most cloud providers. We transmogrify Docker containers into lightweight micro-VMs and run them on our own hardware in racks around the world, so your apps can run close to your users. It is also worth noting that the back-end for our GraphQL API is a Rails app.

While there are plenty of differences between MRSK and, the starting and end points are pretty much the same.

You start with an application and a Dockerfile. Rails 7.1 will provide a starter Dockerfile. fly launch will use this Dockerfile if it exists, otherwise it will provide Dockerfiles for all current versions of Rails as well as a number of other frameworks including Elixir, Laravel, Django, a number of Node frameworks, and even Rack apps. We even make dockerfile-rails available to all - you are welcome to use it to build Dockerfiles for your existing Rails applications and deploy to any datacenter or cloud using MRSK.

The desired result is to have multiple instances of your application deployed, each connected to a common database, load balanced, protected by a firewall, with a SSL certificate, and monitored with health checks.

DHH followed up with a video demonstrating the workflow using MRSK:

Following are key points in the video:

Time Description
2:15 MRSK requires a bit of knowledge of Linux and Docker
2:55 rails new ship --main --css tailwind
3:02 cd ship
rails g scaffold post title:string body:text
rails db:migrate
3:39 Hetzner - select region
Create server
4:12 create config/deploy.yml
specify the service name, image name
4:20 grab the ip address, paste into deploy.yml
4:28 set up an environment template: mrsk envify
4:44 mrsk deploy
6:31 note that docker may need to be restarted;
recommend remote docker buildx setup
7:15 create another vm for db and app servers
7:32 add two firewalls - ports 80 and 22 for the app servers, 3306 for db
8:28 add load balancer
8:55 change rails db config, install gem, change config/deploy.yml
9:40 create database
10:09 update config/database.yml
10:23 update env template with mysql root password
10:44 mrsk setup
11:20 mrsk redploy
11:38 mrsk details
12:39 mrsk rollback
13:11 setup domain name using Cloudflare
13:48 http3 and compression
14:22 failure - look at logs with nice grep feature!
14:44 origin mismatch
15:06 uncomment two lines in config/environments/production.rb
15:28 mrsk redeploy

Inspired by DHH’s video, I made one of my own, developing and deploying the same application. I substituted for Hetzner. Rails for Rails 7.1.0.alpha. And Postgresql for MySQL.

Here are the key points in the video:

Time Description
1:21 rails new ship --css tailwind
cd ship
1:50 rails g scaffold post title:string body:text
1:54 flyctl launch --force-machines --region ord
3:08 fly deploy
4:30 fly open
5:02 fly machine clone --region cdg
5:48 fly dashboard
7:25 vi app/views/posts/index.html.erb
7:42 fly deploy

You can play with this right now.

I used the [ terminal]( for this demo - try it yourself if you have a GitHub account or an email address. You can also run this on your own machine, we have a [Hands-on]( guide that will walk you through the steps.

Try Fly for free

Like DHH, I started with a cold cache - in particular with no Docker layers already having previously been built. Unlike DHH, I chose NOT to fast forward over the boring parts, as I want to realistically depict how long it takes to deploy an application.

Both and MRSK are young, and undoubtedly will learn much from each other. I am particularly envious of rollback, love the log grep feature, and while Cloudflare has moved on to HTTP/3, is currently only at HTTP/2.

As both MRSK and share the goal of providing to the developer only a sliver of the complexity associated with most other solutions, the true winners of these types of competition are developers everywhere.

By standardizing on a common piece of infrastructure, in this case Dockerfiles, people are free to pick the solution that best suits their needs, confident in the fact that they can switch back and forth or even use both simultaneously as there is no lock in here.

We welcome you to compare our prices against your favorite data center or cloud, and to draw your own conclusions as to matters like developer ergonomics and ease of use.