stormy: a neofetch-style weather command for your terminal

A weather card you run like neofetch

stormy is described as a minimal, customizable, neofetch-like weather command line tool, and the neofetch comparison is the most useful thing about it, because it sets the expectation for the output. It is a card, printed once, that tells you the conditions outside and, with the ASCII art turned on, shows it as a picture.

The idea, the structure and the design come from another project, rainy, and the readme says so directly. The difference is the language. The author liked the concept of a Neofetch-style weather command, found that the simplicity and visual appeal of rainy clicked immediately, and wanted to recreate that experience in Go, partly for his own satisfaction and partly because building clean command line tools is what he enjoys.

The feature list is short. Multiple weather providers, OpenMeteo as the default with no API key required, and OpenWeatherMap as the alternative. Current weather conditions with an ASCII art representation. Temperature, wind, humidity and precipitation information. Customisable units, with metric, imperial and standard. A local configuration file. Colour support for the terminal. A compact display mode. And it works out of the box with OpenMeteo.

That last point is the design decision, because a weather tool that needs you to sign up for an API key before it shows anything is a tool most people never finish installing.

The project is MIT licensed, written in Go, and the last push to the repository was on 2026-09-23, with the newest release listed as v0.3.3 from 2025-07-27, after v0.3.2 on 2025-07-22 and v0.3.0 on 2025-07-19.

Two providers, and the one that needs no key

The provider choice is the first decision a user makes, and the configuration file makes it explicit.

The default is OpenMeteo, and the readme is clear that no API key is required. The alternative is OpenWeatherMap, which does require a key, and the api_key setting in the configuration file exists for it. The shipped example configuration shows both cases, the default one with an empty key and the OpenWeatherMap one with a placeholder.

The difference matters for a command that runs on every shell prompt, because the key is a credential and the default provider avoids having one at all. A user who wants OpenWeatherMap presumably wants its specific data or its own account, and the trade is a key in a configuration file.

The acknowledgements name both providers, along with rainy for the overall idea, structure and design, and wttr.in for the ASCII weather icons. That last credit is the one that explains the visual part of the tool, since the icons that make the card look like something are not drawn by stormy itself.

The result is a program that gets its data over the network from one of two services and turns it into a picture. Everything else it does is presentation.

Configuration is a TOML file in the XDG directory

stormy follows the XDG Base Directory Specification for configuration files and creates a default configuration file on the first run, which is the behaviour that makes it installable and forgettable.

The locations are given precisely. On Linux and macOS the file is at ~/.config/stormy/stormy.toml, on Windows it is at the stormy subdirectory of the application data directory, and setting XDG_CONFIG_HOME overrides the default location for anyone who keeps their configuration somewhere else.

The options are eight. The provider, the API key for OpenWeatherMap, the city, the units for temperature and wind speed, whether to display the city name, whether to use colour, the live mode and the compact format.

Two of those are worth explaining. The live mode is a long-running mode with frequent polling that never stops, which turns the command from a one-shot print into something you leave in a terminal window. The compact mode is a more compact display format, which is what you want when the card is taller than the terminal.

The default configuration file looks like this:

provider = "OpenMeteo"
api_key = ""
city = "New Delhi"
units = "metric"
showcityname = false
use_colors = false
live_mode = false
compact = false

The city in the shipped example is New Delhi, so a first run will try to report the weather somewhere the user did not ask for until they change it.

Live mode is the difference between a command and a dashboard

The usage section is the usual list of flags, and it is short because the program has a narrow surface.

stormy
stormy --city "New York"
stormy --units imperial
stormy --compact
stormy --version
stormy --help

Every flag has a counterpart in the configuration file, which is a good sign about the design. The configuration is for the settings you do not want to type, the city you live in and the units you think in, and the flags are for the settings you change occasionally, and the file is the fallback when a flag is not given.

The live mode is the one that changes the character of the tool. A live run polls frequently and never stops, so the card updates in place while you watch it, which is a weather dashboard in a terminal with no key and no browser. The cost is a process that runs forever and a network request every few seconds, so on a metered connection or a laptop on battery it is a thing you start deliberately rather than something you leave in a shell profile.

The compact option interacts with it, because a live card that scrolls off the top of a small terminal is a card you cannot read. The display examples in the readme, with the base, coloured, minimal and numbered variants as images, show that the output is meant to be looked at rather than merely read.

Six ways to install, and the packaging is handled for you

The installation section covers the platforms a terminal tool is expected to run on, and every entry is one command.

For Arch there is the AUR with yay -S stormy, for FreeBSD the ports collection with pkg install stormy, for macOS Homebrew with brew install stormy, and for the declarative crowd Nix with nix profile install pointed at the GitHub repository and the stormy output. There is also go install for anyone with a Go toolchain, and a build from source that is three commands, clone, build, and move the binary into a directory on your path.

The Repology badge tracks the packaging status across distributions, which is the usual way to answer the question of whether your distribution already carries it.

The Nix entry is the one that says something about how the project is maintained, because the repository carries flake.nix and a flake.lock, so the tool is packaged as a flake and the lock file pins its inputs. The.goreleaser.yaml at the root does the same job for the release binaries, since a Go command spread across AUR, FreeBSD, Homebrew and Nix needs a single automated build that feeds them all.

So the distribution story is a normal one for a modern Go command line tool, and the only unusual thing is how completely it is covered, which is a consequence of the project being small enough for one person to package properly.

Four dependencies, and the ones that matter

The go.mod is short enough to read in one go, and each dependency has an obvious job.

The module is github.com/ashish0kumar/stormy, it requires Go 1.23.0 with a toolchain line of go1.23.2, and the direct requirements are BurntSushi/toml at 1.5.0 for the configuration file, fatih/color at 1.18.0 for the terminal colours, k0kubun/go-ansi for the ANSI escape sequences, and golang.org/x/term for the terminal handling.

The indirect requirements are the colour support detection, go-colorable and go-isatty, which are the libraries that answer the question of whether the output is going to a terminal at all. That is the standard problem with colour in a command line tool, and it is worth noticing that the tool solves it rather than assuming.

The TOML choice is also the modern default for a configuration file, and it matches the fact that the settings are a flat list of scalars and booleans, so there is no need for a nested format.

The source layout is small. There is a main.go at the root, an internal directory for the packages, an assets directory for the images used in the readme, and the build files. There is no vendor directory and no code generation, which is what a program of this size should look like.

Editorial conclusion

stormy fits a person who wants the weather on their terminal and does not want a widget, a browser tab or an account, because the default provider needs no key and the output is a single card you can run from a shell alias. It is the wrong choice if you need historical data or forecasts beyond the current conditions, since the tool reports the weather now, and it is the wrong choice if your terminal cannot do colour, which is a setting but a per-terminal limitation. Before you install it, decide whether you want the free provider or an OpenWeatherMap key, and put a city in the configuration file, because the first run creates a default file and the default city in the shipped example is New Delhi.

Frequently asked questions

Official sources

1. ashish0kumar/stormy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases