VaultSharp gives .NET teams typed access to HashiCorp Vault, minus the token plumbing

A typed client for Vault as an HTTP service

Vault is described in the project documentation as a secret management system built by Hashicorp as an Http Service. VaultSharp is the .NET side of that conversation: a library you reference from any .NET application to talk to a Vault server. It is described as a cross-platform C# library targeting .NET Standard 1.3, .NET Standard 2.0, .NET Standard 2.1, .NET Framework 4.5, 4.6.x, 4.7.x and 4.8, and .NET 5.0 through .NET 8.0, with implementations listed for .NET Core 1.x to 3.x, Mono 4.x and above, Xamarin.iOS 10.x and above, Xamarin Mac 3.x and above, Xamarin.Android 7.x and above, and UWP 10.x and above.

The library was re-designed from the ground up, the documentation says, to give a structured experience across auth methods, secret engines and system APIs, and the Intellisense on the IVaultClient interface is meant to carry much of that documentation in the editor.

The audience is application teams that have already decided to use Vault and want typed access rather than hand rolled HTTP calls. It is not a replacement for Vault itself, and it does not stand up a server.

Auth methods are a pluggable layer you can extend

Authentication is the first decision you make when you construct a client, and VaultSharp covers a long list of Vault auth methods: AppRole, AWS, Azure, GitHub, Google Cloud, JWT/OIDC, Kubernetes, LDAP, Okta, RADIUS, TLS, Tokens and UserPass. The client is configured with an auth method object and a set of client settings, and the settings object is also where you set proxies and custom delegates. The construction sequence in the quick start is short: choose an auth method, hand it to the settings along with the server URL, then create the client.

IAuthMethodInfo authMethod = new TokenAuthMethodInfo("MY_VAULT_TOKEN");
var vaultClientSettings = new VaultClientSettings("https://MY_VAULT_SERVER:8200", authMethod);
IVaultClient vaultClient = new VaultClient(vaultClientSettings);

The extension point matters more than the list. The documentation says you can bring your own auth method by providing a custom delegate to fetch a token from anywhere. That means an organisation with an internal credential broker can wire that in rather than forcing a stock Vault auth method on every service.

The type used in the quick start is IAuthMethodInfo, and the token method is instantiated with a token string. Pick the auth method before you construct settings, since the settings object takes it as an argument.

Reading a KeyValue secret with the mount point kept separate

The KeyValue engine is supported against both the v1 and the v2 APIs, and the client exposes them as separate surfaces. The v2 read takes a path and a mount point as two separate parameters, and the documentation is emphatic about this, with a note telling you not to pass a single combined string, and to use named parameters so the call reads clearly. The same method also takes version and wrapTimeToLive as parameters, which matters for v2 semantics where a secret can carry metadata alongside the data.

The result comes back wrapped in a typed Secret of SecretData, so the payload is a typed object rather than a raw string.

Secret<SecretData> kv2Secret = await vaultClient.V1.Secrets.KeyValue.V2
                               .ReadSecretAsync(path: "secretPath", mountPoint: "mountPointIfNotDefault");

This is where the library's value is clearest. Getting a v2 secret wrong usually means mixing up the mount point and the path, and the call signature makes that mistake hard to hide.

Dynamic Consul credentials come back as a typed object

The Consul secret engine is called out as having first class support in this library, and the quick start shows the shape of that call. You ask the Consul engine for credentials, and the result arrives as a Secret of ConsulCredentials, from which you take the token field.

Two arguments drive the call, the Consul role and the Consul mount. The documentation points readers at the Consul section under Secrets Engines for the full set of Consul related methods, which suggests the surface is broader than the single call in the quick start.

The same pattern applies across the other dynamic credential engines, which the feature list names as AD, AWS EC2 and IAM, Consul, Cubbyhole, Databases, Google Cloud, Key-Value, Nomad, PKI, RabbitMQ, SSH and TOTP. The general shape of a secret read is a typed method on a per-engine namespace, returning a generic Secret wrapper around a data type.

Token renewal is explicitly the host application's responsibility

Here the documentation is unusually direct. VaultSharp does not support automatic token refresh, and it is the responsibility of the host application to refresh the login token according to its expiry. The host app is free to call the ResetVaultToken method on the auth API from time to time, and the README shows that call as vaultClient.V1.Auth.ResetVaultToken().

There is a second escape hatch. The host app can re-initialize the entire VaultClient instance, and the documentation recommends that in cases where resetting the token alone may fail because the signature time is too old, which it names as an issue with AWS signatures.

That means a service consuming VaultSharp must own at least one piece of infrastructure that many clients hide: knowing when its credential expires and reacting before that happens. If your team has no scheduled background work in the application, this is the sharpest edge in the library.

Singleton or RequestScoped depends on how fast your token expires

The documentation spells out the dependency injection lifetime decision, and the reasoning is concrete. If the login token expiry is much longer than the deployment cadence of the application, the recommended lifetime scope for IVaultClient is Singleton, because it logs in to Vault once to get the auth token and reuses it for every subsequent call.

The Singleton lifetime fails in exactly one situation: when the login token expiry is shorter than the deployment cadence. Then you either write your own token renewal logic or use a RequestScoped lifetime. The documentation says renewal logic is the more performant of the two, because with request scoping VaultSharp would request a login token for every web request you handle.

The practical consequence is that the lifetime you pick encodes a policy decision about credential lifetime, and the two options differ in how much traffic they send to Vault.

No endpoint list, no round robin DNS

The other thing the client will not do for you is failover. The documentation states plainly that VaultSharp does not support built-in client side failover, either by accepting multiple endpoint URIs or by supporting round robin DNS, and it repeats the point for emphasis.

The client is therefore pointed at a single Vault URL, and the settings object takes one server address. If you run a Vault cluster behind a load balancer, that load balancer has to be the failover mechanism, because the library has no second address to fall back to and no DNS rotation logic of its own.

This is a reasonable simplification for many teams and a real constraint for others. Availability across Vault nodes is handled outside the client, and anyone evaluating the library should decide deliberately whether a load balancer in front of Vault is acceptable.

Licence, target frameworks and the release picture

VaultSharp is licensed under the Apache License 2.0, with the licence file in the repository root. Apache 2.0 is a permissive grant, so you can ship it inside a commercial .NET product without a separate commercial licence from the author, subject to the notice and attribution terms in the LICENSE file, and a patent grant that the licence text defines. That is a description of the licence terms rather than legal advice, and organisations with a formal review process should read the LICENSE file directly.

On maintenance, the repository is not archived and the last push was on 2026-08-17, a day after the v2.0.4.1-beta1 release on 2026-08-16. The two preceding stable releases, v1.17.5.1 and v1.17.5, came in September 2024, so the beta sits between a long stable line and a new major generation. The documentation also says the library will follow the published .NET end of life dates for the frameworks it targets, which is the rule that decides whether an old target such as .NET Framework 4.5 still matters for your build.

The repository holds a solution file, src and test directories, a CHANGELOG.md, a VaultSharpNugetPackages directory, and both a next.md and a NextTodo.txt that hint at the planned direction of the work.

Editorial conclusion

VaultSharp fits teams that already run Vault and want one typed client across every auth method and secret engine, on any .NET target the project still lists. It does not fit services that expect the library to renew tokens, retry across multiple Vault endpoints, or round robin DNS on its own, because the README says those are absent. Before adopting, check which target framework you are on against the listed .NET Standard, .NET Framework and .NET 5 to 8 targets, and read the section on dependency injection lifetime to decide whether Singleton or RequestScoped matches your token expiry.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. rajanadar/VaultSharp on GitHub
4. README
5. Releases