alfred-spotify-mini-player: Controlling Spotify From an Alfred Workflow

A Player That Lives Inside a Launcher

The Alfred Spotify Mini Player is described as an Alfred workflow to control your Spotify library at your fingertips, and the project presents itself as a mini player rather than as a desktop application.

The distinction is the whole design. An Alfred workflow is a piece of macOS automation that lives in the launcher, so the player is a search-and-invoke surface rather than a window. You bring up the launcher, type something, and the workflow talks to the Spotify API to start a track, change the state of the player or search the library. The workflow interface is drawn in the launcher itself, which is why the README shows an example animation of the launcher rather than a standalone app.

The alternative to this design is an application with its own window, its own media keys and its own place in the dock. The launcher approach trades that for the fact that the control surface is already open, already searchable, and already has a keyboard shortcut attached.

It is a niche tool, and the niche is well defined. If you already live in Alfred, the workflow is a few keystrokes away. If you do not, the same thing can be done with a different launcher, but the workflow itself is tied to Alfred.

The Premium Account Requirement

The most important line in the README is a warning, and it changed the project for every existing user.

You now need to have a Spotify Premium account to use the workflow, with a link to the blog post about the Spotify developer access and platform security update, which is dated February 2026 in the URL.

The cause is on Spotify's side rather than in the workflow code. The developer platform tightened who can create and use integrations, and a workflow that controls playback against a personal library needs the access that now sits behind a paid tier. So a project that ran on a free account for years stopped working for a large part of its users, and the author put the requirement at the very top of the README with warning markers around it.

That is worth understanding before installing, because the requirement is not about the workflow's features but about who is allowed to use the API it calls. The second thing to understand is that the author cannot fix it, because the constraint is in Spotify's developer platform.

Installation Is a Single Workflow File

The installation is two steps, and the first one is a download.

Download and install the latest version of the workflow, which is a file with a specific extension:

https://github.com/vdesabou/alfred-spotify-mini-player/releases/latest/download/spotifyminiplayer.alfredworkflow

Then follow the setup documentation.

The .alfredworkflow file is Alfred's own package format, and double clicking it installs the workflow. That is a notable difference from the usual pattern for a tool that needs a token, a client identifier and a callback URL, where you would clone a repository, run an installer and configure a script. Here the code arrives as a package, and the configuration happens through the setup documentation on the project site.

The releases page is the distribution channel, and the README links to the latest version directly, so a user never has to find a release by hand. The project site is alfred-spotify-mini-player.com, and it carries the full information, the download link and the setup documentation.

What the Repository Shows: PHP Source and an Alfred Remote

The repository layout is short and tells you what kind of project this is.

The spotify-mini-player/ directory holds the implementation, and the project metadata records the primary language as PHP, which is the language the server side of the workflow is written in. An Alfred workflow that needs to call a third party API needs something to hold the API token and to serve the player interface, and that is where the PHP comes in.

remote.json is the Alfred remote definition, a configuration file that ships with the workflow.

Then there are resources/ for the icons and images the workflow displays, and resources.idraw, which is a design source file rather than a code artefact, which tells you that the look of the player is drawn somewhere and kept in the repository. There is also a docs/ directory with the images used in the README, and a CLAUDE.md at the root for automated contributors.

The presence of remote.json and resources.idraw together is a good description of the project type. It is a small server side implementation with a designer-drawn interface, packaged for a launcher, rather than a library that other code depends on.

Where the Real Documentation Lives

The README is deliberately short, and every pointer in it leads somewhere else.

The README says to find all information and download the workflow on alfred-spotify-mini-player.com, and that is where the setup documentation, the feature list and the site version of the documentation live. The Features section of the README is a screenshot rather than a list, and the Example section is a short animation, so the detail about what the workflow can do is on the site.

The design reason for that split is the same one as the installation format. A workflow is a binary package, so there is no repository for a user to read for usage instructions, and a README that is the only documentation would have to be in the repository, which a user who installed the package may never open. Putting the documentation on the site means it is reachable from the install instructions.

The one thing the README does insist on is the Premium requirement, and it puts it above everything else, which is the right editorial judgement for a breaking change that affects every user.

The Version Line and What the Release Numbers Say

The releases use an unusual version format, and it is worth reading the numbers as dates rather than as semver.

The recent tags are v-14.3 from 2026-09-11, v-14.2 from 2026-09-02 and v-14.1 from 2026-03-02. The version is prefixed with v- and carries a dash, and the minor number climbs over the year, with 14.1 in March, 14.2 in September and 14.3 nine days later.

So the project is on a fourteenth major line and ships patch numbers inside it, and the gap between 14.1 and 14.2 is six months, which is the pace of a project that follows the platform it depends on rather than a project with a backlog of features. The two releases nine days apart in September look like a response to something changing on the Spotify side rather than to a feature cycle.

The README also carries a set of badges for the release date, the number of commits since the latest release, the open and closed issue counts and the download numbers, which is a way of showing whether the project is still moving. The commits-since-release badge is the honest one to watch, because it tells you whether the source has moved past what you downloaded.

Where the Limits Are

There are three constraints on this project that are not design choices but facts about the environment it runs in.

The first is the account tier, which the README now leads with. A Premium account is required, and that is a platform decision rather than a limitation the author chose.

The second is the launcher. An Alfred workflow is tied to Alfred, which means macOS and Alfred, and there is no equivalent workflow for another launcher, or for a keyboard-driven launcher that does not run macOS. The project is also a mini player rather than a full client, so anything a Spotify client does that needs a persistent interface is out of scope by construction.

The third is that the repository is the source, not the product. The deliverable is a .alfredworkflow file, and the repository holds the code and the design resources it is built from. A user who wants to extend the workflow has to work from the source, and a user who only wants the player downloads a release and is done. The two audiences are different, and the project serves both, which is why the site carries the user documentation and the repository carries the implementation.

The licence is GPL-3.0, the repository is not archived, and the last push was on 2026-09-15.

Editorial conclusion

alfred-spotify-mini-player fits an Alfred user on macOS who wants to start and steer music without leaving the launcher, and who is willing to authorise the workflow against a Spotify account, which is the cost of the whole approach. It is a poor fit if you do not have Premium, since the workflow now stops working without it, and a poor fit if you want a full featured Spotify client, because a launcher workflow is a front end to the Spotify API rather than a player in its own right. Before installing, read the Premium requirement and the setup documentation, because the authorisation step is where the friction is, and note that the repository is the source of the workflow rather than an application you configure. The workflow is GPL-3.0 licensed, the current version is 14.3, and the last push was on 2026-09-15.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. vdesabou/alfred-spotify-mini-player on GitHub