azure-sdk: the parent repository of the Azure client libraries
This is the Azure SDK parent repository and mostly contains documentation around guidelines and policies as well as the releases for the various languages supported by the Azure SDK.
At a glance
- What is it?
- The Azure/azure-sdk repository holds no client code of its own. It is the index of the language SDKs, the place where the design guidelines and review policy live, and the map from a service to the package you install.
- Who is it for?
- Use azure-sdk when you need to know which language repository or package to install for an Azure service, or when you are writing a client library that must pass the architecture review. Do not look for source code here, since the client libraries live in the per-language repositories, and read the terminology section before you assume an SDK and a package mean the same thing.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly PowerShell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A jumping off point, not a library
The first line of the README sets expectations. This is the Azure SDK parent repository, and it mostly contains documentation around guidelines and policies as well as the releases for the various languages supported by the Azure SDK. The source for the client libraries exists for the most part in repositories for each language, so this repository is a jumping off point into those language specific repositories. If you arrive here looking for the client for a service, you will not find it. What you will find is a table with a row per language, and each row links to the design guidelines for that language, the packages, the repository and the documentation. That table is the actual product, a map from the Azure service surface to the artefacts a developer installs, and it also tells you how mature each language's guidelines are.
Draft guidelines mark which languages are still moving
The language table has eleven rows and it carries a status marker for the guidelines. General, .NET, Java, JavaScript, Python and Rust have design guidelines that are not marked as draft, while the Android, Go, C, C++ and iOS entries are all labelled as Draft. That difference is not cosmetic. A draft guideline is a document that is still moving, so code written against it may need to change, while a settled one is a contract a client library author can rely on. The documentation column is its own kind of signal. .NET, Go, C, C++, Java, JavaScript and Python all link to documentation pages, whereas Android, iOS and Rust are marked as Coming Soon, which tells you where to look for reference pages before you file an issue. Rust is the interesting case in that list, since its guidelines are settled while its documentation is not yet published.
SDK, Client Library and Package are not synonyms
The terminology section exists because the three words are used loosely in conversation and the SDK team wants them separated. An SDK is the entire Azure SDK for a single language, itself broken up into numerous client libraries. A client library is a library, with associated tools, documentation and samples, that customers use to work with an Azure service, and there is often one per service per language, though sometimes a single client library covers several services. A package is a client library once it has been packaged for distribution, with the format chosen by the ecosystem: a NuGet package for .NET, a Maven package for Java, an npm package for JavaScript, a Python wheel for Python, a Go module for Go and a Crate for Rust. Each client library is published separately to the appropriate language specific package repository, and developers consume each one separately as needed for their use case. If you have ever wondered whether a service ships one package or a family of them, this is where the answer is defined.
Releases come from the engineering systems team
One sentence in the terminology section settles how versions happen. The releases are performed exclusively by the Azure SDK engineering systems team. That is the reason a client library does not carry hand-written changelog entries and version bumps in the usual way, and it is a meaningful difference for anyone who expects to cut a patch to a client library in their own fork. The repository keeps the release artefacts under a releases directory alongside the documentation site sources, and there are no GitHub releases attached to this repository itself, so the version history of the individual packages lives in the per-language package repositories rather than here. The top level also carries an unknown-metadata-fixes-report.md file, which gives a hint about the operational side of keeping package metadata consistent across a large matrix of services and languages.
New client libraries pass an Architecture Board review
The governance is short and explicit. Service teams should schedule reviews of their client libraries with the Azure SDK Architecture Board, and the review process is documented separately from the design guidelines. That single sentence implies a lot. A service team cannot simply publish a client library in the shape it prefers; it goes through a review, which is what keeps the Azure surface consistent across the supported languages even though the code lives in a separate repository per language. If you are building a client library for a service that does not have one, this repository is where you start, and the review is the gate you have to plan for rather than discover late. The review process page is linked from the README alongside the general design guidelines, and both are published under the same azure.github.io site.
The documentation site is generated from this repository
The layout of the top level explains the rest. There is a _config.yml, _data, _includes, _layouts and _posts directory, a Gemfile and Gemfile.lock, feed.xml, search.json and a sitemap.xml, which is the shape of a Jekyll site, and the documentation pages are published at azure.github.io/azure-sdk. A docs directory holds the guideline pages themselves, and the same directory contains the azuresdkspecs folder, which is where the service specifications live. Those specifications are the source of truth for what a client library should expose for a given service, which is why a new client library cannot be designed purely by reading an existing one. Beside the site sources sit engineering directories, eng, plus a .devcontainer folder, .vscode settings, a SECURITY.md file and a .ruby-version file. The primary language recorded for the repository is PowerShell, which reflects the scripts that drive the release and metadata tooling rather than any client code.
Contributions run through a CLA, and issues are routed by scope
Two contribution rules are worth knowing before you open a pull request. Most contributions require you to agree to a Contributor License Agreement declaring that you have the right to grant the rights to use your contribution, and when you submit a pull request a CLA bot automatically determines whether you need to provide one and decorates the pull request with a label or comment, so you only need to do this once across all repositories using the CLA. The project has also adopted the Microsoft Open Source Code of Conduct. Routing is the other thing to get right. Issues related to a specific language should be opened in the corresponding language repository, while cross cutting issues can be opened here, so a question about Python client behaviour belongs in the Python repository and a question about the shared guidelines belongs in this one. The repository is MIT licensed, its last push was on 2026-10-22, and it is not archived.
Editorial conclusion
Use azure-sdk when you need to know which language repository or package to install for an Azure service, or when you are writing a client library that must pass the architecture review. Do not look for source code here, since the client libraries live in the per-language repositories, and read the terminology section before you assume an SDK and a package mean the same thing.
Frequently asked questions
Where do I find the Azure client library source code?
In the per-language repositories. The Azure/azure-sdk repository is a jumping off point that links to each language repository, its design guidelines, its packages and its documentation, and issues about a specific language should be opened in that language's repository.
What is the difference between an SDK, a client library and a package?
An SDK is the whole Azure SDK for one language, made of many client libraries. A client library is what developers use to work with an Azure service. A package is that client library packaged for distribution, as a NuGet package, Maven package, npm package, Python wheel, Go module or Rust Crate.
How are Azure SDK client libraries reviewed and released?
Service teams schedule reviews of their client libraries with the Azure SDK Architecture Board, and the releases are performed exclusively by the Azure SDK engineering systems team rather than by the individual service teams.
Which Azure SDK languages have draft design guidelines?
The Android, Go, C, C++ and iOS design guidelines are marked as Draft, while General, .NET, Java, JavaScript, Python and Rust are not. Documentation is marked Coming Soon for Android, iOS and Rust.
Do I need to sign a CLA to contribute to the Azure SDK?
Most contributions require agreeing to a Contributor License Agreement, and a CLA bot checks for it automatically and labels the pull request accordingly. You only need to do it once across all repositories using the CLA.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/azure-azure-sdk)Was this useful?