Skip to content

Hubs

A hub is a place that clients connect to. Think of it like the destination for an app, device, or experience.

A hub is not the same thing as a client. The hub is the place. The client is what connects to it. Permissions decide what that client can do after it connects.

Use this page when a hub is missing, unavailable, not visible, or hard to recognize in Dashboard, Clients, Permissions, or Live Map.

For owned hub creation, use Create a Hub. For shared discovery, use Public Hubs. For connection issues, move next to Clients or Live Map.

  • a hub is missing, unavailable, or not visible;
  • you need to choose between private and public hubs;
  • you need to understand what depends on a hub before creating clients;
  • the hub status, address, skills, or health panel is unclear.
QuestionSimple answer
What is a hub?The destination a client connects to.
Who creates it?The workspace, when the plan allows owned hubs. Pro allows up to 10 owned hubs.
What does it use?A skill set and runtime defaults.
What connects to it?Clients.
What keeps it safe?Narrow permissions for each client.
Hub page with hub cards and a selected hub detail panel showing address, skills, clients, permissions, and health.
The hub view shows setup, health, connected clients, permissions, and public details when a hub is listed publicly.

Name

The friendly label you use to recognize the hub.

Address

The hub address clients use when they connect.

Public or private

Private hubs stay inside the workspace. Public hubs appear in discovery.

Skills

The abilities available to the hub.

Runtime

The shared working setup behind the hub’s skill set.

Many other items point back to a hub:

  • Clients connect to one hub.
  • Permissions are set for a client on a hub.
  • Skills define what the hub can do.
  • Runtime defines shared settings for the hub’s skill set.
  • Dashboard shows hub status and attention items.
  • Live Map shows hubs and their clients.

Because hubs sit in the middle, choose the hub before creating clients and permissions.

PrivatePublicCertifiedCommunity

Private hubs are for your workspace. Use them when the hub should only be available inside your account area.

Public hubs are for discovery. They can publish a description, tags, audience guidance, age guidance, quality label, and starter prompts. Public hubs are useful for demos, shared experiences, and Free-plan exploration.

When you use a public hub, you do not manage that hub’s runtime. You create your own client for the public hub and keep permissions narrow.

When you create your own hub, you choose whether it uses the workspace default skill set or a separate skill set. Runtime config belongs to the skill set, not the client.

QuestionWhere to look
Where do clients connect?Hub
What can the hub do?Skills
What shared defaults do those skills use?Runtime
Which clients may use the hub?Permissions

Hub cards and inspectors show:

  • current state, such as ready, pending, failed, or unknown;
  • live status when available;
  • connected and known clients;
  • warnings;
  • recent activity;
  • available updates;
  • extra status details when the hub has them.

When you publish a hub publicly, make the listing useful:

  • write a short description in plain language;
  • add lowercase tags like assistant, education, or support;
  • choose the audience category;
  • add an age guidance value if needed;
  • publish starter prompts users can copy or try.

Good public hub listings make it obvious what the hub is for before anyone creates a client.

Create another hub when you need a different public/private setting, different skills, a different address, or a separate group of clients and permissions. Keep one hub when the same setup still makes sense.

A hub is ready for a first client when:

  • the name explains the hub purpose;
  • the public or private setting is correct;
  • the skill set choice is intentional;
  • the address is visible when needed;
  • the hub status has no unexpected warning;
  • you know which client should connect next.