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:
# 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.
# ✅ 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.