Reference

These pages state facts about Layer5 Cloud: which plan includes a capability, which role holds a permission, and how to call the REST API. Start with Concepts for how the pieces fit together.

Security permission keys 🔗

Provider Admin holds every key. The table lists the default holders of the other roles, as of Layer5 Cloud v1.0.280. “Interface” means the control or tab is disabled or replaced by a permission error screen. “Server” means the Layer5 Cloud server refuses the request with HTTP 403.

Roles that hold the keys come from the default keychains: View keys sit in User View, Delete Token in Security Management, Create Token and Download Token in Security Management and User Edit, and the key and keychain management keys, including Assign Keychains to Roles, in Provider Management. Where the server requires the Provider Admin role, it checks the role across the whole deployment, not the role held in one organization. See Default Permissions for the role matrix, and Keys, Keychains, Sessions, and Tokens for lifetimes, cookies, and endpoints.

Visibility rules 🔗

Default keys and keychains are owned by the system. Deleting a key or keychain is a soft delete, and a deleted key or keychain stops granting access immediately.

Feature availability by plan 🔗

Your plan is one condition for using a capability. Your role and where your Layer5 Cloud deployment runs also decide what you can do. Those conditions follow the matrix and the limits table.

Plans 🔗

The matrix has one column for each of the four Layer5 plans: Free, Team Designer, Team Operator, and Enterprise. Each plan is offered with monthly and annual billing. The Free plan is the plan that Layer5 Cloud calls Personal in its plan records, so you see that name in subscription and entitlement data. Entitlements follow your organization’s plan. Current pricing and plan details are listed at layer5.io/pricing.

Reading the matrix 🔗

• A check mark means the plan includes the capability.
• A dash means the plan does not include it.
• Each table covers one category of capability. The What it does column describes the capability in one sentence. An empty cell means the plan list records no description.

The matrix is taken from the Layer5 product feature list. It lists the capabilities that have a documentation page. A capability that does not appear here is not necessarily unavailable. Check the page that documents it.

This section covers the Layer5 Cloud categories. For design, deployment, collaboration, and performance capabilities, see Kanvas reference.

Capabilities by plan 🔗

Identity & Access Management 🔗

Workspaces 🔗

Catalog 🔗

Security 🔗

Managed Service Provider 🔗

Support and Deployment 🔗

Academy 🔗

Limits by plan 🔗

Each plan records a quantity for the following entitlements.

For workspaces per organization on the Free plan, the plan records disagree: the monthly billing record sets 1 and the annual billing record sets 10.

Which limits Layer5 Cloud enforces 🔗

Layer5 Cloud enforces one limit today: components per design. When you save or import a design, Layer5 Cloud compares its component count with the limit of your organization’s active plan. A design that exceeds the limit is refused with the error Design exeeds maximum limit of N components supported by your current plan, where N is the limit. To proceed, reduce the number of components in the design or upgrade the plan. When an organization holds more than one active subscription, the highest component limit among them applies. An organization with no active subscription cannot save or import a design. The request fails with HTTP 500 and the error Org is not entitled to adding components to a design.

Layer5 Cloud records every other quantity in the table and lists it through the entitlements API (GET /api/entitlement/features), but it does not refuse an action because of any of them. For the API’s base URL and authentication, see the Cloud API.

Availability depends on more than your plan 🔗

Your role 🔗

Authorization in Layer5 Cloud is by permission key. Each role you hold grants a set of keys, and your effective permissions are the union of the keys from every role you hold in the organization you are working in. An action your role does not grant is refused with HTTP 403, even when your plan includes the capability. See Default Permissions for which role holds which permission.

Where your deployment runs 🔗

Layer5 Cloud runs either as the hosted service that Layer5 operates or as a self-hosted deployment that you operate. Self-hosted Deployment is listed under the Enterprise plan in the Support and Deployment table. The difference that matters most for availability is provider administration. The Provider Admin role administers the deployment and passes every permission check. On a self-hosted deployment, your operators assign it.

Custom roles 🔗

Only Provider Admins create custom roles. Layer5 Cloud refuses a role creation request from anyone else with HTTP 403. On hosted Layer5 Cloud, an organization cannot create a custom role itself. On a self-hosted deployment, the operator’s Provider Admins can. Roles are defined for the whole deployment, not per organization, so a role change applies in every organization where the role is held.

The Custom Roles and User-defined Roles rows in the Identity and Access Management table describe how those capabilities are packaged into plans. Layer5 Cloud does not check your plan when a custom role is created.

Plan rows and enforcement 🔗

The component limit is the only entitlement Layer5 Cloud enforces by plan. The capability rows in the matrix describe how Layer5 packages its plans. When an action is unavailable and the plan is not the component limit, check your role and your deployment first.

Support by plan 🔗

The support channels and response commitments each plan includes are listed in Support.

Related Reading

• API Reference
• Cloud API
• Rate limits