Deploying Bullet Train with Flightcontrol

The Bullet Train (opens in a new tab) SaaS (Software as a Service) framework extends Rails by providing features, structure, and best practices for building a SaaS application.

This example will show you two different ways to deploy a Bullet Train-based application with Flightcontrol. If you want to learn more about how Flightcontrol deploys Rails applications, check out the Rails Deployment Guide.

Required Environment Variables

We suggest using the dashboard to set environment variables, even if you use a flightcontrol.json file to configure your project. This keeps your secrets out of your source code, and lets you configure different values for different environments.

Two environment variables are required for Bullet Train to work properly:

SECRET_KEY_BASE
RAILS_ENV

Before you get started, you will need to generate a new Rails secret key for your production environment, if you do not already have one.

Rails lets you create a new secret key with the following command:

rails secret

Set the SECRET_KEY_BASE environment variable to the value generated by the rails secret command. If you migrate an existing application to Flightcontrol, you can use the current secret key.

You should also set the RAILS_ENV environment variable to production.

Changes to the Procfile

Bullet Train comes with a Procfile in the root directory that has commands for running the web, worker, and release processes. Flightcontrol's Nixpacks build process will read the release process from the Procfile and run it after building your application as part of a release phase.

However, we need to comment out that release process in the Procfile so that Flightcontrol does not run it twice (once for web, once for worker). Here is an example Procfile from Bullet Train with the release process commented out:

Procfile

# These are not combined because we want to reload all models after the migrations take place.
# release: bundle exec rails db:migrate; bundle exec rails db:seed
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
worker: bundle exec sidekiq -t 25

Changes to the Production Configuration

When you deploy Bullet Train (or most Rails applications) in a cloud environment, you need to handle host security.

Bullet Train (and Rails 6+) uses the config.hosts setting in the config/environments/production.rb file to configure the allowed hosts for your application.

At the end of that file, you should configure two things - one is the list of hosts that your application will respond to, and the other is to disable host security for the health check of your application.

If you use Flightcontrol to provide a custom domain for your application, you should add that domain to the list of allowed hosts. For example, if you use example.com as your custom domain, you should add .example.com to the list of allowed hosts.

For preview environments and applications without custom domains, Flightcontrol provides a unique domain name from cloudfront.net. For these cases, you should add .cloudfront.net to the list of allowed hosts.

config/environments/production.rb

  # ✅ YOUR APPLICATION'S CONFIGURATION
  # If you need to customize your application's configuration, this is the place to do it. This helps avoid merge
  # conflicts in the future when Rails or Bullet Train update their own default settings.
  config.hosts << ".cloudfront.net"
  config.host_authorization = { exclude: ->(request) { request.path == '/' } }

Configuration Options

One way to deploy your application is to use the Flightcontrol dashboard to configure your project.

When you set up your project in Flightcontrol, add a new Flightcontrol environment for your production environment.

Inside that Flightcontrol environment, you will need several services:

Web Server
Private Worker
Relational Database Service (RDS)
Redis (ElasticCache)

The Web Server service will need one change to the default configuration. Set the Build Command to the following:

mkdir -p tmp/pids && bundle exec rake assets:precompile && bundle exec rails db:migrate

For the Private Worker service, you need to run Sidekiq. Change the Start Command to the following:

bundle exec sidekiq -t 25

The Build Command for the Private Worker service should be a " " (single space), so that the default build command is not run.

The Database service will need to match your chosen database - Postgres, MySQL or MariaDB. The ElasticCache service does not require any configuration changes.

For any of these services, you will need to pick the right instance sizes and instance counts for your application's work load.

You will also need to pick an AWS region for deployment (such as us-west-1 or us-east-1).

Next Steps

After configuring your project with either the dashboard or with the flightcontrol.json file, Flightcontrol will deploy your application to AWS.

You can also setup a Custom Domain for your application to use your own domain name instead of an assigned name.

Blitz.js Docker