Thanks. I've installed certificates on our domain controllers, and now I can connect properly with LDAPS and login via my domain account.

Hi @parthu-reddy , I'm not sure if there's a relation here, but perhaps. The "running out of disk space" is not surpsing if you're indexing mega-repositories like the public debian repos. They are gigabytes in size. Here's some more info about those: https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds You definitely want to switch to Indexing Jobs when you connect to public repops. This can be set at operating system level (it's the %ProgramData% special folder) or in ProGet under Admin > Advanced Settings > LocalStorage. Anyway this is somethitng best brought up as a separate topic if you have follow-ups (if you don't mind), I'd hate to pollute this thread with debian/indexing questions :) Cheers, Alana

Hi @michael-day_7391 , I can't really comment on what you're seeing in the Artifactory logs (i.e. [1] and [2]), but when an Access Token is specified, that token is sent on requests via a Bearer authorization header (unless Use Legacy API Header is selected). Otherwise, the Username/Password are sent via a Basic header. This happens on each and every request, regardless of whether it's a file download, api call, etc. Probably just easier to disable authentication during the import if this keeps coming up. OCI Registries (i.e. what you're using for your Helm charts, as opposed to a regular Helm registry) are not supported, so you'd need to export those files and use disk-based import or something like that. Cheers, Alana

@atripp Ah, thanks, I did not read https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds well enough, my bad, sorry. I'll talk to DevOps about the update then. Thanks for the fast reply! Best, Frank

Hi @mikael , We plan to add this support via PG-3213 in an upcoming maintenance release -- perhaps Feb 20 if all goes well! Cheers, Alana

Hi @jonathan-simmonds_0798, Thanks for the suggestion! This has been a long-standing wish-list item, but it's deceptively complicated. The "current idea" is a feature called "raft analysis" that will create a list of all raft items that depend on other raft items. For example, a pipeline that references a script. Or, a script that calls a module, and so on. It could also detect warnings/errors and report them. Creating this list often involves opening thousands of files and "parsing" them, which is not a trivial operation... but we're only talking "a few minutes" in most cases. However, the main challenges arise with invalidating this list (many edits will cause that to happen), and then communicating the status of the rebuild to users. I'll add a note to our BuildMaster 2026 roadmap though and see if we can explore it again; the current focus is boring..... modernization (PostgreSQL). That said, you probably noticed it but.... you should be able to see if a particular pipeline has an error (like a missing script) on the piepline overview page. Not as nice. Thanks, Alana

Hi @parthu-reddy , At this time, we don't have a disk cleanup procedure for local storage like this; we may add it in the future, but for the time being you can just delete them. The LocalStorage folder is ephemeral -- not quite "temp" storage, but the contents can be deleted. They will just be recreated next time it's needed. Thanks, Alana

Thanks, that worked! We've had problems with this repo before as directory browsing isn't allowed due to the fact it's hosted on S3, so it breaks some software if you just put in the folder path. I guess ProGet is properly just appending the usual location of the repodata file instead of requiring the ability to browse the root folder.

Hi @koe , This is definitely a problem that you can solve with BuildMaster, but before giving any kind of technical guidance, I'd like to understand the business processes. On first glance, this sounds like one of two scenarios: Quasi-custom Software, where you create a customized build of a software application (perhaps bundled with their plugins, etc) User-driven Deployments, where you maintain a single application but deploy a new version of that application based on user requirements (new feature they requested, bug fix, etc) Are either of those close? Whatever the case, can you describe the decision-making process or rationale that goes into "deploy a software release to either all production systems, all test systems or just a single one out of all these systems?" Are there different types of releases (e.g. a "patch" release of an old version)? Or is everyone "forward only, latest version"? BuildMaster is, of course, an automation platform - but more importantly, it's about modeling process and visualization. And when it comes to process, consistency is key - even when there are variations. We don't believe a decision like above is "arbitrary, and based on the whims of an application director", but there's probably some rationale that goes into it. So, with BuildMaster, our goal is to help get everyone on the same page about which process to follow for different releases. Anyway, how you model this will have a big impact down the line. Cheers, Alana

Hi @Nils-Nilsson , Good news - this is actually on our ProGet 2026 roadmap. The general idea is to "reuse" Feed Groups -- I guess we'd call them "Feed & Project Groups" or something? Anyway, the projects would be grouped in the UI similarly, and you could scope project-based permissions to a group. We will try to get it as a preview feature in the coming weeks, assuming it can be done in low risk. It seems like this would be the case. Cheers, Alana

I have downloaded ProGet 2025.0.19 and was able to successfully change the location for that last setting. Thanks.

Hi @geraldizo_0690 , Thanks for the report! Sometimes bug fixes are a single character like this ... [image: 1769504251057-1c7d2a43-f6ca-41b0-9853-65cdea7cb5b7-image.png] It'll be be in the next maintenance release via PG-3205 :) Cheers, Alana

Hi, our Proget instance was updated to 2025.19 (Build 14) and the above described issue disappered. Excellent! Thanks!

Hi @davidroberts63 and @mikael , Thanks for the insight and ideas! I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run? Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me. Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;) I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on. Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file. Cheers, Alex

Thank you. Does it mean that I must stay with the SQL server version and do not migrate to the one with PostGres.

For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.

So I succeeded this time, I changed the montpoint to /data and created the subdirectories: mkdir -p /data/proget/proget-backups mkdir -p /data/proget/proget-database mkdir -p /data/proget/proget-packages Set correct permissions on the folders (same permissions as on the./proget-* folders) chmod 700 /data/proget/proget-database/ chmod 755 /data/proget/proget-backups/ chmod 755 /data/proget/proget-packages/ Set ownership chown 101:root /data/proget/proget-database/ chown root:root /data/proget/proget-backups/ chown root:root /data/proget/proget-packages/ Set correct SELinux context semanage fcontext -a -t svirt_sandbox_file_t "/data/proget(/.*)?" restorecon -Rv /data/proget Stop- and remove proget (I had a sapshot of the server as backup) docker stop proget docker rm proget rsync data to new directory rsync -avh ./proget-packages/ /data/proget/proget-packages/ rsync -avh ./proget-database/ /data/proget/proget-database/ rsync -avh ./proget-backups/ /data/proget/proget-backups/ Then install with (:z added for SELInux) docker run -d --name=proget --restart=unless-stopped \ -v /data/proget/proget-packages:/var/proget/packages:z \ -v /data/proget/proget-database:/var/proget/database:z \ -v /data/proget/proget-backups:/var/proget/backups:z \ -p 8624:80 \ proget.inedo.com/productimages/inedo/proget:25.0.18 last, remove the old directories in root home folder after ensuring everything is OK. cd ~ rm -rf ./proget-packages ./proget-database ./proget-backups Now it works as expected. i don't know what I did wrong last time, but now proget isn't filling up the root directory anymore. probably obvious for everyone used to docker, but wasn't for me :)

Hey Alana, No worries. I have a similar issue with an Ansible deployment in Kubernetes with permissions. So I have a special file share now for images that don't support changing the user/group that processes run as. Basically, the file share exposed and consumed by the image is configured (when using squashing) to have certain permissions. And we can make docker containers or Kubernetes deployments compatible by specifying the securityContext to tell it when user & group to run the pod as, or some containers allow specifying a user ID and group ID as environment variables. This is just to control the linux permissions for folder/file access. Somewhere in the image setup, there's configuration forcing it to access /var/proget/database as the user "postgres" and with the group "root", and it tries changing permissions on that folder at some point. If the image supported the securityContext or the user/group ID environment variables, it would run as those specified permissions instead - but - your image would need to be able to run as those permissions, and it would probably take some work to get the image reconfigured to allow that, and to do testing. For now, it works. It would take some evaluation to see if your image would support changing the user/group away from the current postgres/root.

Yes , it is indeed npm packages, yes I was using /packages. Though when traying to search within /feed it was also strange as it seems to ignore @ . Both are okay for now. Just put it somewhere in the improvement list, I understand there is some limitation to it, encoding, filter etc and trying to do universal search across different type.

Hi @jw , We added "auto-publish Inedo.ProGet" to our internal tracking list -- and in theory it will be done in the next week or so. I think we meant to do that earlier but it just fell off the list. Thanks for pointing that out - please don't hesitate to bug us if you don't see it published next time :) Thanks, Alana