Feature ideas

Currently, the maximum number of entities returned by a search query rule when mapping relations is limited to 500. There is no built-in way to exceed this limit. Since 500 may be too low for certain use cases, it would be helpful to provide an option to increase this limit.

The port_search Terraform data source currently calls POST /v1/entities/search, which requires a property field in every rule. This means relation-based filter rules are not supported, and the following query fails with "rules/0" must have required property 'property': data "port_search" "pd_entities" { query = jsonencode({ "combinator" : "and", "rules" : [ { "relation" : "pagerduty_escalation", "operator" : "isNotEmpty" } ] }) } The blueprint-scoped endpoint POST /v1/blueprints/{blueprint}/entities/search does support relation-based rules (e.g. filtering by isNotEmpty on a relation field), but the port_search data source does not expose this endpoint. Requested change: Add support for relation-based filter rules in the port_search data source, either by: Exposing the blueprint-scoped search endpoint (/v1/blueprints/{blueprint}/entities/search) as an option in the data source, or Updating the global search endpoint to accept relation rules without requiring a property field. Use case: We need to find all entities across blueprints where a specific relation (e.g. pagerduty_escalation) is set (i.e. isNotEmpty). Today this requires a multi-step REST API workaround outside of the Terraform provider, which undermines the goal of managing Port infrastructure as code. Current workaround: Query /v1/blueprints to discover all blueprints that define the target relation. For each blueprint, query /v1/blueprints/{blueprint}/entities/search with a relation rule. This is brittle and forces us to bypass the Terraform provider entirely.

Regex validation used to run live for string inputs, which was a much better experience than waiting until action execution. We’d like to have live validation back, or a setting to toggle it on/off.

Some data models include blueprints such as CI/CD jobs or deployments. These blueprints usually get filled with high number of entities, but the entities in these blueprints become stale and lose relevancy very quickly. With this feature, users will be able to configure custom retention for specific blueprints, giving them the option to automatically delete old entities once the number of entities for the blueprint passes X entities, or if an entity was updated more than 1 week/month/year ago

As the data-model grows, the graph visualization looses value as it become more chaotic. Being able to save and label multiple views which support storing custom positions for the cards would be awesome. In addition, viewing blueprints by integration would be helpful, or even an N+1 relations kind of button where I can select a blueprint and hide everything but blueprints that relate directly to it.

Request to support one blueprint hosting millions of entities. While there is no hard limit on number of entities per blueprint, it is still not possible today to have millions of entities on one blueprint without performance issues.

This is not to add a data source to a schema registry elsewhere, but for Port to have inbuilt functionality to detail and manage a schema registry. This would be useful because it can then directly hook into other components in Port across the estate, such as Service Catalog, Team ownership and the like. The functionality should allow for schema versioning, tracking schema changes and in the future integrate with third party data stores to help manage those schemas.

🔎 Context: Our architecture model follows a natural hierarchy of relations, for example: • Domain <-Business Service -> System <-Component <- App Version <-Deployment (EKS Workload / ArgoCD Application / ECS Task Definition) • Component <- Quality Analysis (SonarQube Project) On the Component level in reports and widgets we need to see information coming from multiple related entities. • Domain Architect from Domain • Domain, Business Owner from Business Service • Deployment metrics from EKS / ArgoCD / ECS (deployment type, health rating, environments, AWS accounts, regions). • Quality metrics from SonarQube Project (size rating, coverage, complexity, link to SonarQube) On the Deployment / Quality Analysis level we also need to see properties coming from the Component, for example: • Status • SRE / DevOps owner ⚠️ Problem Currently this is difficult to achieve because: 1. Reports and widgets can only be based on a single entity, which makes it hard to build cross-entity views. 2. Mirror properties cannot be used flexibly, because: • mirror properties cannot mirror another mirror property • mirror properties cannot be used from the reversed direction of a relation Because of these limitations we are forced to introduce workarounds such as: • duplicating relations in both directions • creating additional direct relations between entities • using automations to maintain bidirectional links This leads to relation explosion in the data model and significantly increases model complexity. It also might have a performance impact building more infrastructure and automations than conceptually required, which adds operational overhead and system load. 💡Possible solutions Any of the following improvements would help solve this problem. 1️⃣ Flexible reports / widgets Allow reports or widgets to aggregate data from multiple related entities, not only a single entity. 2️⃣ Mirror properties as aggregation properties Allow mirror properties to be defined using a relation path, for example: Component → App Version → Deployment → health_rating Component <- SonarQube Project → coverage Component -> System <- Business Service → Domain 3️⃣ At minimum Support: • mirroring a mirrored property through a direct relation • mirroring a property from the reversed direction of a relation (related idea https://roadmap.getport.io/ideas/p/mirror-properties-from-the-other-direction-of-relation ) 📈 Impact We have successfully connected all the required data sources to Port (infrastructure, deployments, and quality analysis). As a result, the catalog already contains the necessary operational and architecture data. However, due to the current limitations around mirror properties and cross-entity reporting, we are struggling to turn this data into useful dashboards and reports.

Add the ability to mirror a property from a related blueprint even, regardless of the direction of the relation.

Sometimes during entity creation there are cases where you still want to create the entity, but don't want to create a missing related entity. Having this flag would allow for this use case. The entity would be created with the relation identifier included. This would put the entity in a state that is no different than when you delete an entity that is related to another entity and don't delete dependents. The identifier is still in the relation. If the related entity is recreated at some point, the two entities will now have that relationship.