Learn the secrets of Rails deployment and everything it takes to successfully run your application in the wild.

„Screw it! — Moving my Rails app to production takes more time than developing it!“ — Every Rails developer before their first release —

Your Rails application is the heart of your business. Built with the utmost care, adhering to best practices, and tested extensively. You trust your codebase and you can hardly await your first customers.

But before you can lean back and monitor your dashboard for incoming sales, there is an intermediate step you postponed for as long as possible: Moving your application from your development machine into the wild.

You already tried hosting your application with a PaaS like Heroku, EngineYard, or Ninefold only to find out that they do not quite cut it for you:

For serious apps, they are awfully expensive. Don't let their free tier lure you into thinking that they are offering a great deal: While their smallest offerings are enough for hobby projects or a shortcut to quickly test a production app in the wild, a PaaS is going to cost you a lot of money as soon as your application needs background jobs, caching or monitoring. They even charge you for more database rows.

Don't let their free tier lure you into thinking that they are offering a great deal: While their smallest offerings are enough for hobby projects or a shortcut to quickly test a production app in the wild, a PaaS is going to cost you a lot of money as soon as your application needs background jobs, caching or monitoring. They even charge you for more database rows. They make you worry about data integrity. With new leaks being exploited every other day, having your valuable customer data stored on someone else's server does not contribute to a peaceful sleep. Neither does having to rely on someone else to apply the latest patch to a system library.

With new leaks being exploited every other day, having your valuable customer data stored on someone else's server does not contribute to a peaceful sleep. Neither does having to rely on someone else to apply the latest patch to a system library. They prevent you from becoming a better developer. No specific Ruby versions, no cutting-edge application servers, no exotic database — only what the service provides. This shields you from operations — a topic serious developers must not neglect — and prevents learning new marketable skills which will become more and more important in the future.

You are on a point where you have outgrown hosting with a PaaS and realize that rolling your own infrastructure is the way to go.

But there is a wealth of information to digest before you are even able to provision a Rails stack and a lot of questions need to be answered.

„Moving to production defeats Rails' agility in minutes.“ — Every Rails developer during their first release attempt —

Picture yourself having all the needed information to spin up a server from the ground up — without needing to hunt down every tiny drip of wisdom scattered around the web — plus a dedicated workflow to turn this information into a blueprint to apply to any bare naked machine:

You spin up a Rails server in minutes. Setting up and configuring a Rails server requires a lot of steps, but you only have to worry about them once: When you build your server's blueprint which will make provisioning of every future machine a no-brainer — be it in your staging or production environment.

Setting up and configuring a Rails server requires a lot of steps, but you only have to worry about them once: When you build your server's blueprint which will make provisioning of every future machine a no-brainer — be it in your staging or production environment. You deploy your app with a single command. Worry-free deployments mean that you can push new releases as soon as they are ready. Not having to rely on some highly opinionated deployment tool means that you can tweak each of your applications' deployment process to be most efficient.

Worry-free deployments mean that you can push new releases as soon as they are ready. Not having to rely on some highly opinionated deployment tool means that you can tweak each of your applications' deployment process to be most efficient. You learn marketable skills no tool can replace. Rails is based on Rack — and so are many other great Ruby web frameworks. Why not use your knowledge to host and deploy your Sinatra/Hanami/Camping apps the same way?

Your application development reaches a whole new level:

„There will no longer be a difference between running your app locally and serving it to your customers.“ — Me, promising —

The problem is gathering all the necessary knowledge, most of which is buried inside of half-assed blog posts and outdated tutorials. Finding and evaluating this information is demoralizing and takes days, weeks or even months of trial-and-error — time you would rather spend on developing awesome products for your customers.

Unfortunately, up until a few years ago there has not been a single resource providing you with distilled information on how to efficiently build your environment this way.

Then there was. And now it is back in its awesome third edition.