Feature ideas

The Ocean container image runs as user ocean with UID 999 . Some organizations have security policies that prohibit running containers with UIDs below 1000. This restriction blocks deployment unless the default UID is overridden, which can break functionality or impact performance (e.g., issues with certificate updates or /tmp access). Request: Parameterize the UID in the Dockerfile or Helm chart, or provide a supported way to run Ocean with a user UID >= 1000 , to comply with stricter security policies.

Today, the homepage have a list of "Personal Widgets" available which is not available on dashboard pages. It reduce options availables for dashboard creation.

Every API endpoint is plural and has a plural response data structure, except for "integration." However, the integration endpoint returns the plural in your response data structure... "integrations": [{}] You should make API endpoint naming conventions consistent.

Currently, Port's /v1/auth/access_token API requires clientId and clientSecret to be passed in the POST request body. This creates challenges for security-conscious implementations where: Secret masking: Many logging and monitoring systems can mask header values but not POST body content, leading to potential credential exposure in logs OAuth2 standard compliance: The OAuth 2.0 specification (RFC 6749) supports sending client credentials via the Authorization header using Basic authentication Automation workflows: Users building automation flows need to handle credentials securely without introducing additional infrastructure like cloud functions Proposed Solution Add support for passing client credentials via the Authorization header using HTTP Basic Authentication, in addition to the existing POST body method. Example implementation: curl --location --request POST ' https://api.getport.io/v1/auth/access_token ' \ --header 'Authorization: Basic <base64_encoded_clientId:clientSecret>' \ --header 'Content-Type: application/json' This would be in addition to (not replacing) the current method, ensuring backward compatibility. Benefits Enhanced security: Enables credential masking in logs and monitoring systems Standards compliance: Aligns with OAuth 2.0 best practices Simplified automation: Reduces the need for intermediate services to handle authentication Flexibility: Provides users with multiple authentication methods based on their security requirements

Input fields that are hidden using the visibility property, or marked as disabled , remain visible and editable when the form is switched to JSON mode. Currently, the visibility property only affects how fields are displayed in the UI. It hides them from the standard form view but doesn’t remove them from the underlying data structure or JSON representation. This behaviour can potentially allow users to modify fields they shouldn’t have access to, which may introduce security or data integrity risks. Suggested Enhancement: Consider excluding hidden and disabled fields from JSON mode, or marking them as read-only, to align behaviour with the form view and prevent unauthorised edits.

Visualising graphql schemas, including search across would be super useful for api documentation

The Port Ocean Helm Chart currently uses a fixed service port name ( ocean-port ). Some environments, such as shared EKS clusters, may enforce naming conventions via admission controllers. If the service port name does not comply, deployment is rejected. This prevents users from deploying Ocean without modifying the chart. Request: Parameterize the service port name in the Helm values file, allowing users to set a custom name that complies with their cluster policies.

Currently, if your description for an action itself is too long, both the action card and the action form cut off the description. There is an ellipses added at the end, but there is no way to expand the description in either spot to view the rest of the text. The description should be expandable, or you should be able to hover over it and have a tooltip with the full text visible.

Right now there is a 300 character count limit for the URL input when configuring an Organization Announcement. Many links are longer than 300 characters, and there should be no limit - or a far higher one.

The incremental sync script can collect changes every x minutes, acting as a "near real time" events processor. Adding this behavior to the Azure Resource Graph integration would provide near real time experience on top of the full resync using the resource graph QL, which would act as a cleanup.