HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gorilla
mux
Go2013–2025
gorilla / mux

mux

Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍

31Distinct people
37Mentions
0Explicit recommenders
21.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:34:28 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year37 dated mentions

Observed mentions: 2013-01-01 05:37:44 UTC to 2025-05-11 17:26:21 UTC.

02462013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 3 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC606
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC211
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC615
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC514
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC532
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC110
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
gorilla/mux Package gorilla/mux implements a request router and dispatcher for matching incoming requests to their respective handler. The name mux stands for "HTTP request multiplexer". Like the standard http.ServeMux, mux.Router matches incoming requests against a list of registered routes and calls a handler for the route that matches the URL or other conditions. The main features are: It implements the http.Handler interface so it is compatible with the standard http.ServeMux. Requests can be matched based on URL host, path, path prefix, schemes, header and query values, HTTP methods or using custom matchers. URL hosts, paths and query values can have variables with an optional regular expression. Registered URLs can be built, or "reversed", which helps maintaining references to resources. Routes can be used as subrouters: nested routes are only tested if the parent route matches. This is useful to define groups of routes that share common conditions like a host, a path prefix or other repeated attributes. As a bonus, this optimizes request matching. Install Examples Matching Routes Static Files Serving Single Page Applications (e.g. React, Vue, Ember.js, etc.) Registered URLs Walking Routes Graceful Shutdown Middleware Handling CORS Requests Testing Handlers Full Example Install With a correctly configured Go toolchain: go get -u github.com/gorilla/mux Examples Let's start registering a couple of URL paths and handlers: func main() { r := mux.NewRouter() r.HandleFunc("/", HomeHandler) r.HandleFunc("/products", ProductsHandler) r.HandleFunc("/articles", ArticlesHandler) http.Handle("/", r) } Here we register three routes mapping URL paths to handlers. This is equivalent to how http.HandleFunc() works: if an incoming request URL matches one of the paths, the corresponding handler is called passing (http.ResponseWriter, *http.Request) as parameters. Paths can have variables. They are defined using the format {name} or {name:pattern}. If a regular expression pattern is not defined, the matched variable will be anything until the next slash. For example: r := mux.NewRouter() r.HandleFunc("/products/{key}", ProductHandler) r.HandleFunc("/articles/{category}/", ArticlesCategoryHandler) r.HandleFunc("/articles/{category}/{id:[0-9]+}", ArticleHandler) The names are used to create a map of route variables which can be retrieved calling mux.Vars(): func ArticlesCategoryHandler(w http.ResponseWriter, r *http.Request) { vars := mux.Vars(r) w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Category: %v\n", vars["category"]) } And this is all you need to know about the basic usage. More advanced options are explained below. Matching Routes Routes can also be restricted to a domain or subdomain. Just define a host pattern to be matched. They can also have variables: r := mux.NewRouter() // Only matches if domain is "www.example.com". r.Host("www.example.com") // Matches a dynamic subdomain. r.Host("{subdomain:[a-z]+}.example.com") There are several other matchers that can be added. To match path prefixes: r.PathPrefix("/products/") ...or HTTP methods: r.Methods("GET", "POST") ...or URL schemes: r.Schemes("https") ...or header values: r.Headers("X-Requested-With", "XMLHttpRequest") ...or query values: r.Queries("key", "value") ...or to use a custom matcher function: r.MatcherFunc(func(r *http.Request, rm *RouteMatch) bool { return r.ProtoMajor == 0 }) ...and finally, it is possible to combine several matchers in a single route: r.HandleFunc("/products", ProductsHandler). Host("www.example.com"). Methods("GET"). Schemes("http") Routes are tested in the order they were added to the router. If two routes match, the first one wins: r := mux.NewRouter() r.HandleFunc("/specific", specificHandler) r.PathPrefix("/").Handler(catchAllHandler) Setting the same matching conditions again and again can be boring, so we have a way to group several routes that share the same requirements. We call it "subrouting". For example, let's say we have several URLs that should only match when the host is www.example.com. Create a route for that host and get a "subrouter" from it: r := mux.NewRouter() s := r.Host("www.example.com").Subrouter() Then register routes in the subrouter: s.HandleFunc("/products/", ProductsHandler) s.HandleFunc("/products/{key}", ProductHandler) s.HandleFunc("/articles/{category}/{id:[0-9]+}", ArticleHandler) The three URL paths we registered above will only be tested if the domain is www.example.com, because the subrouter is tested first. This is not only convenient, but also optimizes request matching. You can create subrouters combining any attribute matchers accepted by a route. Subrouters can be used to create domain or path "namespaces": you define subrouters in a central place and then parts of the app can register its paths relatively to a given subrouter. There's one more thing about subroutes. When a subrouter has a path prefix, the inner routes use it as base for their paths: r := mux.NewRouter() s := r.PathPrefix("/products").Subrouter() // "/products/" s.HandleFunc("/", ProductsHandler) // "/products/{key}/" s.HandleFunc("/{key}/", ProductHandler) // "/products/{key}/details" s.HandleFunc("/{key}/details", ProductDetailsHandler) Static Files Note that the path provided to PathPrefix() represents a "wildcard": calling PathPrefix("/static/").Handler(...) means that the handler will be passed any request that matches "/static/*". This makes it easy to serve static files with mux: func main() { var dir string flag.StringVar(&dir, "dir", ".", "the directory to serve files from. Defaults to the current dir") flag.Parse() r := mux.NewRouter() // This will serve files under http://localhost:8000/static/<filename> r.PathPrefix("/static/").Handler(http.StripPrefix("/static/", http.FileServer(http.Dir(dir)))) srv := &http.Server{ Handler: r, Addr: "127.0.0.1:8000", // Good practice:
Read the full README on GitHub

What Hacker News says

6 sources
I don't understand, so explain it to me like I am a child, I am certain I am missing something basic and the developers on the project aren't as dumb as it seems. Seriously, it seems so goddamn basic. I am going to walk you through step by step how I would add an external library to my Go project. #1. Switch to the go project directory #2. Fork for the new feature (adding_mux) #3. Run go get github.com/gorilla/mux #4. Add import "github.com/gorilla/mux" to my code, use mux for great goodness #5. Commit my code (this is commit of ./src which includes two things, the addition of the new github.com/gorilla/mux/* and my code using that new library) #6. Merge #7. Push At this point, the commit that was just checked in doesn't need a change to its import path, will never break and will work as it was committed FOREVER. git clone FOO; go build
Read the rest
BAR -- victory! If at some point I want to update that library (new cool feature!) #1. Switch to go project directory #2. Fork for updating library (update_mux) #3. Run go get -u github.com/gorilla/mux #4. Write code using new awesome features #5. Commit my code (again, "my code" in this case is both the update to the mux library, and my new usage of it, again committed together for great goodness!) #6. Merge #7. Push! I feel like one of us is bat shit insane, and at this point, I am just hoping it isn't me. EDIT: Another cool side effect of this is you end up with localized hermetic copies of your code with references for posterity to where you got it, bonus points! EDIT 2: For reference, there are various forks of the source he "released" (abandoned? Sold for 28k? whatever) ... I think you can start looking at the github network from here: https://github.com/runningwild/haunts
In Golang dependency hell in Haunts The Manse game
What? It ONLY looks for localized copies. When you have import "github.com/gorilla/mux" it will look in $GOROOT/src/pkg/github.com/gorilla/mux and $GOPATH/src/github.com/gorilla/mux if it is missing, you can fulfill it with go get github.com/gorilla/mux which will place it in the first place in $GOPATH What are you talking about breaking with distributed teams? Since $GOPATH/src/github.com/gorilla/mux is in source control you NEED NOTHING and it will be a known working git clone. EDIT: Additionally, it will never auto-update those dependencies (and break your build) unless you explicitly tell it to with "go get -u".
In Golang dependency hell in Haunts The Manse game
Great post. I've done some experimentation with Go for web dev, and encountered similar problems; it's such a delight to write code in that I'd love to use it in production, but can't justify spending a lot of time debugging the immature libraries and writing new ones, particularly not on the clock for clients. I too ran into a problem with null types in another library interfacing with postgresql. The weak points I found were: * Lack of an ORM (there are many, almost all incomplete, and lacking in some way) * Immature or incomplete db interface libraries * No db migrations (would love to see a simple sql-only solution here) * Package management is simple and elegant but without explicit versioning, so forking is the end result to ensure stability * No process pool management for running Go behind something like Apache or nginx. This goag
Read the rest
ain tool looks interesting for the last point though: https://github.com/rcrowley/goagain and the routing I found pretty straightforward with something like github.com/gorilla/mux so there are solutions, they're just not always as fully baked or as mature as you'd find in other ecosystems. One place Go shines though is the great built in web server which really simplifies getting up and running and testing, and which I see they've built on here. Given how easy and pleasurable it is to work with, and the focus on practicality rather than language features, I'm quite confident that Go will reach it's stated aim of becoming a popular server-side language quite soon. For those new to the philosophy behind the language, I found this informative - http://talks.golang.org/2012/splash.article
In Gotchas, Irritants and Warts in Go Web Development
The go import tool does version go std lib packages, but I think the worry is more about external packages - later when the go ecosystem matures, and I'm relying on lots of packages from different sources (say for a web app), with interdependencies, and I must update them regularly for security updates, but don't necessarily want the latest master for all, I have no way to specify versions without rolling my own personal package management, downloading the packages and changing urls etc. If I'm in an org and sharing this with others I'd basically end up reinventing a package proxy internally in order to control what software versions are used to build. This is a small flaw in the go packaging system (and it is a flaw) which I'm sure they'll fix, either with a convention to always use branches for versions (which I guess is doable, but onl
Read the rest
y if it becomes widespread), or by changing import to take an argument for the version. So something like: import "github.com/gorilla/mux/1.0.3" or import "github.com/gorilla/mux", ~> "1.0.3" which would let you specify any minor updates say and possibly other permutations, and thus might be more flexible. I believe a few things have been suggested on the list but I haven't followed the conversation, not sure what the outcome was - perhaps just that it needs further thought. At present the first solution is possible, BUT it needs to become a convention which everyone follows in order to be useful (involving named branches or tags at the repo). The other advantage of this is that it states requirements fully in the package concerned - otherwise all we know is that this code requires github.com/gorilla/mux, not which version or when it was last tested/imported, whether it will work with the latest release or not, etc. But then it would let you run into conflicts by accidentally importing two versions of the same package with different paths. The current convention of no version certainly puts more onus on the package maintainers to maintain backwards compatibility, or on users to maintain their own library of packages which they periodically update, and I see the arguments for it. Of course none of this matters if you're just one person using packages to build an app at one moment in time, but if you yourself supply packages/apps to others, or want to setup members of an org over time with the same set of packages in the same state, and rely on other packages to compile yours, it can become more complex. Other package managers tend to have a central point to adjust package dependencies, and make sure packages are always available forever at the same uri, so it'll be interesting to see how go manages this when go packages become more complex and widely used, start to be removed by maintainers, and start to have complex chains of dependencies on specific versions, or whether the much simpler go system in the end leads to a saner situation and puts the onus for this problem back on end users.
In Go as an alternative to Node.js for Very Fast Servers

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.