Feature ideas

Some customers would like the option to automatically report Port's information to an external SIEM system for security concern. https://www.ibm.com/topics/siem#:~:text=Security%20information%20and%20event%20management,chance%20to%20disrupt%20business%20operations . First and most important are the changes of Port's audit log

Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties. Example of Tags property with type of array: Current state: "Tags" : ["tag1"] Ingesting a new tag using the API: "tag2" New state: "Tags": ["tag1", "tag2"]

Add support for ingesting ServiceNow user-group membership records to drive. This would help to leverage membership data to establish a User-Groups relationship pattern natively within the Ocean integration.

Port's URL and Labeled URL properties are fundamentally different types, once a URL property is created, it cannot be converted to a Labeled URL in place. The only path to migration requires creating a new property, deploying, migrating data, updating all integrations, and deleting the old property, a process that can take ~2 hours for what should be a trivial display change. Proposed Solution Allow a display-layer transformation (e.g., via JQ expression or a simple label mapping) on existing URL string properties, so that: The underlying data remains a plain URL string (no schema change, no integration updates required). The display layer renders the URL with a human-readable label, equivalent to the current Labeled URL behavior. Why It Matters Eliminates data duplication and integration dependencies caused by property recreation. Reduces a ~2-hour migration to a seconds-long configuration change. Aligns with the spirit of the already-shipped Labeled URL feature.

The MyTeams option should appear in the filter value dropdown whenever the selected filter property resolves to a team, regardless of whether that property is: A native owning team property on the directly filtered entity A computed team property on the directly filtered entity An owning team property or relation on a related entity (i.e. filtering Entity A by Entity B's owning team) This can currently be achieved using JSON mode filters, but not in the form view with MyTeams.

Add support for reliably identifying the earliest commit & timestamp that belongs to a pull request across GitHub, GitLab, and Azure DevOps, as this is required to calculate Lead Time for Changes regarding DORA metrics.

Enterprise customers need Port to support access to internal MCP servers behind private network boundaries. A Port Agent–style proxy (deployable via Helm) would enable secure connectivity and unlock a major use case currently blocked by the platform’s push-based architecture. This would also allow teams to integrate internal tools (e.g., on-prem systems and private APIs) through Port’s MCP interface at scale.

Currently, the Bitbucket integration UI only supports username/password authentication. However, token-based authentication (client ID/secret) appears to already be supported at the Helm chart level. This suggests the limitation may be UI-only. It would be helpful to expose client ID/secret auth in the UI to align with existing backend capabilities and improve security/flexibility. If this is just a UI gap, it could be a relatively quick win if prioritized.

Currently, permission changes made through Terraform are not captured in the audit logs The request is to add support for logging permission changes triggered via Terraform in the audit logs

Summary Support for concurrent (overlapping) client secrets with configurable time-to-live (TTL) to enable automated, zero-downtime secret rotation. Problem When rotating a Port client secret, the old secret is immediately invalidated upon replacement. In distributed systems, consuming services need time to pick up the new secret value. During this propagation window, services still using the old secret experience authentication failures, causing downtime or errors. Currently, the same secret name cannot hold two valid values simultaneously, and there is no built-in mechanism to set an expiry/lifetime on a secret. While a custom automation can partially work around this, the lack of native support makes automated rotation fragile and error-prone. Proposed Solution Concurrent secrets: Allow at least two valid secrets to coexist for the same credential (e.g., a "primary" and "secondary" key pattern, similar to Azure AD app registrations or AWS IAM access keys). Both secrets should be accepted for authentication until the older one is explicitly revoked or expires. Secret TTL / expiry: Allow an optional time-to-live to be set when creating or rotating a secret. Once the TTL elapses, the secret is automatically invalidated. This enables a "create new → wait for propagation → old expires" workflow without manual cleanup. Rotation API: Expose a secret rotation endpoint (or extend the existing secrets API) that creates a new secret while keeping the previous one valid for a configurable grace period. This would integrate naturally with self-service actions for automated rotation schedules. Use Case As a platform team operating Port integrations across multiple Kubernetes services (Ocean integrations, CronJobs, Lambda functions), we want to automate client secret rotation on a regular cadence via a self-service action. The rotation flow would be: Generate a new secret (old secret remains valid) Propagate the new secret to consuming services (via K8s secrets, SSM parameters, etc.) Old secret expires after a configured grace period (e.g., 24 hours) Without concurrent secret support and TTL, there is always a window where some consumers hold a stale secret, resulting in failed API calls. Alternatives Considered Custom automation with rapid propagation: Rotate the secret and immediately push to all consumers. This is brittle — any delay or failure in propagation causes outages. - Scheduled maintenance window: Coordinate rotation during low-traffic periods. This doesn't scale and defeats the purpose of automation.