Alpine Linux Packages Scraper

Alpine Linux Packages Scraper

Scrape Alpine Linux packages from any release branch, repository, and architecture, up to one million per run. Every package comes with its version, license, maintainer, and upstream URL. Export filtered APK index data to CSV, JSON, Excel, or XML.

Building a software bill of materials for an Alpine Linux container image is painful when you manually look up each APK. The official package index is a flat file, so you can not filter by branch, repository, or architecture in one query. This Actor reads the Alpine Linux package index directly, matches packages against a glob pattern, and returns every match in a flat row you can audit or export.

Who uses it	What they scrape Alpine Linux for
DevOps engineers	Generate a full component inventory for a specific Alpine release before a security audit.
Security analysts	Pull every package in a container image so you can bulk-check versions against a CVE database.
Embedded Linux maintainers	Export the package set for a target architecture such as aarch64 to freeze a build manifest.
Open source compliance officers	Collect per-package license fields to verify a distribution meets your open source policy.

What it does

This Actor collects Alpine Linux package metadata from a chosen release branch, repository, and CPU architecture, and returns each matching package as one flat row.

• 📋 Glob name filter: match packages with wildcards like apk*, python3*, or *ssl*, or a bare * for the full index.
• 🔢 Release branch selector: target edge (rolling) or any stable v3.x branch from v3.15 through v3.23.
• 📦 Repository filter: narrow results to main, community, or testing, or search all repositories at once.
• 🖥 Architecture filter: restrict results to x86_64, aarch64, armhf, riscv64, loongarch64, and more, or fetch every architecture.
• 🔗 Enriched detail mode: opt in to collect description, install size, origin, commit hash, build time, and dependency lists from each package detail page.

Results export to CSV, JSON, Excel, or XML, or straight from the API.

What you can do with Alpine Linux data

📄 Generate a container SBOM.

A platform engineer runs the Actor with branch v3.21, arch x86_64, and name filter * to export every package in that release as a CSV bill of materials for a compliance review.

🔍 Audit a single Alpine release for CVE triage.

A security analyst scrapes all main repository packages on edge for aarch64, enriches dependencies, and cross-references versions against the OSV.dev database.

🧊 Freeze an embedded Linux build manifest.

An embedded Linux maintainer exports the community repo packages for armhf on Alpine v3.20 before locking down a Yocto-based build.

⚖️ Verify open source license compliance.

A compliance officer runs the Actor against the full v3.22 index and filters the flat JSON output to count packages by license family (MIT, GPL, Apache) for a distribution audit.

Why choose this scraper

	What you get
Fixed schema across branches	The same flat fields whether you scrape edge or a five-year-old stable release.
No API key or PKI setup	Reads the public package index over HTTPS; no Alpine account or app registration needed.
Architecture-aware	Separate runs for x86_64, aarch64, armv7, and others so your SBOM stays specific to the target board.
Built-in dependency enrichment	One checkbox adds the full depends and provides lists plus build metadata from each detail page.

How it compares

This Actor and the alternative Alpine Linux Packages Scraper both pull APK metadata, but this one adds architecture filtering, a glob-based name matcher, and optional per-package dependency enrichment.

Feature	ParseForge	Alpine Linux Packages Scraper - APK Metadata
Glob-based name filter	Yes, using * and ? wildcards	Not listed
Per-architecture selection	Yes, 10 architectures plus All	Not listed
Enriched dependency and commit data	Yes, opt-in per-package detail fetch	Not listed
Release branch filter with edge and stable	Yes, edge plus v3.15 through v3.23	Yes
Repository filter (main, community, testing)	Yes, with All option	Yes

Configure the run

Drive the Actor with a package name glob, an Alpine release branch, a repository, and a CPU architecture. Filters apply as the index is read so only matching packages land in your dataset. The Input tab lists every parameter.

A first run with the defaults:

{
 "name": "apk*",
 "maxItems": 10
}

A larger pull:

{
 "name": "apk*",
 "maxItems": 200
}

Pricing

Pay-per-result: $0.042 per result collected. You pay only for the results written to your dataset.

Results collected	Approximate cost
100 results	$4.20
1,000 results	$42.00
10,000 results	$420.00

New Apify accounts start with $5 in free credit.

Free users

Free-plan runs return up to 10 results as a preview. Upgrade your Apify plan to collect up to 1,000,000 results per run.

Run it

1. Create a free Apify account with $5 in credit.
2. Open the Alpine Linux Packages Scraper.
3. Set your inputs and any filters, then click Start.
4. Export the results as CSV, Excel, JSON, or XML from the Dataset tab.

Run it programmatically through the Apify API (run-sync-get-dataset-items) or the ApifyClient for JavaScript and Python.

Use with AI agents (MCP)

Give an AI agent live access to Alpine Linux through the Model Context Protocol. Add the Actor to Claude, Cursor, or any MCP client:

claude mcp add --transport http apify "https://mcp.apify.com?tools=parseforge/alpine-linux-packages-scraper"

Then prompt it in plain language to run the scraper and read back the results.

Troubleshooting

The run finished but I got zero results.

Check your glob pattern and filters. A typo such as apk** or a branch that does not carry a particular repo (for example, testing on a stable release) will produce an empty dataset. Try * as the name and 'All repositories' first to confirm data is reachable.

Why does the run take so long when I request many packages?

The base index fetch is fast. When includeDependencies is on, each package requires one extra HTTP request to its detail page, so processing 10,000 packages means roughly 10,000 extra requests. Raise maxItems only as high as you need.

I enabled enrichment but the dependency fields are empty.

A package detail page may not list dependencies if the package has none, or if the mirror temporarily omits the field. Spot-check the same package on pkgs.alpinelinux.org. If the data is missing there too, the package genuinely has no dependencies recorded.

The dataset contains duplicate package rows.

Alpine lists a package once per architecture and repository combination. If you select 'All repositories' and 'All architectures', the same package name will appear multiple times, one row per architecture-repo pair. This is correct and intentional.

My custom glob pattern is not matching the way I expected.

The glob syntax uses * for any number of characters and ? for exactly one. A pattern like lib* matches libc, libssl, and libreoffice. If you need an exact package name, do not add wildcards around it.

FAQ

Question	Answer
Does this scraper need an Alpine Linux account or API key?	No. It reads the public package index over standard HTTPS. There is no login, no token, and no rate-limiting beyond normal HTTP politeness.
What is the difference between the branch filter and the repository filter?	The branch is the Alpine release, such as edge (rolling) or a stable version like v3.21. The repository is the package tier within that branch, such as main, community, or testing.
Can I get the full dependency tree for a package?	When you enable the includeDependencies option, the Actor visits each package detail page and returns the complete depends and provides lists plus origin, commit hash, and build time. This adds one extra request per package.
How do I filter by package name?	Use the name field with a glob pattern. apk* matches packages starting with 'apk', python3* matches Python 3 packages, and *ssl* matches anything with 'ssl' in the name. A single * returns everything.
Which Alpine architectures can I query?	You can pick one of x86_64, x86, aarch64, armhf, armv7, ppc64le, riscv64, s390x, or loongarch64, or select 'All architectures' to pull every arch in one run.
Why are there fewer results when I enable dependency enrichment?	Enrichment fetches additional detail pages for each package. If you set a low maxItems limit, the Actor stops after that number of successful enrichments, which may happen before all packages are processed.
How do I scrape only the packages installed in my Docker Alpine image?	Run apk list --installed inside the container to get the exact package names, then feed those names as a glob (for a small set, run once per name) and match the branch and architecture of your base image.
Does this Actor work with Alpine Linux 3.14 or older?	The branch selector goes back to v3.15. Older branches may still exist on the mirrors but are not listed in the UI enum; you would need a custom build to target them.
What export formats are supported?	Within the Apify platform you can export the dataset to CSV, JSON, Excel, XML, or RSS. The Actor itself returns standard JSON rows.
Is the scraper rate-limited by the Alpine mirrors?	The Actor makes standard HTTP requests to the package index and detail pages. It does not hammer the mirrors, but if you request hundreds of thousands of packages with enrichment enabled, a run will take longer because each package needs its own detail fetch.

Related actors

Browse the full ParseForge collection for more scrapers.

🆘 Need help? Email parseforge@protonmail.com with your run ID, your input, and what you expected.

⚠️ Disclaimer. This Actor is unofficial and is not affiliated with, endorsed by, or sponsored by Alpine Linux Development Team. It collects only publicly available data. You are responsible for using the collected data in compliance with the source's terms of service and applicable data-protection laws, including GDPR, CCPA, and PIPL. Do not use it to collect personal data unlawfully.