Dynos
A dyno is a single process running your ruby code on a server in our grid. Each dyno is independent and includes all the layers in this diagram.
The number of dynos running for a given app directly affects the maximum concurrency and therefore the performance of that app. You can run as few or as many dynos as you need – new dynos can be launched in under 2 seconds for most apps.
A dyno is roughly equivalent to a Mongrel, except that dynos are spread across multiple servers, so performance in most cases is greater.
4 dynos are equivalent to the compute power of one CPU-core on other systems.
POSIX Environment
POSIX Environment
Each dyno has its own unix user and a special read-only filesystem. We use the battle-tested unix permissions system (rather than a security model running inside the Ruby VM) to securely partition your app from other users.
The environment is pre-loaded with your app's database and cache information, so when the dyno process is launched, it has access to those configurations.
Ruby VM
Ruby VM
MRI (open source, C)
A dyno starts by launching the app server in ruby, which then loads your application.
The ruby VM landscape is bustling with activity – there are many VMs to choose from. Some of the newer VMs aren't yet mature enough for production use, and others are stable but not entirely backward compatible with existing apps.
We are using standard, plain-vanilla MRI ruby, to maximize stability and compatibility. We are closely following progress on other ruby VMs.
POSIX Environment
App Server
App Server
Thin (open source, ruby/C)
Mongrel is the original ruby app server that most people have used. Thin is based on Mongrel, but is smaller, faster, and more stable.
When a dyno is launched, the app server is the process that gets created, which then loads rack and boots your app.
Ruby VM
Rack
Rack
Rack (open source, ruby)
Rack is the webserver interface. It is a simple standard for connecting web requests to a ruby process.
Rack is built into most ruby frameworks and app servers, and provides architectural flexibility for your app with its middleware model.
App Server
Middleware
Middleware
Middleware is completely optional, but using rack (or Rails Metal) you can customize your app's architecture.
For example, handle high-volume request paths right in middleware for a performance boost, or route URLs to multiple apps in the same process.
Using your app's environment variables you can connect to your database or cache directly from middleware.
Rack
Framework
Framework
Ruby on Rails, Sinatra, many others
Any rack-compliant ruby framework will run on Heroku. There are many to choose from, but we suggest Rails for full apps, and Sinatra for lightweight services.
Frameworks are optional, you can also write a bare rack app – ruby code connected directly to web requests.
Middleware
Your App
