I wanted to exchange some experience regarding private NuGet feed hosting solutions.

We have used MyGet for years both for our private and public packages. But recently it became so unstable that it would not be responsible to not investigate the alternatives. I looked into Azure Artifacts first because, we already have Azure Devops and it comes free. The transition was mostly painless (I plan to write about it in more detail soon). But hosting public feeds doesn’t seem as easy. One needs to create a public project just for that. So, we still use MyGet for public feeds for now. But will move them also elsewhere.

What are your experiences with private feed hosting? Do you host them yourselves or use a paid service?

  • nibblebitA
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    Azure Artifacts has been great for private stuff. Have you tried Github packages yet? Works well enough for public packages. I don’t know what your use case is, but what prevents you from using nuget.org?

    • canpolatOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Have you tried Github packages yet?

      No. Thank you for the suggestion. We use Azure Devops, but I would expect it to have good integration with GitHub. But creating a public project in Azure Devops may make more sense (so that all packages are in one place).

      […] but what prevents you to use nuget.org?

      The only thing is possible name collisions. I didn’t start looking into this, but it is a possibility. Otherwise I think we will end up doing this.

      • nibblebitA
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Aah yes, naming collisions. I hadn’t considered that. I’m curious what kind packages you want to make available to the public are also prone to naming collisions that can be solved by a namespace convention. Are you publishing libraries, applications, VS extensions or templates?

        • canpolatOP
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          We are publishing libraries (mostly client libraries). There are lots of legacy stuff. It’s safer to own the whole feed instead of pushing it to nuget.org and hoping for the best :)

      • RonSijm
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        We use Azure Devops, but I would expect it to have good integration with GitHub.

        I also use Azure Devops + GitHub - What kind of integration are you looking for? I have my source in Github, and use Azure as build server

        If you’re using Azure as the build server, you can also publish your Nugets into a private feed in Azure

        • canpolatOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          I also use Azure Devops + GitHub - What kind of integration are you looking for?

          Not really “looking for” it but what I meant was “pushing to GitHub packages from Azure Pipelines.”

          If you’re using Azure as the build server, you can also publish your Nugets into a private feed in Azure

          That’s what we do at the moment for private feeds.

    • bignavy
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Wish I could upvote more than once. Azure artifacts has some fucky authentication requirements (cleartextpassword is the dumbest field I’ve ever heard of - especially since it’s not clear text or a password, it’s a base64ed PAT) but there’s plenty of first party support to make it less painful, and it’s a problem you only have to ‘fix’ once.

      Our prior solution was verdaccio for NPM and a shared drive location for Nuget, and….well, it beats the tar out of either of those. Being able to see exactly what’s in the feed, when it got there, who put it there….all grade a stuff. Handling SSO and such seamlessly is nice too, and being able to scope access with tons of granularity….well it seems like a rake waiting to be stepped on, honestly, but if you need to manage access it seems like a big win.

      Public feeds - yes. Why reinvent the wheel? Will be easier to find and use if it’s on nuget.org.

      If OP’s goal is to be able to source control all the public packages that their projects use, for security or peace of mind purposes (or to make it the sole source of packages to avoid dependency injection/confusion attacks)…there’s actually a feature of Azure Artifacts where you can pull packages from an ‘upstream’ like nuget.org and host public packages in a private feed. It’s got a gui, and it’s pretty convenient as far as such things go.

  • atheken
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago

    At my last job, we used sleet in combination with S3 and a cloudfront distribution with an authorization lambda for pulling packages. I think the whole setup took about 2 hours and it was rock solid.

    This was necessary because we were using Octopus Deploy and were bumping into storage limits with their built in feed.

    We were a relatively small team, and relatively slow package publish rate (10x a day, probably).

    Biggest issue with sleet is that it’s not going to support “pull through” so you’ll need to have multiple nuget feeds configured.

    • nibblebitA
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      ooh i haven’t heard of sleet that looks so neat.

      10 publishes a day? Is that slow? I’m at a 20 man team and we run up to about 10 a month. is your final product a suite of packages or are you like only using package references in your projects?

      • atheken
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        We had about 10-15 lambda “Microservices” each of these packaged up a service/contracts library to be consumed by other services that used them. We also had an MVC API and a few windows services that were built for a “distributed monolith”.

        We built all all branches on every push, we tried to deploy updates multiple times a week.

        We had 4 devs working on .net

        The main thing with sleet is that I made zero effort to prune anything from the feed, so eventually it might cost a few dollars per month for S3 storage, but it was literally zero maintenance after we got it set up.

  • LetMeThinkAboutIt
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    I would be really interested to hear/read your story as I am also investigating to use NuGet private feeds! I’m learning how to at the moment, as we aren’t using NuGet to distribute packages, yet.

    • canpolatOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      If you are not using Azure Devops, GitHub Packages (as suggested by @[email protected]) can be worth looking into. They have a generous free tier.