geoipupdate keeps the GeoIP databases current on your own machines

Binary databases only

The scope of the tool is one sentence, and it is worth quoting in full because it is the kind of limitation that saves an afternoon. The GeoIP Update program performs automatic updates of GeoIP and GeoLite binary databases, and CSV databases are not supported. That is the whole product, a small program whose job is to fetch a licensed database from MaxMind and put it where your software expects to find it. The licence angle is implicit in the design, since the databases require an account and a licence key, which is why the program has a configuration file with credentials in it and a documentation set that covers both the program and the config. The program itself is deliberately free, licensed under the Apache License 2.0 or the MIT License at your option, with the copyright held by MaxMind from 2018 to 2026.

Six ways to install it

The README spends more space on installation than on features, which is a fair reflection of where the difficulty is. Releases are provided for Linux, macOS and Windows. On Linux the tarball route is to download and extract the archive, which leaves a directory named something like geoipupdate_5.0.0_linux_amd64 depending on version and architecture, and then copy the binary to where you want it to live, with the documented command copying it to /usr/local/bin/geoipupdate. For Ubuntu there is a PPA, added with the add-apt-repository command and then apt update and apt install geoipupdate. There are also .deb and .rpm packages, installed with dpkg -i or rpm -Uvhi, and both of those land the binary in /usr/bin rather than /usr/local/bin, which is the first thing to get wrong. On macOS the tarball is the same as Linux with a darwin archive, and Homebrew is a single brew install geoipupdate. Windows uses a zip with a geoipupdate.exe inside. There is Docker documentation and a Proto plugin route for the moonrepo toolchain.

The config path changes with the install method

This is the detail that catches people, and the README calls it out for every install route. After a tarball install, geoipupdate looks for the config file at /usr/local/etc/GeoIP.conf by default. After the .deb or the .rpm, it looks at /etc/GeoIP.conf instead. On Windows it looks at a path under ProgramData on the system drive, in the MaxMind GeoIPUpdate folder. The Makefile shows why, because the config file location and the database directory are set per operating system in the build. On Windows the two are the ProgramData MaxMind GeoIPUpdate paths, and elsewhere the config is /usr/local/etc/GeoIP.conf with the data in /usr/local/share/GeoIP, which is the same pair the tarball install lands on. So the binary you get from a package manager looks in a different place than the one you drop in yourself, and the documentation for the configuration itself lives in a separate file for the GeoIP.conf format.

Building from source and moving the defaults

Building from source needs the Go compiler at version 1.26 or newer, and the easiest route is go install, which puts the binary in the Go path bin directory:

$ go install github.com/maxmind/geoipupdate/v8/cmd/geoipupdate@latest

If the default paths are not right for your environment, they can be changed at build time with linker flags rather than at run time, which is the unusual part of this program's configuration model. The defaults are set in the main package as two variables, the config file and the database directory, and the build command sets both:

go build -ldflags "-X main.defaultConfigFile=/etc/GeoIP.conf \
        -X main.defaultDatabaseDirectory=/usr/share/GeoIP"

The consequence for a distribution packager is that the paths are compiled in, not configured at runtime, so a Linux build with the defaults in one place and a Windows build with the ProgramData paths is the normal case rather than an exception. A user who moves the binary to a different machine has to have the same layout, or has to build it again.

The Makefile generates the config and the man pages

The build file shows how the packaging is put together, and it is a good example of a repository that ships more than a binary. The default target builds the binary and the data directory, and the data target produces a set of files from templates: the GeoIP.conf sample, the documentation of that config in Markdown, the program documentation in Markdown, and then the man page versions of both, the .5 page for the config and the .1 page for the program. The templates are rendered with sed, substituting the config file and data directory placeholders, and there is a comment explaining that sed reads a backslash in the replacement text as the start of an escape, so the backslashes in the Windows paths have to be doubled before they can be substituted. That is a small but telling detail, because it is the kind of thing that only appears when a project is built on more than one platform. The version is also injected at link time, defaulting to unknown when it is not set.

A small dependency set for a small program

The dependency list is short and tells you what the program does at the edges. There is a backoff package, which is what makes the download resilient against a server that is briefly unavailable, and a file locking package, which is what stops two scheduled runs from writing the database at the same time. The command line parsing uses pflag, the testing uses testify, and there are the usual net and sync packages from the standard library ecosystem. The module requires Go 1.26.0. The Go module path is versioned as github.com/maxmind/geoipupdate/v8, so the major version of the program is in the import path, and the repository ships with a .goreleaser.yml for building the release artifacts, a golangci configuration, a precious configuration for the linting and formatting rules, a yamllint configuration and a lychee configuration for link checking in the documentation.

Where the project stands

The release history shows the cadence of a utility that is not changing shape. The listed versions are v8.0.0 published on 2026-07-10, 7.1.1 on 2025-07-09 and 7.1.0 on 2024-11-18, so a major version in July 2026 after a year of patches, and the repository is not archived with the last push on 2026-10-19, so work continues between releases. The documentation is split across the repository and the website. The program documentation and the GeoIP.conf reference live in the doc/ directory, the Docker instructions are in doc/docker.md, and the configuration guide is hosted on the MaxMind developer site along with a specific upgrade guide for anyone coming from GeoIP Update 3.x, which is a hint that a large installed base is still on the old version. Bug reports go to the GitHub issue tracker, and the top level also carries a dev-bin directory, a mise configuration, a proto.yaml and a Makefile that does the packaging work described above.

Editorial conclusion

geoipupdate fits an infrastructure team that keeps a fleet of servers geolocating their traffic and wants the database refresh to be a scheduled job rather than a manual download, since the client handles the download, the licence check and the file placement, and the same binary works across the three platforms. It does not fit a project that wants the CSV databases, because CSV is explicitly not supported, and it does not fit a team that wants the updater and the data in one container without thinking about persistence. Before you deploy it, decide where the databases should live and make sure the config path matches, because the default differs between a tarball install, a deb and a Windows zip, and note the release state, where v8.0.0 was published on 2026-07-10 and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. maxmind/geoipupdate on GitHub
4. README
5. Releases