TileMill: a browser based map design studio with a seven year gap in its release history

A design studio, not a tile server

TileMill is described in one line in the repository as a modern map design studio, and that framing is accurate in a way that the word tile server would not be. The application runs as a Node process and renders its interface in your browser. The README is explicit that there is no standalone GUI, that TileMill currently only works in server mode, and that your browser is the interface. On a developer laptop that is convenient: no X11, no desktop application, and the editor is reachable from another machine on the same network.

What you are authoring is a map style, in Mapbox GL style terms, together with the data sources it draws from. The `RENDERING_PIPELINE.md` file at the repository root is the honest place to look for how those two things connect, and its presence at the top level, rather than under `docs/`, suggests the rendering path is the part the project considers worth explaining.

The runtime is Node.js with Mapnik doing the actual raster work. `package.json` pins `mapnik` at roughly 3.7.2 and pulls in `modestmaps`, `carto`, `sphericalmercator`, `backbone` for the interface, and the TileMill project's own `tilelive`, `millstone` and `bones` packages by git tag rather than from the registry. Those three git dependencies matter: they are pinned to specific tags (`bones` at 1.3.31, `tilelive` at v5.14.0, `millstone` at v0.6.18), so an install is only reproducible as long as those tags still exist upstream.

Cloning and running it on macOS as the README describes

There is no package on npm to install, which the README states directly: there are no native packages provided, and installation requires cloning the repository. The quick install path is a clone, an nvm-managed Node version, and two npm commands.

git clone https://github.com/tilemill-project/tilemill.git
cd tilemill
nvm install lts/carbon
nvm use v8.15.0
npm install
npm start

The Node version is not incidental. `nvm install lts/carbon` followed by `nvm use v8.15.0` pins the runtime to Node 8, and the Dockerfile in the repository root agrees, building against `node:8.15` and `node:8.15-slim`. The README lists the tested matrix as Linux with Node 8.11.3 LTS and macOS 10.14 with Node 8.15.0 LTS/carbon, and states plainly that TileMill should theoretically work on Windows but is not tested there.

There are also non npm prerequisites. Mapnik greater than version 3.6.2 is required, though the README says earlier versions may work, and Protobuf needs `libprotobuf-lite` plus `protoc` installed on Ubuntu. Separate installation scripts exist for macOS and are described as possibly usable on Ubuntu and Windows with modification, which tells you how much confidence the project places in those paths.

Postgres comes along in the compose file

Tile exports need a spatial database, and the docker-compose file in the repository brings one up alongside the studio. This is the more reproducible of the two install routes for that reason.

git clone https://github.com/tilemill-project/tilemill.git
cd tilemill
docker-compose up

The compose file starts a `kartoza/postgis:9.6-2.4` service with its data on a named volume, publishes port 5432, and then starts the `tilemill` service on `linux/amd64` with ports 20008 and 20009 published. The application is reachable at `http://localhost:20009`, which matches the README, and the database connection details the README quotes are `host=localhost port=5432 user=docker password=docker dbname=gis`. Compose passes those values through as `PGPORT`, `PGHOST`, `PGDATABASE`, `PGUSER` and `PGPASSWORD`, so the same connection works from your own client.

The README adds a caveat that catches people out: because docker volumes are used for the containers, if you want to use SQLite databases you have to interact with the volumes to get the databases into the container. In other words the SQLite path is workable but not the smooth one in this setup.

Inside the image, the second stage of the Dockerfile runs as the non root `node` user, exposes the tile port and the web port separately, and starts with `node /usr/src/app/index.js --listenHost=0.0.0.0`. The split between 20008 for tiles and 20009 for the web page is worth remembering when you put this behind anything.

What changed in v1.2.0 and what seven quiet years mean

The release history is the most informative thing in this repository, and it needs reading carefully. Versions 1.0.1 and 1.1.0 were both published in 2019. The next release, v1.2.0, was published on 2026-08-30, which is a gap of more than seven years between the 1.1.0 tag in June 2019 and the 1.2.0 tag in August 2026.

The README's opening section, headed Latest Status and dated August 30, 2026, describes v1.2.0 as focused on making map exports easier, adding visual aids for colours and improving Postgres management, and points to a changelog for detail. It also states that the next planned release, v1.3.0, will update npm to a more recent version along with other dependencies. That single sentence tells you the Node 8 pinning is a known, scheduled piece of technical debt rather than a philosophical position.

The last push was on 2026-09-06, a little over a week after the v1.2.0 tag, so the project is not archived and work has continued since the release. The honest reading is that a long dormant project was revived recently enough that the release notes matter more than the accumulated history: nothing in the 2019 to 2026 gap represents tested support for anything, and there is no evidence in the repository of which dependency versions were resolved in between. The `package-lock.json` at the root is the file to inspect for exactly what a fresh install pulls today.

Where this fits against QGIS, Kosmtik and Mapnik itself

The comparison that matters for TileMill is against other ways of making map tiles. QGIS is the general answer: it can style, render and export tiles from a desktop install, with a large plugin ecosystem and no server component. TileMill's argument is the browser interface and the style as a text artifact you can keep in version control, which suits a team that treats map styling as code.

Kosmtik is closer, being built on Mapnik as well and aimed at tile generation from vector data with style files. Where TileMill differs is the studio around it: data sources are managed through the interface, the database connection is part of the application configuration rather than a separate export step, and the same project serves preview and export.

Raw Mapnik is the floor under both. Style XML plus a render pipeline is all TileMill adds, and what that addition costs you is the Node dependency tree described above, plus the fact that Mapnik itself is unmaintained in its original form and has been forked. For a one off map render, going straight to Mapnik or a hosted service is less work. For iterated style design across a project, the studio is the reason to use this instead.

The BSD-3-Clause license recorded in the repository metadata, and the `LICENSE.md` at the root, mean the styling work you produce is not tied to a vendor. That is the practical argument for building a style here rather than locking it into a commercial design tool.

Editorial conclusion

TileMill is worth a look if your work is cartographic rather than analytical: designing a style, previewing it in a browser and rendering tiles from a PostGIS or SQLite source is exactly the loop it was built for, and it does that without a desktop GIS install. It is the wrong tool for large data analysis or for anyone who needs current Node and current Mapnik. Start from the docker-compose path, which brings up PostGIS on port 5432 alongside the studio on 20009, and read RENDERING_PIPELINE.md before committing to it, because the export pipeline rather than the style editor is where the version pinning bites.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. tilemill-project/tilemill on GitHub