Bridgetown: Ruby static sites with an optional fullstack layer

Bridgetown's static-first scope and intended Ruby users

Bridgetown addresses the gap between a static site generator that ends at a frontend build command and a server framework that makes every page depend on an application runtime. It is aimed primarily at Ruby developers who need to combine local content, API-derived data, templates, and frontend assets in one site project. The resulting site can be exported as a complete website for a CDN such as Render or a conventional web server.

That output model is useful for documentation, blogs, marketing sites, and content-heavy sites that do not need a live application process for every request. Bridgetown also remains relevant when one corner of a site later needs dynamic behavior, because its README says it integrates with Roda selectively, "only when and where you need it." This is a concrete boundary rather than a claim that every Bridgetown site is static.

The README does not provide a detailed installation command for creating a new site, nor does it state minimum Ruby, Node.js, or package-manager versions. Its "Start Here" section directs new users to the Bridgetown documentation, command-line usage guide, site configuration guide, and deployment guide. That omission matters for evaluation: the repository explains the framework's scope, but the README does not let an editor reproduce a first generated site without following external documentation.

Bridgetown's content-to-export processing path

The documented build path begins with resources held in the project and external data loaded from APIs. Bridgetown combines that content during rendering. Resources can carry metadata through front matter, while data files provide additional site information. Templates written in Markdown, ERB, Liquid, Serbea, and other supported formats determine how the content is presented.

The output is not merely an HTML directory assembled by hand. Bridgetown also processes frontend assets through esbuild, covering the JavaScript and CSS build pipeline described in the README. Templates, resource metadata, API data, data files, and compiled assets therefore converge in a generated site that can be served without a Ruby process. The project repository is divided into multiple gems, including `bridgetown-core`, `bridgetown-builder`, `bridgetown-foundation`, `bridgetown-routes`, and `bridgetown-paginate`, which reflects a system with separate responsibilities rather than one monolithic gem.

External API data adds an important deployment condition. The README confirms that Bridgetown can load external data, but it does not say when those requests occur or whether every deployment target must retain API access at build time. That makes API timing a design question to verify in the configuration and deployment documentation. A site whose essential content changes continuously may therefore need to reconsider whether build-time generation is the right fit.

Bridgetown and Roda define different runtime boundaries

Bridgetown's defining trade-off is that static generation and dynamic application code coexist without forcing the entire site into one execution model. The README says the project exports a complete website for fast CDNs or traditional servers, while its Roda integration supplies fullstack functionality where required. The repository includes a dedicated `bridgetown-routes` component, and the project documentation treats deployment as a separate decision.

This approach differs from deploying a conventional Ruby application whose Rack or Roda application renders every request. A Bridgetown project can keep static pages as generated files and reserve dynamic routing for specific behavior. That can reduce the amount of work assigned to the web server, although the README does not provide request throughput, latency, or resource-consumption figures.

The boundary also creates a consistency problem. Site-wide layouts, navigation, metadata, and assets may need to work in both exported templates and dynamic Roda routes. The README does not document how shared layouts, authentication, caching, or rollback work across those modes. It is also silent on database requirements and on whether dynamic features can be hosted on the same target as generated output. Teams with a mostly static site and a small account or form feature may find this arrangement appropriate, while teams whose public pages all depend on session-specific behavior should verify Roda routing and hosting before committing to it.

Bridgetown installation starts with the external setup documentation

The README's user setup path is documentation-led. It directs readers to install the Bridgetown gem, learn the command-line interface, configure the site, and select a deployment method. It does not provide the exact gem installation command, a site generator command, a starter template name, or a minimal first-site file tree. Those commands must not be guessed from the repository name.

A first useful setup therefore requires following the linked install and command-line documentation, creating a site with the commands documented there, then reviewing `Site Configuration` before adding resources. The expected first outcome can be described precisely even though the invocation is absent: the generated project should provide the site structure, configuration, resources, templates, and frontend asset locations described by Bridgetown's structure, resources, template-engine, and frontend-assets documentation. The repository README does not state a particular generated directory name or terminal message.

For source development against the repository rather than normal site creation, the README does give exact commands. These commands clone the monorepo, install development gems, and execute the full test suite. They do not generate a deployable example site, so they should not be presented as the normal installation tutorial.

Running Bridgetown's monorepo checks from a local checkout

Contributors can inspect the multi-gem repository locally. The README identifies the repository as a monorepo and provides a development sequence. `git clone` fetches the source, `cd bridgetown` enters the checkout, `bundle` installs development dependencies, and `bundle exec rake` runs the full test suite according to the README.

git clone [email protected]:bridgetownrb/bridgetown.git
cd bridgetown
bundle
bundle exec rake

After cloning and entering the repository, a contributor should expect the commands to prepare the development environment and invoke the root test task. The README does not define expected test counts or output lines, so those cannot serve as acceptance criteria. A successful command exit is the concrete check available from the documented sequence.

The repository also offers narrower and broader contributor paths. A single unit test can be run with `script/test test/test_foo.rb`, while `script/test` runs the full suite according to its description. The root-level `bundle exec rake test_all` tests the entire monorepo, and `script/cibuild` adds RuboCop linting. These commands imply a distinction between local validation and CI-oriented checks. They also add maintenance cost for contributors because changes in one gem can interact with sibling gems in the same repository.

A separate website repository can consume the locally modified `bridgetown-core` gem through a path dependency in its `Gemfile`. This is useful for framework development, but it replaces a published gem with a filesystem dependency, so deployment must have access to that path.

Bridgetown releases, MIT terms, and framework adoption costs

The repository is not archived, and its last push was on 2026-10-14. The recent release history includes `v2.2.2` on 2026-07-06, `v2.2.1` on 2026-06-14, and `v2.2.0` on 2026-05-20. These dates show recent release activity, although the README does not provide a formal support window for each release.

Bridgetown is distributed under the MIT License. That permissive license generally makes it possible to use, modify, and redistribute the software subject to the license text and its conditions. This is not legal advice, and adopters should review `LICENSE` and dependency terms for their particular distribution model.

The upgrade cost is more relevant than the license. Bridgetown spans several gems, content conventions, template engines, configuration, and esbuild integration. Teams may need to review changelog entries, run the full monorepo test suite when contributing, and verify generated output after upgrades. The README does not document a one-command framework upgrade path for site repositories, a compatibility matrix for Ruby or Node versions, or a rollback procedure. Those gaps should be checked in the release notes and deployment documentation before a production migration.

Editorial conclusion

Developers who already work in Ruby and want one framework across static content, frontend builds, and selective Roda integration should start evaluating Bridgetown. Projects that require a runtime backend on every request or need installation commands supplied locally by a quick-start guide should first verify those deployment and setup requirements. The decisive first checks are the current documentation for site creation, the behavior of the required Ruby and Node dependencies, and the chosen host's compatibility with Bridgetown's static export and dynamic route model.

Frequently asked questions

Official sources

1. bridgetownrb/bridgetown on GitHub
2. License: MIT
3. Project website
4. README
5. Releases