vcpkg's README is a copy, its ports compile from source, and its tags are dates

The README here is a copy of a file in the docs repository

The first thing in the README is an HTML comment, and it is the most operationally important line in the file. It says the document is a copy of the README file on the Microsoft/vcpkg-docs repository, and that to make changes you should modify that file instead, with a link to vcpkg-docs and a path inside it.

So the repository you clone to get the ports is not where the README is authored. A pull request that fixes a sentence in README.md here changes a copy that will be overwritten. Documentation work goes to the other repository.

That split is visible in the layout as well. The top level holds ports/, triplets/, versions/, scripts/, docs/, toolsrc/, the two bootstrap scripts, and a set of files that are worth reading as a group: .vcpkg-root, the marker that identifies a directory as a vcpkg root, CodeQL.yml, SECURITY.md, AGENTS.md, CLAUDE.md, LICENSE.txt and NOTICE.txt.

The localised files are the detail I would not have predicted. CONTRIBUTING_pt.md, CONTRIBUTING_zh.md and NOTICE_pt.txt sit in the root, so contributions and the notice have been translated in place rather than kept on a separate site. If you are the kind of project that keeps documentation in one place, this is a useful thing to know before you decide where your own changes go.

Ports compile from source, which is why firewalls get a section

The Security section is short and it explains the single most important operational fact about this tool. Most ports build their library using the original build system preferred by that library's own developers, and they download both the source code and the build tools from the libraries' official distribution locations.

Read the consequences rather than the reassurance. An install is a build, so it needs a compiler and it needs network access to every dependency of every port you selected. Behind a firewall, the README says plainly that the specific access needed depends on which ports are being installed, which means your allowlist is a function of your dependency list and has to be regenerated whenever that list changes.

The air-gapped case has a documented answer, and it is a two-stage process. Install once in a non-air-gapped environment, then populate an asset cache and share that cache with the isolated environment. That is the mechanism asset caching exists for, and it is the one to reach for when the network is the constraint rather than the CPU time.

The other consequence is worth stating plainly: there is no binary-only mode in this design. A port that takes twenty minutes to compile takes twenty minutes on every machine that installs it, which is what binary caching is for, and what the next section is about.

Two caches that solve different problems, and it is easy to mix them up

The key features list names five things, and two of them are caches that sound alike and are not. One is reuse your binary artifacts, which is binary caching: the compiled output of a port is stored and reused, so a second machine or a clean build tree does not have to compile the library again.

The other is enable offline scenarios with asset caching. Assets are the downloaded things: source archives and build tools. Caching them means the install does not have to reach the network, which is what makes the air-gapped workflow in the previous section possible.

The distinction matters when you design a build system around it. Binary caching solves build time on a network you already have. Asset caching solves the absence of a network. If you configure only the first, a clean machine inside your firewall still fails; if you configure only the second, every clean build still recompiles everything.

The other three features are the ones you meet first: build system integration, version control over your dependencies, and the ability to package and publish your own ports, which is how a private registry is built.

Manifest mode and classic mode are different workflows, not different syntax

There are two ways to ask vcpkg for a library, and the difference is where the dependency list lives.

The manifest workflow creates a manifest in your project and then adds ports to it:

vcpkg new --application
vcpkg add port fmt

The classic workflow is a single install command with no project file involved:

vcpkg install fmt

Both reach the same registry, and the README links a page for each. What changes is where the answer to "what does this project depend on" is stored. In manifest mode it is a file in your repository, so it is reviewed in a pull request, diffed, and pinned by a reviewer. In classic mode it is whatever was typed into a shell, which means the dependency set of a build is not something a colleague can read without being told.

For a team, that difference is the whole decision. If you want dependencies to be reviewable, use a manifest. If you are experimenting on one machine, the single command is faster and there is nothing to clean up afterwards.

For the commands themselves, the README's advice is that vcpkg help gives a short description of all available commands and vcpkg help [topic] gives detail on one, which is where to look rather than guessing at flags.

The licence of what you install is not the licence of vcpkg

The license section draws a line that is easy to skim past. The code in the vcpkg repository is MIT licensed. The libraries provided by ports are licensed under the terms of their original authors. And where available, vcpkg places the associated licence or licences at a specific path inside your install tree: installed/<triplet>/share/<port>/copyright.

That path is the operative detail. Compliance for a given dependency is answered by a file in your own installed tree, named by triplet and port, and not by anything in the vcpkg repository or its documentation. If you need a licence inventory for a release, you are reading that directory, and for any port where the file is absent you have to go back to the library's own project.

The triplet in that path is also the identifier for a target configuration, since it is the directory level between installed/ and share/. The triplets/ directory at the top of the repository is where those definitions live, next to versions/ for the version database and ports/ for the packages themselves.

The practical consequence for a build: a vendored or redistributed binary carries the licences of everything inside it, and the MIT notice on the tool says nothing about those.

Three ways to turn telemetry off, and the one that survives CI

vcpkg collects usage data, the data collected by Microsoft is described as anonymous, and there are three documented opt-outs. You can run the bootstrap-vcpkg script with -disableMetrics. You can pass --disable-metrics to vcpkg on the command line. Or you can set the VCPKG_DISABLE_METRICS environment variable.

The shape of those three tells you which one matters. The bootstrap flag affects the install step, and only the install step, so it says nothing about a machine that was provisioned elsewhere. The command-line flag has to be typed on every invocation, which means every script, every CI step and every developer's muscle memory.

The environment variable is the one to set. It is inherited by everything the job runs, it survives the difference between a fresh checkout and an already-bootstrapped tree, and it is a single line in your CI configuration rather than an edit to a dozen command lines. If your organisation has a policy on outbound telemetry from build agents, this is the setting that satisfies it.

The README points to a privacy page on Microsoft Learn for the detail of what is collected, which is where to go if the question is what the data contains rather than how to stop it.

The tool's source lives in a second repository, and the tags are dates

The resources section splits the project in two, and the split is easy to miss. Ports are in microsoft/vcpkg, which is this repository. The source code of the tool itself, meaning the vcpkg executable you type, is in microsoft/vcpkg-tool. Documentation is on Microsoft Learn, and the website is vcpkg.io.

So pinning a vcpkg release pins two moving parts that live in different repositories: the tool build produced by the bootstrap scripts in this tree, and the port and version database that this tree carries. They are released together by date, which brings us to the version scheme.

The release tags are dates. The three most recent are 2026.07.29, 2026.06.24 and 2026.06.01, published on 2026-07-31, 2026-06-26 and 2026-06-04. There is no major, minor and patch triple to compare, so you cannot say a release is a patch or a minor, and a diff between two tags tells you which day each was cut rather than what changed in between.

The last push to this repository was on 2026-09-27, two months after the most recent release. The default branch is master, so master carries port and version changes that no tag contains. For a reproducible build, install a release; for the tool, the cross-platform answer to the common Windows-only question is the two bootstrap scripts, bootstrap-vcpkg.bat and bootstrap-vcpkg.sh.

Editorial conclusion

vcpkg fits C++ teams that want dependency versions reviewable in their own repository and accept compiling from source, and manifest mode with the CMake or MSBuild integration is the workflow to adopt. Set VCPKG_DISABLE_METRICS in CI before anything else, since the other two opt-outs are per-invocation and the bootstrap flag only applies at install time. Plan your firewall allowlist from your port list, because each port downloads source and build tools from that library's own distribution location, and for an isolated network budget for a two-stage asset cache populated elsewhere. Do not file README corrections against this repository, since the file is a copy maintained in microsoft/vcpkg-docs, and do not read installed libraries as MIT, because the licence of every port belongs to its original authors and the file to check is installed/<triplet>/share/<port>/copyright.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/vcpkg on GitHub
4. README
5. Releases