static-curl builds a single curl binary with no shared library dependencies

Two scripts and a key file, nothing more

The repository is almost empty, and that is the point. The top level holds a .ci/ directory, the LICENSE.txt, the project documentation file, build.sh and mykey.asc. The build script is described as running inside an Alpine docker container, downloading curl, verifying it with gpg, and building it. The key file is Daniel Stenberg's GPG key, used for signing and verifying curl releases. That is the whole design, and the payoff is a build that is reproducible in a narrow sense, since the source is fetched, its signature is checked against a known key, and the compilation happens in a pinned minimal base image rather than on whatever machine happens to run the script. The audience is anyone who has hit the same problem in reverse. The usual reason to want a static curl is that the target machine has an old or unusual libc, or none of the libraries your dynamically linked binary needs, or you are producing a container image and would rather not track a base image's library set. The project describes the goal in one phrase, fully static builds of curl that run anywhere.

The build is featureful by default, with the configure line left editable

The build produces what the project calls a featureful build, with OpenSSL, libssh2, nghttp2 and zlib linked in, supporting most protocols. That combination is the interesting part. A minimal static curl, built with nothing but the system resolver, is small but handles only plain HTTP over TCP. Adding OpenSSL gives you HTTPS with certificate verification, libssh2 gives you SFTP, nghttp2 gives you HTTP/2, and zlib lets you handle compressed responses. If you ship a curl to a scripting environment, a CI runner, or a busybox-adjacent appliance, those four are usually the difference between a binary that works and one that does not. The extension point is stated plainly: tweak the configure options in build.sh if you need something else, and suggestions or pull requests are invited. That is a small but real difference in approach compared with the many static curl recipes that hard code one configuration and leave you to fork. The trade-off is that the default is a larger binary than a minimal build, and the project does not publish size figures, so you would measure that yourself for your target architecture.

Where the binaries come from and which architectures exist

Release artefacts are published on the repository releases page, with a download link per CPU architecture, and the links are pinned to the latest release rather than a specific version, which is convenient for a quick grab and wrong for a reproducible deployment. The architectures offered are amd64, i386, aarch64, armv7, armhf and ppc64le. That list is the practical scope of the project, and it is worth reading as the boundary of what a static curl can be expected to cover. There is no x86_64 variant named differently, since amd64 is that one, but there is no musl or glibc distinction to worry about because the binary is static, and there is no riscv64 or s390x. Windows is deliberately absent from the list, and the reason is given: static binaries for Windows are provided directly by curl itself. That is a sensible division of labour, since producing a working static curl for Windows involves the platform's own cryptography and import libraries in ways the Alpine build path does not cover. If your deployment target is Windows, this project is not the route and the upstream project is.

Verification is part of the build, not an afterthought

The step worth copying regardless of whether you use this project is the verification order. The script downloads curl, verifies it with gpg, and only then builds it, using the key checked into the repository as mykey.asc. The key is Daniel Stenberg's, the same one used to sign curl releases, and the build verifies the signature of the tarball it fetched rather than trusting a checksum alone. This matters more than it might appear, because the usual supply chain risk in a build script of this shape is exactly this step: a script that downloads a tarball from the internet and unpacks it will happily build whatever the server returned, and a hash file next to the download URL is only as trustworthy as the same origin. Verifying against a known public key moves the trust anchor to a key whose fingerprint people have had reason to check for years. The repository is MIT licensed with the licence in LICENSE.txt. The CI configuration lives in .ci/ and the build status badge points at a moparisthe.best Jenkins instance, so the build is run automatically rather than only on request.

What you get is upstream curl, and what that means for updates

The release tags tell you how the versioning works. The recent releases are v8.21.0 dated 2026-07-18, v8.17.0 from 2025-11-16 and v8.11.0 from 2024-11-09, which map onto the upstream curl release numbering rather than a separate project version. The last push to the repository was on 2026-07-15, and the repository is not archived. So the artefact you download is a rebuild of a specific upstream curl release, and the maintenance question is really the upstream question: when curl publishes a security fix, a new tag appears here carrying it. That is a genuine advantage over the many alternative approaches to static curl, where you end up maintaining a private build recipe and a private binary and finding out about CVEs late. The corresponding cost is that you inherit upstream's release cadence and its support decisions, including which platforms upstream still builds for. If your organisation has a policy of running only vendor-supported builds of curl, that policy will point at curl's own Windows artefacts and at distribution packages for the platforms where they exist, and this project is the answer for the platforms where those are not available.

Where a static curl is the wrong tool

There are clear cases where this approach is the wrong answer, and they are worth stating before you wire a downloaded binary into a pipeline. First, TLS trust. A static binary with OpenSSL linked in carries its own certificate handling, and the system certificate store on the target machine is not consulted in the way a distribution package would consult it. If your environment relies on a corporate root installed into the host trust store, a self contained binary may not see it, and you will be adding certificate flags or bundling a CA file to compensate. Second, security response. The binary is a point in time build, and if you do not rebuild on each upstream release you are running a curl with known advisories, and there is no package manager to remind you. Third, distribution policy. Some environments have a rule that binaries must come from the distribution, and a build script that fetches and compiles sources will not satisfy that rule even when the code is identical. The alternative approach, in each case, is to use the distribution package where it exists, and to use curl's own static Windows builds for Windows. Where neither is possible, this project is a small, readable build recipe that produces the artefact you need without you having to become the person who maintains a curl fork.

Editorial conclusion

Adopt static-curl when you need one curl binary that runs on hosts where you cannot install libraries, such as minimal containers, embedded images or build sandboxes, and when you would rather not depend on a distribution's package versions. Do not adopt it if you want a curl that is patched for your platform's security advisories, since the build downloads upstream sources and follows upstream releases, and do not use the Windows builds from here, because the project states that static binaries for Windows come from curl itself. Before you pin a version, check that the release you download corresponds to the upstream curl release you want, and read build.sh to see exactly which configure options produced it.

Frequently asked questions

Official sources

1. License: MIT
2. moparisthebest/static-curl on GitHub
3. Project website
4. README
5. Releases