We are migrating Pega Robotics from 19.1.83 to 22.1.41 and we need to configure a repository on Pega Cloud, according to a few files that we have been reading when selecting a Filesystem type we have this two options:
Map a network drive
UNC approach
Either option used we need to grant with read/write access to everyone; we have a couple of questions regarding this:
Is there a way to only grant access to specific user to create and stablished this connection?
Is there a way of after grant this read/write access restrict the access to other users in AD with a policy in order to proctect the repository?
Is there any workaround to prevent or restrcit the access to other users in the network in order they can’t access the repository and only Pega can stablished the connection?
To secure your Pega Robotics repository using a UNC path or mapped drive, the best approach is to create a dedicated service account (like a bot user) and give only that account read/write access to the shared folder. Don’t use “Everyone” or broad permissions. On the folder, remove access for all other users and restrict it using NTFS or Active Directory settings. If needed, use group policies to block access from other users or machines. You can also set up firewall rules so only your Pega Runtime machine can talk to the share. This way, only Pega can connect, and no one else in your network can browse or write to it. It keeps the setup clean and secure without exposing the repo to everyone
As you have said we can configure a service account in order to grant access to it, is there any configuration that has to be done on Pega Cloud? because this repository will be configure in it to maintain the Package Binaries.
If we create a Service Account and restrict the access as per said Pega Cloud could be able to setup the repository and connect without any issues? is there any documentation or examples regarding this type of configuration that we can search?
You can’t use a UNC path or mapped drive as a repository in Pega Cloud because Pega Cloud doesn’t support direct access to your internal network shares. Instead, you should use an S3-based repository either your own AWS S3 bucket or the Pega-provided cloud storage. In that case, you can create a service account (IAM user) with limited permissions to access only that bucket. Then in Pega, you configure the repository rule with the access key and secret. This lets Pega connect securely and only that service account will have access. No UNC or network drive setup is needed on Pega Cloud. Let me know if you want help setting up the S3 policy or Pega config screen.
Ok, thank you very much for your insights and knowledge. I understand that for Pega Cloud the best is to use a Cloud to define the repository.
Attached you’ll find a document that we search and review from another post and we were wondering if the sheet 4.1 talking about setting a Repository based on filesystem storage is not possible anymore? or is not the best approach, Pega doesn’t recommend this type of repository?
Yes, Sheet 4.1 in your document refers to setting up a repository using a filesystem-based approach, but that method is only valid for on-premise or self-managed environments, not for Pega Cloud.
Pega Cloud environments are isolated for security and scalability reasons, and do not support direct access to file systems, UNC paths, or mapped drives. While the method in Sheet 4.1 might still work for legacy or development setups running outside the Pega Cloud, it is not recommended and will break in Pega Cloud especially as Pega phases out all local file system access in favor of repository APIs like S3 or Pega Cloud File Storage.
So, what you saw in the document is technically accurate for certain use cases, but not applicable or supported in a modern Pega Cloud deployment. Stick with S3 or Pega-provided storage for anything running on Pega Cloud.
Thanks for your explanation, Could you please explain how we need to set up the S3 there are any configuration that we need to take into consideration? Also in Pega there anything we need to keep in mind?