Sleet

A static NuGet package feed generator. ☁️ + 📦 = ❄️

Sleet creates and updates NuGet v3 feeds as static files on Azure Blob Storage, Amazon S3, S3-compatible storage, or a local folder. NuGet clients restore packages straight from those files, so there is no server to run.

Documentation: emgarten.github.io/Sleet

Table of Contents

• Sleet
  • Table of Contents
  • Features
  • Why use static feeds?
  • Getting Sleet
    • Install as a dotnet global tool (recommended)
    • Install as a local tool
    • Run without installing
    • Sleet.exe for Windows
    • Using SleetLib as a library
  • Quick start
  • Commands
  • Documentation
  • Contributing
  • History
    • How was sleet named?
  • Related projects
  • License

Features

• Serverless. Create static feeds directly on Azure Storage, Amazon S3, or any S3-compatible storage (Cloudflare R2, MinIO, Backblaze B2, etc.). No compute required.
• Cross platform. Sleet is built in .NET and runs on Linux, macOS, and Windows.
• Fast. Static feeds use the NuGet v3 feed format so clients resolve packages with simple HTTP requests.
• Simple. A straightforward command line tool to add, remove, and update packages.
• Flexible. Configure credentials via files, environment variables, command line args, .netconfig, or AWS-specific patterns to fit any workflow.
• Symbol server. Serve .pdb files to debuggers from the same feed. See symbol server.
• Package retention. Automatically prune old package versions with configurable stable/prerelease limits and release label grouping. See package retention.
• Version badges. Generate shields.io-compatible version badges for your packages.
• External search. Plug in a custom search endpoint for dynamic query results.
• Cache control. Set CDN-friendly Cache-Control headers for immutable and mutable feed files. See CDN and caching.

Why use static feeds?

• Package binaries are typically kept outside of git repos — static feeds provide a long term storage solution that can be paired with checked in code.
• NuGet feeds are read for restore far more often than they are updated.
• Cloud storage accounts are a cheap and secure way to share nupkgs for public or private feeds.
• You keep full control of your packages.

Getting Sleet

Sleet requires the .NET 8 SDK or later. See Install Sleet for all options.

Install as a dotnet global tool (recommended)

dotnet tool install -g sleet

sleet should now be on your PATH.

In CI scripts, pin a major version so a new major release can't change your build unexpectedly:

dotnet tool install -g sleet --version "7.*"

Install as a local tool

A local tool manifest pins an exact Sleet version for a repository:

dotnet new tool-manifest
dotnet tool install sleet

Commit the dotnet-tools.json file it creates, then run dotnet tool restore and use dotnet sleet.

Run without installing

With the .NET 10 SDK or later, dnx downloads and runs Sleet in one step:

dnx sleet createconfig

Sleet.exe for Windows

The SleetExe package contains a self-contained Sleet.exe for Windows x64 that doesn't need .NET installed.

1. Download the latest SleetExe nupkg from NuGet.org.
2. Extract tools/Sleet.exe to a local folder and run it.

Using SleetLib as a library

Install the SleetLib NuGet package to access Sleet functionality programmatically from your own .NET applications. See SleetLib.

Quick start

Create a feed on Azure Storage in three steps:

# 1. Generate a config file
sleet createconfig --azure

# 2. Edit sleet.json with your storage account URL and credentials

# 3. Push packages (the feed is created automatically on first push)
sleet push mypackage.1.0.0.nupkg

Then add the feed's index.json URL as a package source in NuGet. See Use a feed with NuGet.

For other storage backends see the documentation.

Commands

See commands for full details and options.

Documentation

The documentation is published at emgarten.github.io/Sleet. The source files are in /doc.

Get started:

• Install Sleet
• Create an Azure feed
• Create an Amazon S3 feed
• Create a Cloudflare R2 feed
• Create a local feed
• Use a feed with NuGet

Guides:

• Azure authentication and AWS authentication
• Publish from CI
• Private feeds, including a private feed on AWS with S3, CloudFront, and Lambda@Edge
• S3-compatible storage, web servers and static hosting, CDN and caching, and multiple feeds
• Package retention and backup and migration

Reference and help:

• Commands, configuration, environment variables, and feed settings
• How Sleet works, feed locking, and limitations
• Troubleshooting and FAQ
• Release notes

Also see this getting started blog post for a walkthrough.

Contributing

We welcome contributions! If you are interested in contributing to Sleet, report an issue or open a pull request to propose a change. See CONTRIBUTING.md for how to build, test, and preview the documentation.

To build and run the unit tests locally:

# Linux / macOS
./build.sh

# Windows
./build.ps1

The functional tests run against Azure Storage and Amazon S3. By default, they run against local emulators in Docker, so you don't need a cloud account:

# Linux / macOS
./functional-tests.sh

# Windows
./functional-tests.ps1

See functional tests to run them against real accounts.

CI runs on Linux, macOS, and Windows.

History

Sleet was created to achieve the original goals of the NuGet v3 feed format: provide maximum availability and performance for NuGet restore by using only static files.

The v3 feed format was designed to do all compute when pushing a new package since updates are infrequent compared to the number of times a package is read for restore. Static files also remove the need to run a specific server to host the feed, allowing a simple file service to handle it.

How was sleet named?

Sleet is.. cold static packages from the cloud. ☁️ + 📦 = ❄️

Related projects

• Sleet.Azure provides MSBuild props/targets for running Sleet.
• Sleet.Search provides a search service for Sleet feeds.

License

MIT License