Dyno Grid

This is where all the action happens. Your app code runs inside the dyno grid, occupying as many slots as needed. New dynos for your app can be started in under 2 seconds for most apps. Dynos are launched in an environment containing your app's database and cache information.

Compiled Slugs

When you push code to Heroku, we compile a slug – a self-contained, read-only version of your app including all its dependencies, that's ready to be launched into the grid. This is part of how we can start new dynos so quickly.

This compilation step also checks that your app can actually start, and rejects your code if not. This ensures you don't replace running dynos with broken ones during a deploy.

Forget Servers

Never think about servers again. The dyno grid is spread across a large number of servers, based on load. Servers are invisibly managed by the platform, and are never exposed to you.

Your app is securely partitioned from other users.

Server Diversification

Your app's dynos are dispersed across different CPU cores, maximizing performance and minimizing contention. The number of dynos on each server varies with load.

Intelligent Routing

Heroku's routing mesh tracks detailed performance data for your app, and balances load accordingly.

If a dyno is unresponsive for any reason (user bugs, long requests, or high load), other requests will be routed around it.

Disposable Resources

All dynos are disposable. Because new dynos for your app can be started so quickly, it's trivial to start new dynos and route traffic to them.

Misbehaving dynos are simply ignored, and eventually garbage collected.