Log in to and use the Enterprise Portal

Beta Feature

The Enterprise Portal is Beta. Features described on this page are subject to change.

This topic describes the new Enterprise Portal experience from the customer's perspective, including how to log in and use the portal features.

Logging in

Customers can access the Enterprise Portal through several methods:

Invitation email: When a vendor invites a customer user, they receive an email with an activation link. Clicking the link opens the portal and activates their account.

Magic link: On the login page, customers enter their work email and click "Continue with email." A one-time sign-in link is sent to their inbox. No password is needed.

Pending invite detection: If a customer visits the login page and has a pending team invite they haven't accepted yet, the portal informs them about the invite and gives them the option to enter their invite code directly, rather than only showing the magic link flow. After logging in, if a user has accepted one team but has pending invites to other teams, they also see a pending invites section prompting them to accept.

Self-service signup: When enabled by the vendor, customers can create their own account by visiting the signup URL, entering their information, and verifying their email with a code.

SAML SSO: When SAML is enabled by the vendor and configured by the customer's team, customers can log in using their corporate identity provider credentials. On a first SAML login, the portal creates the account automatically. A login that starts at the identity provider needs no invitation. A login that starts at the portal login page requires a pending invitation for that email address. For more information, see Just-in-time user provisioning in Manage customer access.

Access with multiple teams

If your email address has been invited to more than one customer team, you can switch between teams in the Enterprise Portal. To switch teams, click your name in the header and select a different team from the list. Each team has its own license, pull tokens, and portal content based on its assigned channel.

When you first log in, if you have pending invites to additional teams, the portal displays a pending invites section prompting you to accept them. After accepting, you can switch between all of your teams at any time.

All users invited to the same customer team share access to the same pull tokens, license credentials, and portal content.

Portal navigation

Once logged in, customers see a sidebar with the navigation defined by the vendor's toc.yaml. The default template organizes content into:

• Installation: Release history and step-by-step install instructions for each install method the customer's license allows, such as Embedded Cluster, Helm, KOTS, and kURL
• Instances & Updates: The customer's instances, available updates, and upgrade guides
• Security: CVE reports and SBOMs, when Security Center is enabled
• Support: Support bundles, FAQ, and contact information
• Automation: API reference and workflow guide for service account automation

The vendor controls which sections and pages appear for each customer through entitlements, visible_when rules, and unpublished pages marked hidden: true. Customers only see published content that is relevant to their license.

A version dropdown in the header lets customers switch between documentation versions when multiple are available on their channel.

Search is available via the search button in the header or Cmd+K (Mac) / Ctrl+K (Windows).

Installing and upgrading

Install pages show interactive, personalized instructions:

1. The customer selects or starts a new installation from the pending installations list
2. Configuration options (network availability, version, Kubernetes distribution) update the commands dynamically
3. The customer copies and runs the commands in their environment
4. After installation, they can name the instance for easy identification

The install commands are personalized to the selected installation and include the customer's specific credentials. If the customer switches installations or renames their instance, the commands update automatically.

For Helm installations of releases that contain more than one Helm chart, the charts are listed in the order determined by the weight property of the HelmChart custom resource. This applies to both the install and the upgrade instructions. For more information, see Chart installation order in Install with Helm.

For upgrades, customers use the Instances & Updates page. Helm and Embedded Cluster instance cards with an available update expand into generated CLI upgrade steps. KOTS and kURL cards expand into guided Admin Console application-upgrade steps. The portal identifies the selected target and supplies an application air gap bundle when required, but the customer performs and monitors the deployment in the Admin Console.

Instances that are already on the latest version show an Up to date badge. Customers can still expand supported cards to review the current release's commands or Admin Console guidance.

If a vendor marks a release as required, it is visually flagged with a Required badge and pre-selected as the upgrade target. Customers can still choose a later version.

Customers start a new installation from the install page for their method (Embedded Cluster, Helm, or KOTS) using the New installation button. Each install page appears only when the customer's license enables that method.

Air gap customers can create new instance records manually or by extracting details from an uploaded support bundle.

Downloading install artifacts

Depending on the install method and license entitlements, customers can download artifacts directly from the portal:

• Air gap bundles: Available from the Release History page and the install flow for air gap installations. Each release shows a build status (Ready, Building, Failed, or Not built) and a download link when the build is complete.
• Helm chart tarballs: Available during Helm installations when the customer selects limited or no registry access. Download links appear inline in the install and update instructions.
• CLI tools: The preflight plugin binary is available for download in the install flow, regardless of registry access settings.
• KOTS and kURL artifacts: The KOTS CLI, the Admin Console air gap bundle, the kURL installer bundle, and the application air gap bundle, plus the optional Preflight and Support Bundle CLI tools. Air gap bundles are available only when the customer's license allows air gap installations.

Private registry image relocation (Embedded Cluster)

For Embedded Cluster air gap installations, customers using a private registry can enter their registry hostname directly in the install flow. The instructions update to include image pull, tag, and push commands targeting that registry, along with the appropriate --registry flags on the install command. This is also available during Embedded Cluster upgrades when the instance was originally installed with a private registry.

KOTS and kURL instances

KOTS and kURL instances appear on the Instances & Updates page alongside Helm and Embedded Cluster instances, labeled KOTS or kURL. Each instance shows its current version and status.

KOTS and kURL instance cards expand into a guided application-upgrade panel. Customers can review or change the intended target release and then follow ordered steps for checking, selecting, and deploying that release in the Admin Console. The panel does not generate an upgrade CLI command, and it does not track whether the deployment completed.

What the panel shows depends on the instance:

• Online and proxy: The command to reopen the Admin Console, then steps to open Version History, check for updates, and deploy. No air gap artifact is offered.
• Air gap: The selected release's application air gap bundle. When the bundle is ready and the instance is not already on that release, the panel adds the reopen command and steps to upload the bundle from Version History and deploy.
• Air gap, bundle still building: The build status only, with no upload or deploy steps.
• Air gap, already on the selected release: The bundle, with no deploy step.
• Expired license, or a license without air gap access: No bundle.

The reopen command uses the customer's application slug for KOTS and default for kURL, which is where kURL's install.sh runs the Admin Console. To set a different namespace for those commands, see KOTS and kURL upgrade guides in Customize portal content.

For kURL, the panel upgrades the application only. It does not rerun install.sh or upgrade the cluster, and an application release does not on its own mean either is needed. Vendors document their own cluster-maintenance conditions and procedure in the customizable kURL upgrade guide.

The default content template includes dedicated KOTS and kURL install pages and entitlement-gated application-upgrade guides. Vendors can customize Admin Console access, registry, support, and kURL cluster-maintenance instructions, change the panel's guide link, or remove it. An expired license still surfaces a renewal notice on the install-page download controls. For installation-page details, see KOTS and kURL installer pages in Customize portal content.

Customers can create air gap instance records for KOTS and kURL the same way as for Helm and Embedded Cluster. They can enter instance information manually from the Instances & Updates page, or extract details from an uploaded support bundle. Availability depends on the customer's license having the corresponding install type and air gap option enabled.

Team management

Users on the customer's team can manage their portal team from the Team Settings page:

• Invite users: Send email invitations to colleagues
• Remove users: Remove team members from the portal
• Service accounts: Create and manage service accounts for programmatic access (CI/CD, automation)
• SAML configuration: When SAML is enabled by the vendor, users on the team can configure their identity provider by uploading IdP metadata and certificates
• Webhooks: Register a release webhook to start upgrade pipelines when a new release is available. For more information, see Manage customer release webhooks

Service account automation

Users on the customer's team can create service accounts and tokens for CI/CD systems and other automation.

Customers can use these tokens to call Enterprise Portal API endpoints from the same domain as the portal. Entitled KOTS and kURL customers can create install options, fetch JSON install and update instructions, and download artifacts the same way Helm and Embedded Cluster customers do.

The default Enterprise Portal content template includes an API reference and workflow guide for service account automation. The default workflow example uses Helm. The in-portal API reference documents kots and kurl when those install types are entitled.

For more information, see Headless Enterprise Portal: customer API.

Manage service account tokens

Users on the customer's team manage service accounts and their tokens from Team Settings > Service Accounts in the Enterprise Portal. A service account can hold more than one token, and each token works until it is revoked.

• Create a token: Adds a new token to the service account and leaves its existing tokens working. Give the token a name that identifies where it is used, such as ci-runner. The portal shows the token value only once, when you create it.
• Revoke token: Stops one token. The service account and its other tokens keep working.
• Revoke service account: Permanently disables the service account and stops all of its tokens. Use this only when nothing should authenticate with the account anymore.

Give automation access to an existing installation

When you install from the portal, the portal creates a service account named after your installation. Automation that manages that installation, such as an upgrade pipeline, must use a token on that same service account, because a service account can only see its own install options. Create an additional token on the installation's service account for the automation instead of reusing the token the installation runs with. For more information, see Headless Enterprise Portal: customer API.

Replace a token

To replace a token without interrupting an installation, create a new token on the same service account, move each system to the new token, and then revoke the old token.

• For Helm installs, run helm registry login with the new token and then redeploy with helm upgrade.
• For Embedded Cluster v2 installs that include the Admin Console, version 2.7.4 and later, download a license file that carries the new token and upload it from the License page in the Admin Console. The cluster then uses the new token without reinstalling.
• For Embedded Cluster v2 versions earlier than 2.7.4, and for Embedded Cluster v2 installs that do not include the Admin Console, a running cluster cannot adopt a new token. Reinstalling with the new token is required.
• Embedded Cluster v3 doesn't support moving a running installation to a new token. Don't revoke a token that a running Embedded Cluster v3 installation uses.

Confirm the installed Embedded Cluster versions before you revoke a token that Embedded Cluster instances depend on.

Read-only automation is not exempt. If you use a token headlessly to call Enterprise Portal API endpoints, for example to list available releases or check for new versions, update it there too before you revoke the old token.

note

Revoking a token affects every system that authenticates with it. When a service account token is the identity credential for a running installation, this includes update checks, license sync, and registry pulls. Plan the change so that each installation is moved to a working token first.

Support bundles

Customers can generate and upload support bundles from the portal:

• Generate bundles: Follow the instructions on the Support Bundles page to generate a diagnostic bundle. The page provides instructions for Embedded Cluster, kURL, Helm, and KOTS installations, and each customer sees only the methods that their license enables
• Upload bundles: Upload an existing bundle file for vendor analysis. The maximum upload size is 2 GB. For larger bundles, use the Replicated SDK API upload endpoint, which has no size restriction.
• View history: See previously uploaded bundles and their status

Security

When Security Center access is enabled for a customer, customers with Helm or Embedded Cluster installations can view security data for their releases.

• CVE reports: Browse vulnerabilities by severity, component, and container image for the selected release. For each CVE, the Fixed In column identifies the earliest vendor release that resolves it, when one is available.
• Fixable CVE filtering: Vendors can show only CVEs with an available fix or allow customers to switch between all CVEs and fixable CVEs.
• Release comparisons: Compare the selected release with the latest available release. The report shows how many CVEs are fixed by severity and container image.
• Upgrade recommendations: When active instances use the selected release, follow links to the Instances & Updates page to upgrade them. When viewing the latest release, select an older release listed on the page to review its security data and upgrade options.
• SBOMs: Download the Software Bill of Materials for any release version. SBOMs are accessible to all users on the customer's team.

note

Security Center data is available for Helm and Embedded Cluster installations only. KOTS and kURL instances don't contribute CVE data or upgrade recommendations, and they aren't counted toward instance totals in Security Center. Customers whose only instances are KOTS or kURL see an explanatory message instead of security data. Customers with a mix of instance types still see Security Center for their Helm and Embedded Cluster instances.

License information

Customers can view their license details including expiration date, license type, assigned channel, and any custom license fields configured by the vendor. Customers cannot edit their license from the portal.

Customers whose license enables Embedded Cluster, KOTS, or kURL installations can also download their license.yaml file, which those installation methods require. Helm installations do not use a license file, so Helm customers do not see a download option.