<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[ProGet: Strategies for (more) flexible feed naming]]></title><description><![CDATA[<p dir="auto">Hi all,</p>
<p dir="auto">I'm currently setting up a new ProGet instance, migrating from a relative large instance with a few "catch all" feeds, to a new install with a more granular set of feeds. Ideally, I'd like to implement consistent set of URL patterns, including possible forms of 'namespacing' for multiple tenants, and clear separation between repository types (including in paths). We use CI/CD heavily to validate e.g., registry usage; so being able to create some consistent patterns would be great.</p>
<p dir="auto">Based on the current options and documentation, I understand that the following patterns apply (by default);</p>
<ul>
<li>single "URL segment" feed name, no urlencodable characters (i.e., no <code>/</code> allowed)</li>
<li>always prefixed with a feed type, though depends on the feed type, e.g.;
<ul>
<li><code>nuget</code> for NuGet, PowerShell, Chocolatey</li>
<li><code>helm</code>, <code>npm</code>, etc. for their respective package managers</li>
<li>Docker has no path prefix</li>
</ul>
</li>
<li>alternate names can be defined, but have the same restrictions</li>
</ul>
<p dir="auto">This can lead to somewhat restrictive and sometimes confusing feed URLs (e.g., the <code>debian</code> prefix being used for general apt-compatible systems, the Docker feeds having no prefix at all).</p>
<p dir="auto">I'm therefore wondering if there are alternative strategies to allow more flexible feed naming? Possibly via internal configuration or otherwise?</p>
<p dir="auto">One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names. e.g.,;</p>
<ul>
<li><code>proget.org.com/ps/tenant-a</code> to <code>proget.org.com/nuget/ps-tenant-a</code><br />
or</li>
<li><code>proget.org.com/docker/tenant-a</code> to <code>proget.org.com/docker-tenant-a</code></li>
</ul>
<p dir="auto">I would love to head your thoughts.</p>
<p dir="auto">Best,<br />
Cyril</p>
]]></description><link>https://forums.inedo.com/topic/5792/proget-strategies-for-more-flexible-feed-naming</link><generator>RSS for Node</generator><lastBuildDate>Mon, 06 Jul 2026 23:52:46 GMT</lastBuildDate><atom:link href="https://forums.inedo.com/topic/5792.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 03 Jul 2026 12:58:07 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to ProGet: Strategies for (more) flexible feed naming on Fri, 03 Jul 2026 12:58:07 GMT]]></title><description><![CDATA[<p dir="auto">Hi all,</p>
<p dir="auto">I'm currently setting up a new ProGet instance, migrating from a relative large instance with a few "catch all" feeds, to a new install with a more granular set of feeds. Ideally, I'd like to implement consistent set of URL patterns, including possible forms of 'namespacing' for multiple tenants, and clear separation between repository types (including in paths). We use CI/CD heavily to validate e.g., registry usage; so being able to create some consistent patterns would be great.</p>
<p dir="auto">Based on the current options and documentation, I understand that the following patterns apply (by default);</p>
<ul>
<li>single "URL segment" feed name, no urlencodable characters (i.e., no <code>/</code> allowed)</li>
<li>always prefixed with a feed type, though depends on the feed type, e.g.;
<ul>
<li><code>nuget</code> for NuGet, PowerShell, Chocolatey</li>
<li><code>helm</code>, <code>npm</code>, etc. for their respective package managers</li>
<li>Docker has no path prefix</li>
</ul>
</li>
<li>alternate names can be defined, but have the same restrictions</li>
</ul>
<p dir="auto">This can lead to somewhat restrictive and sometimes confusing feed URLs (e.g., the <code>debian</code> prefix being used for general apt-compatible systems, the Docker feeds having no prefix at all).</p>
<p dir="auto">I'm therefore wondering if there are alternative strategies to allow more flexible feed naming? Possibly via internal configuration or otherwise?</p>
<p dir="auto">One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names. e.g.,;</p>
<ul>
<li><code>proget.org.com/ps/tenant-a</code> to <code>proget.org.com/nuget/ps-tenant-a</code><br />
or</li>
<li><code>proget.org.com/docker/tenant-a</code> to <code>proget.org.com/docker-tenant-a</code></li>
</ul>
<p dir="auto">I would love to head your thoughts.</p>
<p dir="auto">Best,<br />
Cyril</p>
]]></description><link>https://forums.inedo.com/post/19844</link><guid isPermaLink="true">https://forums.inedo.com/post/19844</guid><dc:creator><![CDATA[gbeckett]]></dc:creator><pubDate>Fri, 03 Jul 2026 12:58:07 GMT</pubDate></item><item><title><![CDATA[Reply to ProGet: Strategies for (more) flexible feed naming on Fri, 03 Jul 2026 15:12:56 GMT]]></title><description><![CDATA[<p dir="auto">Hi <a class="plugin-mentions-user plugin-mentions-a" href="https://forums.inedo.com/uid/3873">@gbeckett</a> ,</p>
<p dir="auto">There are Feed Names (which you can configure) and API endpoints (which you cannot configure).</p>
<p dir="auto">Our general guidance on feed names is <code>internal-nuget</code> or <code>public-nuget</code>, but we've seen cases where a lot of feeds are needed. I suppose tenant namespace like <code>tenant1-nuget</code> might work too. But like naming of everything else, you'll figure it out as you go.</p>
<p dir="auto">While you can't change API endpoints, you could use the alternative <code>/endpoints</code> url if you really wanted. So instead of <code>/nuget/public-nuget</code> it would be <code>/endpoints/public-nuget</code>. Honestly I wouldn't bother... it's just a URL that no one really sees, and that's actually going to make it more of a pain to support. That's why we don't expose this.</p>
<p dir="auto">Some ecosystems (like Docker) only support one registry per domain/port, which is why Docker feeds have no prefix. We work-around this by using namespaces.</p>
<blockquote>
<p dir="auto">One option I'm considering is layer a proxy in front of ProGet, to provide the URL rewriting to map to ProGet-compatible names.</p>
</blockquote>
<p dir="auto">Please don't do this :) We do not recommend nor do we support URL rewriting like this. People have figured out how to do it, but it causes lot of headaches and it will be painful to debug. Which is why we don't support it. Again... it's just a URL that no one really sees after you enter it.</p>
<p dir="auto">Hope that helps!</p>
<p dir="auto">Thanks,<br />
Steve</p>
]]></description><link>https://forums.inedo.com/post/19845</link><guid isPermaLink="true">https://forums.inedo.com/post/19845</guid><dc:creator><![CDATA[stevedennis]]></dc:creator><pubDate>Fri, 03 Jul 2026 15:12:56 GMT</pubDate></item><item><title><![CDATA[Reply to ProGet: Strategies for (more) flexible feed naming on Mon, 06 Jul 2026 09:10:06 GMT]]></title><description><![CDATA[<p dir="auto">Thanks for the tips. That Docker constraint is particularly good to know, I hadn't realized!</p>
<p dir="auto">We do have a rather large amount of feeds to manage, including a (growing) set of feeds we use as local mirrors. I'll see if we can find an alternative solution that works for us...</p>
]]></description><link>https://forums.inedo.com/post/19847</link><guid isPermaLink="true">https://forums.inedo.com/post/19847</guid><dc:creator><![CDATA[gbeckett]]></dc:creator><pubDate>Mon, 06 Jul 2026 09:10:06 GMT</pubDate></item></channel></rss>