Feature ideas

Today, the user entity from the Governance page only has the identifier field which shows either the email or upn value. However, in the case where both upn and email fields are present for a user, the upn field is used as the identifier and the email field doesn't show up in port. Adding the property to for an email field in the Governance page would further enhance the data inside of port.

The Bedrock provider currently always routes requests to AWS's native Bedrock endpoints, with no way to point at a different host. Some organizations run an internal proxy or gateway in front of Bedrock's invoke API for network control, auditing, or centralized access management, and need requests to go through that proxy instead of directly to AWS. The underlying AI SDK (@ai-sdk/amazon-bedrock v4+, already in use by Port) natively supports a baseURL override alongside its existing credential options, so adding an optional baseUrl config field to Port's Bedrock provider would unblock proxy-fronted Bedrock deployments without changing the default AWS-direct behavior.

Please add support for Amazon Bedrock API keys as a native authentication method alongside the existing assume-role and static IAM access key options. AWS now supports service-scoped Bedrock API keys (both long-term and 30-day short-term). Allowing users to store a Bedrock API key as a Port secret and authenticate directly via the AWS_BEARER_TOKEN_BEDROCK mechanism would remove the need for cross-account roles or broad IAM keys. This significantly reduces the security blast radius and simplifies credential rotation.

Amazon Bedrock agents (highest priority) - AWS::Bedrock::Agent - AWS::BedrockAgentCore::Runtime Goal: catalog the AI agents running in AWS, with ownership and governance in Port. Amazon OpenSearch Service domains - AWS::OpenSearchService::Domain IAM roles, including usage data - AWS::IAM::Role - Must include RoleLastUsed (LastUsedDate, Region), as returned by the IAM GetRole API. Goal: identify unused or stale roles for security and governance reviews. Why this is needed AWS v3 doesn't support custom kinds, so users can't add these resources themselves. The AWS Legacy integration isn't a full workaround: Cloud Control has no List operation for OpenSearch domains, and Cloud Control doesn't return RoleLastUsed for IAM roles. The only remaining option today is custom code (a script or a standalone Ocean integration), which customers don't want to build and maintain. Since v3 uses service-specific AWS APIs, it shouldn't be affected by these Cloud Control limitations. Related Bedrock agents may overlap with the native Bedrock integration planned for Q4. If that integration will cover them, the scope here can narrow to OpenSearch and IAM.

Currently, Port handles Kubernetes data by ingesting resources into the Software Catalog and displaying runtime information or dashboards, alongside running operations via self-service actions. However, there is a customer need for an integrated, interactive cluster-management UI directly inside Port (analogous to Headlamp’s embedded experience) to monitor, visualize, and interact with Kubernetes resources seamlessly without navigating away from the portal. https://headlamp.dev/blog/2024/11/11/introducing-an-integrated-backstage-and-headlamp-experience/

The GET /v1/workflows/runs endpoint currently returns at most 1000 results with no way to page beyond them. Query parameters that appear filterable workflowIdentifier, source, createdBefore, from/to, offset are ignored, and GET /v1/workflows/{identifier}/runs returns 404. For orgs with high-volume event-triggered workflows, the 1000-run window can cover as little as two hours of history, making all older runs permanently unreachable through the list endpoint even though they exist and are individually accessible by ID. The fix is straightforward: add a next cursor to the response and make the existing filter parameters functional, matching the pattern already implemented on GET /v1/actions/runs?version=v2. At minimum, workflowIdentifier and a createdAt date range (from/to) would cover the majority of reporting use cases, with status, result, and source as nice-to-haves. This is a parity gap, not a new concept the pattern exists in our own API.

Admins can create pre-made filters presets on dashboard pages. Presets give members an easy starting point.

SSO group allow/block regex filters currently apply at the company level, so they can't be scoped to an individual organization. Because teams are organization-scoped while group filters are not, any IdP group assigned to a user triggers team creation in every organization that user can access, regardless of whether the group is relevant there. Customers running multiple organizations under one account have no way to prevent this cross-org team sprawl without one shared regex affecting all organizations identically. Supporting per-organization group filters would let admins keep each organization's team list limited to the groups that actually belong there.

We're migrating from the legacy AWS integration to aws-v3. Two resource kinds we rely on have no exporter or blueprint in aws-v3 but they are crucial: AWS::Glue::Job AWS::StepFunctions::StateMachine Is support for these kinds on the roadmap (did search can't find)? If so, is there a rough timeline?

When a social login provider (e.g. "Continue with Google") is disabled for an organization's domain, users who click it today hit a hard-stop "Login is disabled" page with no path forward, even though the org has a working SSO (e.g. Okta) configured. Instead, blocked social-login attempts should automatically redirect to the org's configured SSO flow, or at minimum surface an explicit "Login with SSO" button on that page. Without this, anyone following a shared link lands on a dead end before ever reaching login, which directly hurts first-time user onboarding and early retention.