---
description: Instructions for reploying Rails apps to Fly.io
---

# Fly.io rails app hosting

As of this writing, my instrumental\_template app is pre-configured to deploy to Fly.io, as is Ripple.fm.



***

### Deploy to staging

First checkout staging branch.  Then deploy to staging app, which will deploy the current code in your local environment (you're currently viewing staging).

```
git checkout staging
flyctl deploy -c fly.staging.toml --build-arg RAILS_ENV=staging
```

### Deploy to production

First checkout main branch.  Then deploy to staging app, which will deploy the current code in your local environment (you're currently viewing main).

```
git checkout main
flyctl deploy -c fly.production.toml --build-arg RAILS_ENV=production
```



***



### How it works:



The project must have 2 toml files in the root:

* `fly.production.toml`
* `fly.staging.toml`

The only difference between these 2 files is the app name at the top references an app name on Fly.io. &#x20;

* Note:  It's best to have 2 "organizations" in Fly.io, one for staging, one for production.  The app name can reference an app in any organization.



Then it uses the `Dockerfile` to run the deployment.

This line:

```
ENV RAILS_ENV=${RAILS_ENV:-production} \
```

Allows us to specify which rails environment each deployment should use.  It defaults to production.



So the deployment CLI command specifies both which .toml file to use and which ENV to use:

```
flyctl deploy -c fly.production.toml --build-arg RAILS_ENV=production
```



Note:  The deployment will deploy the code that is on your local machine (not the code that is currently up on github). &#x20;

* So when you're deploying to production, be on the `main` branch.
* When you're deploying to staging, be on the `staging` brancy.
