Installing a package is usually easy once you know its name and which repository provides it. Finding that combination can take longer, especially when you work across several Linux distributions.
Does the package exist for your distribution release? Is there an ARM build? Which package contains a particular executable? Is the result from the distribution itself or a third-party publisher?
pkgdex puts those questions into a searchable package index. I built pkgdex and run GetPageSpeed, whose repositories are included alongside distribution repositories and other publishers. Here is a practical way to use it, starting with NGINX.
Start with a package name
Open the search results for nginx.
The results are grouped by distribution and release. Each row identifies the repository, architecture, package filename, and description. That makes it possible to see where a package comes from before opening its details.
A name search can also return related packages. For example, the NGINX results include modules and configuration packages as well as the server itself. Read the package name and description rather than assuming every match installs the same thing.
Start with the distribution release you actually run, then check the architecture. An x86_64 result and an aarch64 result are different builds. A familiar package name does not make a build for another distribution interchangeable with yours.
If you prefer browsing first, the home page lists distributions and repositories. The wider index also includes BSD, macOS, and Flatpak sources, but this walkthrough stays with Linux packages.
Inspect the package before installing
Follow a package filename to its detail page. For a concrete example, this NGINX package for openSUSE Leap 16.0 shows its version, architecture, repository, license, dependencies, provided capabilities, and file list.
The file list answers questions that a short package description cannot: where is the executable, which configuration paths are included, and does this build ship the module you need?
The page also provides installation guidance and a download link. Treat it as information about that particular build. For an actual installation, use your distribution's package manager with the appropriate repository configured, so it can resolve dependencies and apply updates.
Finding an older version in an index is useful for investigation. It does not mean that version is the best choice for a new server, or that it is the version your configured repositories will currently install.
Search by a file you recognize
Sometimes you know the executable path but not the package name. Switch to the Files search scope instead of guessing.
Try finding packages that contain /usr/bin/htop.
That search returns packages whose indexed file metadata matches the path. You can then inspect the result for your distribution and architecture.
Using the full path helps narrow the question. Searching for just htop in file metadata can also match completion scripts or other filenames containing that text. Neither result tells you what is installed on your own machine; pkgdex searches repository metadata.
The search tabs also expose Summary, Provides, and Requires scopes. Those are useful when your starting point is a description or a dependency capability rather than a package name.
Limit discovery to one publisher
If you already know which publisher you want, a global search adds unnecessary results.
The GetPageSpeed publisher page groups our indexed repositories. For a specific example, open the GetPageSpeed search for nginx-module-brotli.
This keeps the search within GetPageSpeed while showing builds across distribution releases, architectures, and repository variants. It is a convenient starting point for checking whether we package a module for a particular target.
Before installing an NGINX dynamic module, check that its build matches your NGINX packaging and version. A search match alone does not establish compatibility. Access and subscription terms belong to the source repository; being searchable in pkgdex does not change them.
Get the results as JSON
For a script or a non-commercial project, the public API offers the same kind of package discovery without scraping HTML:
curl --fail --silent --show-error --max-time 20 \
'https://pkgdex.org/api/search/nginx'
The response is a JSON array. Returned fields include name, version, arch, repo_name, distro, and repo_version, plus an id for looking up package details. Do not assume a single response is a complete inventory of every match.
The API documentation describes scoped searches, package detail lookup, and MCP tools for assistants. It currently specifies free use for non-commercial projects, no authentication, and a maximum of 10 requests per second.
Try your next package lookup
Start with a package name, a missing file, or a publisher you already use. Narrow the result to your distribution release and architecture, inspect the package metadata, and then return to your package manager for installation.
Try it at pkgdex.org.
Top comments (0)