Extend custom_property limits

[etiennej70]

Select Topic Area

Product Feedback

Body

Hello,

We are trying to link our repositories to our internal software component catalog. Each component has a unique UUID, and we want to store these UUIDs in a custom_property on the corresponding repository.

Our goal:

• Associate one or more component UUIDs with each repository.
• Use this link to sync metadata (e.g., owning business unit) from our catalog to other custom properties.
• Enforce repository rulesets based on this synced metadata.

The problem:

Our use case is blocked by the current limitations, especially for our monorepos which contain many components:

• Scale: We have thousands of component UUIDs, but a multi-select property is limited to 200 options.
• String Length: A string property value is too short (75 characters) to store the UUIDs for a monorepo (one UUID is 36 characters).

Our proposition:

• Extend the limit length of the string custom_property to 1024
• Extend the limit to multi-select available options to 20 000

BR,
Etienne

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[sanatan0511]

Increase the string property length to 1024 and the multi-select options to 20,000. This allows storing and linking thousands of component UUIDs per repository, enabling metadata sync and rules enforcement at scale.

This is quite common I also face this.Current constraints pose real challenges for mapping of components, and your proposals make sense — especially as internal system integrations become more common.Also please report the same to GitHub also I do but if many do make things become so simple.I hope I answer your question :)

[teshcodes]

Hi Etienne 👋

​This is a fantastic use case, and you've clearly identified the scaling bottlenecks with Custom Repository Properties for large environments and monorepos. You are not alone in hitting these walls!
​The current limits—especially the 75-character string value and 200-option multi-select—make it nearly impossible to link repositories to a high-volume component catalog (where one UUID alone is 36 chars).

​Short-Term Workaround: External Mapping

​While we wait for GitHub to expand these limits:
​The most reliable workaround is to store a single, short reference key (like a catalog_id or monorepo_key) in the custom property. Your internal system can then use this single key to look up the full list of component UUIDs. This keeps the GitHub property lightweight and scalable.

​Support for Your Proposal

​Extending the string limit (e.g., to 1024 characters) and the multi-select limit (e.g., to 20,000 options) makes perfect sense for enterprise governance and scale.
​I strongly encourage you to submit your proposal officially via the GitHub Feedback Discussions. That is where the Product team actively reviews feature requests like this one.
​Good luck!

[Aditya-Prakash14]

Hi Etienne,
Your use case highlights how scaling custom_properties could unlock major integration and rules automation for large monorepos and enterprise environments. Extending string property limits to 1024 and multi-select to 20,000 would help teams efficiently associate repository metadata at scale.

Current constraints pose real challenges for mapping thousands of components, and your proposals make sense — especially as internal system integrations become more common. In the meantime, workarounds (single catalog key reference, API mapping, sync via GitHub Actions) can help, but a true extension would be best for direct metadata storage and automation.

I hope GitHub prioritizes this feature for advanced users!