One URL returns terminal, browser, image, JSON, or metrics output
A request to wttr.in/London can return an ANSI forecast for curl, while query options select plain text, custom one-line fields, JSON, PNG, HTML, or Prometheus exposition text. Locations can be cities, airport codes, coordinates, IP addresses, domain names, and named attractions. That range explains the project's staying power: one endpoint fits a shell prompt, a tmux status bar, a browser bookmark, or a small program without making each client draw weather symbols itself.
The code behind that surface is compact enough to inspect. Our measured commit c369bc4 had 638 files and about 13,052 lines of source in a 13.2 MB checkout. Installation still brought in 101 packages, which is more machinery than a curl user ever sees. The Apache-2.0 license permits reuse, and the repository includes a Dockerfile plus a dedicated tests directory. One CI workflow is present, a much smaller automation footprint than many services with this level of public use.
A self-hosted instance still depends on geocoding and weather data
The current README describes a single binary with fonts, pages, translations, and static assets embedded at build time. Serving useful forecasts requires data around that binary. The documented configuration points to a MaxMind GeoLite2 City database for IP resolution, OpenCage for turning names into coordinates, disk and database cache paths, and an upstream weather endpoint. OpenCage needs a token. WorldWeatherOnline is optional, with its own registration and token when selected.
The sample weather URL points back to the public wttr.in JSON endpoint unless the operator changes it. That makes the default self-hosting recipe a private presentation and cache layer over the original service, rather than an independent forecast source. Build preparation also installs font packages before producing the binary. Our sandbox completed that build in 7 seconds, but production still needs provider quotas, cache sizing, file permissions, logs, and a policy for upstream errors.
What happened when we ran it
Our sandbox installed wttr.in in 27 seconds with 101 packages, then built it successfully in 7 seconds. The test step ended with exit code 1 after 53 seconds. Go reported 4 passed packages and 21 failed packages out of 25. This was commit c369bc4 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image.
The end of the log showed setup failures in packages including internal/assets, internal/config, internal/formatter, internal/query, and internal/server. It showed successful results for internal/ip and internal/renderer/oneline, then a final FAIL. Those lines do not state the root cause, so it would be wrong to blame a missing font, network call, or code defect from that evidence alone. The useful finding is exact: the build passed, while 21 of 25 package tests did not get through setup in our environment.
The checked-in Docker path has a specific open repair
The Dockerfile builds on Debian and copies the result into Alpine. Open pull request 1294 says that binary uses glibc through a cgo SQLite dependency, while Alpine supplies musl, causing the container to fail when executing the file. The same report says the image command lacks the required server subcommand and configuration path. Its proposed fix changes the runtime image, supplies the arguments, and handles an unconfigured geocoder without a nil-pointer crash.
That report is still an open pull request, so adopters should verify the current image rather than treating the proposed repair as merged behavior. Our 7-second native build does not test whether the multi-stage image starts, accepts its config, or serves a forecast. The repo's Dockerfile is valuable as a record of required build fonts and ports, but production packaging needs a start-up test that launches the exact image and requests text, JSON, and PNG output.
Weather source errors matter more than pretty terminal output
The service supports compact formats that are easy to place in automation. Easy parsing does not make the forecast authoritative. Open issue 1280 reports identical, incorrect temperatures for several cities in Chile and labels the problem as data-source related. Issue 1270 says documented high and low placeholders were returning literal field markers for the reporter. Our lab did not reproduce those reports. Both remain directly relevant when an application consumes the output without a person checking it.
A personal status line can tolerate a stale or odd result. Safety alerts, agricultural controls, travel dispatch, and paid weather products need a source with defined coverage, validation, and support. The README recommends reasonable polling intervals and provides wttr.is as a fallback domain for scripts. Our 53-second failed test run adds another reason to keep retries and error handling in the client instead of assuming every HTTP response contains sound forecast data.
September commits show activity without a release channel
GitHub recorded a push on September 7, 2026. A Docker repair pull request opened on September 6, and other issues received updates during August. The repository had 30,507 stars and 331 combined issues and pull requests when fetched. That count is not a bug total. Together with the recent push, it shows a maintained project with a large backlog and ongoing user reports.
GitHub's latest-release endpoint returned 404, and the tags list contained only markers for the old Python backend and old Go frontend. Commit-based development can work for a public service, but organizations that require versioned artifacts must create their own pinning and change-review process. The 4-of-25 package result on commit c369bc4 makes that discipline more important. For casual use, the hosted endpoint remains the project's clearest success. Self-hosters are taking on a service, its providers, and its unfinished packaging details.