# buffalo: a Rails shaped project layout for Go web development

> buffalo is a Go web framework that bundles routing, templating, sessions, assets and an optional ORM into a project generator, so a new application arrives wired together rather than assembled dependency by dependency.

**gobuffalo/buffalo** — Rapid Web Development w/ Go

- Repository: https://github.com/gobuffalo/buffalo
- Website: http://gobuffalo.io
- Stars: 8,416 · Forks: 581
- Language: Go
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/gobuffalo-buffalo

## What the generator gives you on the first run

The README's pitch is that `buffalo` helps you generate a web project that already has everything from front end work such as JavaScript and SCSS through to the back end pieces like database access and routing, all hooked up and ready to run. What it hands back is not a library you import, it is a project structure with an agreed place for every file. That is the actual product, and it is why the README says it is not just a framework.

The documentation lives at gobuffalo.io rather than in the repository. The README links three starting points: an installation page, a page for creating a new project, and a tutorials index. There is no `go install` line in the README, which means the exact install command is settled on the documentation site rather than in the file you would expect to find it. The repository itself is the implementation of the framework, with `app.go` holding the application type, `handler.go` and `middleware.go` the request pipeline, and `render/` the template integration.

The dependency list in `go.mod` is the most concise description of what Buffalo actually is at runtime: gorilla/mux for routing, gorilla/sessions and gorilla/handlers for session and middleware handling, gobuffalo/plush for templates, gobuffalo/events for application events, monoculum/formam for form parsing, cobra for the command line, and BurntSushi/toml for configuration.

## Two branches, and modules are not optional

Buffalo ships two long lived branches and the distinction matters when you pin a dependency. `main` is described as current mainstream development and `v1` as the current stable release, with v1 being the current stable version of Buffalo core. The README also spells out which branch a pull request should target: feature requests go to `main`, and version specific branches accept bugfixes only.

There is a hard requirement attached to all of it. Buffalo works only with Go modules, and the README warns that `GOPATH` mode is likely to break most of the functionality of the ecosystem, with a link to a blog post about the road to 1.0 requiring modules. If you maintain a larger GOPATH-era codebase, adopting buffalo means migrating first.

The supported Go versions are named explicitly: the README says the team supports the last two versions of Go, which it gives as 1.23 and 1.24, and that older versions may work but are not encouraged. The repository's own `go.mod` requires Go 1.25.0, which is a stricter floor than the README's prose and a useful detail when your CI image is pinned:

```go
module github.com/gobuffalo/buffalo

go 1.25.0
```

The plugin directories in the tree, `plugins/` and `internal/`, suggest the project generation is extensible rather than fixed, though the README does not document the extension mechanism.

## Plush instead of html/template, and why that is a real choice

The most interesting decision in the framework is the template engine. The README names github.com/gobuffalo/plush as the templating package and states it was chosen over the standard `html/template` for a variety of reasons, the biggest being that it is significantly more flexible and easier to work with. That is a real departure from the standard library, and it is the piece most likely to matter to you if you come from a Rails or ERB background, since plush is closer to ERB in feel than to Go's template syntax.

The current dependency is `github.com/gobuffalo/plush/v5 v5.0.11`, so the fifth major version of the template engine is what v1 of the framework uses today. The `render/` directory in the repository holds the integration, and v1.1.2 included a change to avoid memory allocation when calling Render, which tells you the render path is on the hot path and gets treated as such.

Routing is the other layer with a stated rationale. The README names gorilla/mux and says it was chosen for stability and flexibility, conceding there might be faster routers while arguing this one is the most powerful. Gorilla also supplies sessions, cookies and handlers, and the README frames the whole approach as keeping Buffalo's own core small by gluing together packages rather than reimplementing them. If you are deciding whether that is the right trade for your team, SHOULDERS.md in the repository is where the full list of upstream projects lives.

## The benchmark section that refuses to publish numbers

The README has a benchmarks section, and it is worth reading for the attitude rather than the content. The author declines to publish any, points readers to the benchmarks published by the projects listed in SHOULDERS.md, and tells them to run their own. The stated reasoning is that Go is fast enough and that there is no interest in playing the benchmark game.

That is unusual candour in a framework README, and it has a practical consequence you should plan for: there is no published throughput figure to compare buffalo against another web framework. If performance is a selection criterion, you have to build it and measure it yourself, which means the comparison cost falls entirely on your side of the decision.

The database layer is optional by design. The README describes pop, and its command line tool Soda, as chosen because they balance simplifying common tasks against being idiomatic and giving the flexibility needed to build an app, noting that pop and Soda share the same core philosophies as Buffalo. The word optional matters: nothing in the tree forces a database on a project that does not want one, though `render/`, `mail/` and `binding/` are shipped as part of the core repository rather than separate modules.

## v1.1.4 turned into a dependency security release

The most recent release, v1.1.4 published on 2026-03-20, is almost entirely about security. It added an automated vulnerability scanning job using `govulncheck` in CI on every push and pull request, added a SECURITY.md with vulnerability reporting guidelines, and upgraded `golang.org/x/net` to v0.45.0.

The list of CVEs fixed in that one upgrade is the striking part. Four high severity issues, including the HTTP/2 rapid reset attack CVE-2023-39325, request smuggling in h2c CVE-2022-41721, and two denial of service issues, plus seven medium severity issues covering an XSS in the HTML tokenizer, an HTTP proxy bypass via IPv6 zone IDs, HPACK continuation flood, and the HTTP/2 stream cancellation attack. That is a measure of how much transitive HTTP stack risk a Go web framework inherits simply by depending on `golang.org/x/net`, and it is the kind of thing you would otherwise have to discover during an incident.

The feature work in the same release was thin by comparison: support for multiple file uploads through `c.File()` in a single form field, and template metadata injection letting templates reach file metadata such as path, base name, extension and modification time via `TemplateMetadataKeys` and `TemplateBaseDir`. v1.1.3 from 2025-10-07 carried the earlier parts of that same work, and v1.1.2 from 2025-05-17 was the plush and helpers upgrade.

The repository `Dockerfile` shows how the project tests itself, which is a fair indicator of what is covered:

```dockerfile
RUN go mod tidy
RUN go test -tags "sqlite integration_test" -cover -race -v ./...
```

Both tags matter. The sqlite tag pulls in a real database driver for the integration tests rather than mocking the ORM layer.

## Conclusion

buffalo makes sense for a team that wants the shape of a Rails application in Go, with a generator that hands you a working layout on day one and a dependency set chosen by people who had to pick one. It does not make sense if you want a small library to drop into an existing service, because the framework's value is precisely the project structure and the opinions inside it. The core has been on the v1 branch through v1.1.2 and v1.1.3, with v1.1.4 published on 2026-03-20 focused on dependency security rather than new features, and the last push to main was on 2026-03-21. Start at the installation page on gobuffalo.io, then read SHOULDERS.md in the repository before deciding, because that file is the real argument for the framework and it is more honest than the feature list.

## FAQ

### Is buffalo still being developed?

The last push to the main branch was on 2026-03-21, and v1.1.4 was published on 2026-03-20. That release focused on security work, including a govulncheck CI job and an upgrade of golang.org/x/net to v0.45.0, rather than new features.

### Does buffalo require Go modules?

Yes. The README states that buffalo works only with Go modules and that GOPATH mode is likely to break most of the functionality of the ecosystem. The repository's own go.mod requires Go 1.25.0, while the README says the supported Go versions are the last two releases, given as 1.23 and 1.24.

### Which branch should I depend on, main or v1?

The README describes main as current mainstream development and v1 as the current stable release of Buffalo core. Pull requests for new features are expected against main, while v1 only takes bugfixes.

### Does buffalo need a database?

The model and ORM layer is optional. The README describes pop and its Soda command line tool as the chosen database access packages, but nothing in the repository requires a database for a project that does not want one. Integration tests do use sqlite, selected through the sqlite build tag in the Dockerfile test command.

## Sources

- [gobuffalo/buffalo on GitHub](https://github.com/gobuffalo/buffalo)
- [License: MIT](https://github.com/gobuffalo/buffalo/blob/main/LICENSE)
- [Project website](http://gobuffalo.io)
- [README](https://github.com/gobuffalo/buffalo/blob/main/README.md)
- [Releases](https://github.com/gobuffalo/buffalo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gobuffalo-buffalo