sinatra/sinatra: A Ruby DSL for Minimal Web Applications

What Sinatra Is and the Problem It Addresses

Sinatra is a Ruby DSL for creating web applications that eliminates boilerplate. The README opens with a three-line example that illustrates this directly: require 'sinatra', a get block returning a string, and nothing else. That is a complete HTTP server. Rails, the dominant Ruby web framework, solves a different problem: it provides conventions for the full application lifecycle including database migrations, asset compilation, authentication scaffolding and a dozen other concerns. Sinatra makes none of those assumptions.

The target use case is a service that handles a small number of HTTP routes and has no need for the structures Rails imposes. This includes JSON APIs consumed by a single client, webhook handlers, small internal tools, prototype services and applications that are deliberately simple by design. Sinatra describes itself as "classy web-development dressed in a DSL," and the DSL is genuinely minimal: routes are Ruby blocks, parameters come from a hash, the response is whatever the block returns.

Sinatra runs on top of Rack, the Ruby web server interface, which means it can be mounted alongside other Rack applications, used as middleware in a Rails app, or run standalone with any Rack-compatible server. The repository at sinatra/sinatra is the official canonical source, and the homepage is at sinatrarb.com.

The Routing DSL: Named Parameters, Wildcards and Pattern Matching

Routes in Sinatra pair an HTTP method with a URL pattern, each associated with a Ruby block. The README documents the full set of supported HTTP methods: get, post, put, patch, delete, options, link and unlink. Routes are matched in the order they are defined, and the first matching route wins.

Named parameters are extracted into the params hash using a colon prefix in the pattern:

get '/hello/:name' do
  # matches "GET /hello/foo" and "GET /hello/bar"
  # params['name'] is 'foo' or 'bar'
  "Hello #{params['name']}!"
end

Splat (wildcard) parameters use an asterisk and are returned as an array at params['splat']. Optional parameters use a question mark suffix. Regular expressions can replace string patterns entirely. Query string parameters are also available through the params hash without any additional configuration.

Trailing slash behavior is explicit: the README notes that GET /foo and GET /foo/ are treated as different routes, so a developer who wants both to match must register both. This is a deliberate design choice that keeps routing behavior predictable and avoids hidden redirects.

Installing Sinatra and Running a First Application

The README gives a minimal working application:

require 'sinatra'

get '/' do
  'Hello world!'
end

Install the required gems:

gem install sinatra rackup puma

Then run the application file:

ruby myapp.rb

The application listens on port 4567 by default. The README notes that code changes do not take effect until the server is restarted, and recommends rerun or rack-unreloader for automatic reloading during development. The three gems installed are: sinatra itself, rackup (the Rack server runner), and puma (the production application server). The README includes puma in the install command, which signals that puma is the intended server for anything beyond quick local testing.

The application runs on the classic style by default, where route helpers are defined at the top level. Modular applications using Sinatra::Base require a config.ru file and an explicit run directive, which the README covers separately.

Templates, Static Files and the Views Folder

Sinatra supports a wide range of template languages beyond ERB. The README documents fourteen template options: Haml, ERB, Builder, Nokogiri, Sass, SCSS, Liquid, Markdown, RDoc, AsciiDoc, Markaby, RABL, Slim and Yajl. Each template type has a corresponding helper method (haml, erb, slim, etc.) that renders the named template from the views/ directory by default. Templates can also be defined inline as here-documents or as named strings if keeping everything in a single file is preferred.

For static assets, placing files in the public/ directory causes Sinatra to serve them without routing through any handler. The README documents cache control helpers, a send_file method for downloading files, and helpers for generating URLs based on the current request context. The request object is available in any route block through the request method, giving access to headers, cookies, body content and request parameters.

Views have access to instance variables set in the route block, and layouts are supported through a layout.erb convention or an explicit :layout option. Nested layouts are possible using yield with a block.

Modular Style vs Classic Style

Sinatra offers two structuring styles. Classic style uses Ruby's method_missing and top-level method definitions: get, post and other HTTP helpers are available directly at the script level, which makes one-file applications concise. This is the default style when running ruby myapp.rb.

Modular style uses Sinatra::Base as a base class. An application class inherits from Sinatra::Base and defines routes as instance methods. This style is required when using Sinatra as Rack middleware inside a larger application, when multiple Sinatra applications need to coexist in the same process, or when building a gem that includes Sinatra-based routes. The modular style requires a config.ru file to mount the application.

The README documents both approaches and discusses trade-offs: classic style pollutes the Ruby main object namespace, which can cause unexpected method conflicts in complex applications. Modular style is more predictable in large codebases at the cost of slightly more setup. The recommendation from the README is to use classic style for simple standalone apps and modular style for everything else.

Where Sinatra Reaches Its Limits

Sinatra provides no database integration. There is no built-in ORM, no migration system and no database configuration convention. Connecting to a database requires choosing a separate library (Sequel, ActiveRecord used outside of Rails, or another ORM) and wiring it up manually. The README does not document this, which is consistent with the project's philosophy of providing only routing and request handling.

There are also no built-in test helpers specific to Sinatra. The README points to Rack::Test for testing, which works but requires knowing the Rack testing API rather than framework-specific matchers. Authentication, session management beyond the basic Rack session, and authorization are all left to the developer. The contrib gem at sinatra-contrib provides extensions for common tasks like JSON output, multi-route definitions and content negotiation, but these are optional add-ons.

For teams that want these features provided automatically with a standard project layout, Rails is the appropriate choice. Sinatra's design is explicit about what it does not include, and the trade-off is that building anything beyond CRUD routes requires assembling the pieces manually.

Last Push and MIT License

The last push to the sinatra/sinatra repository was on 2026-07-20. The repository has no GitHub releases visible in recent history, though the gem is distributed via RubyGems rather than GitHub releases. A CHANGELOG.md and VERSION file are present in the top-level directory. The MAINTENANCE.md file suggests the project documents its support and maintenance policy explicitly.

The license is MIT. MIT allows commercial use, modification, distribution and private use with no copyleft conditions. The only requirement is retaining the copyright notice and license text. The sinatra-contrib/ and rack-protection/ directories in the repository tree indicate the repository is a monorepo that also hosts the contrib extension gem and the rack-protection middleware used for Sinatra's security features. The sinatra.gemspec file at the root defines the gem metadata for distribution.

Editorial conclusion

Ruby developers who need a small HTTP API, a lightweight web service or a Rack middleware component will find Sinatra directly useful. Rails developers adding a minimal auxiliary service alongside an existing Rails app can use Sinatra's modular style through Sinatra::Base to keep the scope contained. Sinatra is the wrong choice when you need a full application framework: no built-in ORM, no test helpers designed for Sinatra, no asset pipeline. The MIT license allows unrestricted use. Before deploying, choose a production-grade application server (puma is listed in the gem install command) since the default WEBrick server bundled with older Ruby versions is not suitable for production traffic.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. sinatra/sinatra on GitHub