Manage Updates

Updates appear in a few places, but the rule is simple: update the smallest thing that owns the change.

Use Skills for skill package updates. Use Runtime and Release Policies for runtime container targets. Use Hubs and Release Policies for hub container targets. Use Billing when an update action is locked or the workspace needs private runtime or hub capacity first.

This keeps updates deliberate without making everyday setup feel heavy.

Start Here If

• Dashboard says an update is available;
• a skill row says it can update;
• a runtime update is ready for a skill set;
• a hub update is available;
• Release Policies shows an existing resource behind the saved target;
• Billing appears before you can manage private skills, runtime, or hubs.

At a Glance

Update type	Open this first	What changes
Skill update	Skills	One skill package in the selected skill set.
Runtime update	Runtime or Release Policies	OVOS core and messagebus images for a runtime group.
Hub update	Hubs or Release Policies	Hub listener and preview bridge images for a hub.
Plan gate	Billing and Plans	Whether the workspace can use the private feature.

Before You Update

Confirm:

• Billing allows the action if the page says Review plan, upgrade required, or limit reached;
• you know whether the update is for a skill, a runtime group, or a hub;
• the selected skill set or hub is the one you mean to change;
• Dashboard has no unrelated warning that should be handled first;
• a short restart or sync is acceptable for the affected runtime or hub;
• for hub updates, the backing runtime has no attention item.

Tip

Keep the default path simple: apply one visible update, wait for the ready state, then move to the next one only if Dashboard still asks for attention.

Update Owners

Skill updates

Skills shows installed skills, available versions, update badges, and Update all. Skill updates restart the runtime once updated packages are ready.

Runtime updates

Runtime updates move a runtime group to the saved image target. The core and messagebus images report ready when sync finishes.

Hub updates

Hub updates move the listener and preview bridge to the saved target. If the backing runtime needs attention, fix runtime first.

Release policy

Release Policies choose the default image target for new runtime groups and hubs, then let you apply that saved target to existing resources.

Release Source Choices

Choice	Use it when	Remember
Managed	You want the selected catalog track to stay current.	This is the easiest default.
Pinned	You want an exact catalog bundle until you choose another.	New resources stay on that bundle.
Custom	You need image overrides for an advanced case.	Blank override fields inherit from the selected catalog track.

New runtime groups and hubs use the saved release target. Existing runtime groups and hubs keep running until you apply the target to them.

Apply an Update

1. Start from the visible prompt. Dashboard, Skills, Runtime, Hubs, or Release Policies should tell you what needs attention.
2. Check Billing when prompted. If the action is locked, confirm the workspace has the needed runtime or hub capacity before changing setup.
3. Choose the owner page. Use Skills for skill packages, Runtime for a selected skill set, Hubs for a selected hub, or Release Policies for saved runtime and hub targets.
4. Review the target. Check the version label, release track, changed images, and any warning beside the resource.
5. Apply the update. Use Update skill, Update all, Update runtime, Update hub, Apply target, or Apply to all only when the target is clear.
6. Wait for sync. Runtime updates report ready after core and messagebus are healthy. Hub updates report ready after listener and preview bridge are healthy.
7. Verify the story. Return to Dashboard, then use Live Map when the update affects connected clients.

Billing Checks

Billing keeps update work from feeling mysterious:

• Free workspaces can keep using public hubs and available client connections;
• private skill sets, marketplace installs, and runtime operations need runtime capacity;
• owned hubs and hub release operations need hub capacity;
• paid skill add-ons renew monthly and stay separate from workspace plan upgrades;
• custom hub addresses and some help options are plan-controlled.

If Billing says the plan allows the action but the update still fails, return to the owner page and capture the visible status before asking for support.

Common Update Questions

Question	First check
”Should I update a skill or runtime?”	Use skill updates for one ability. Use runtime updates for the container images behind the skill set.
”Why can’t I update the hub?”	Check whether the backing runtime needs attention, then check Billing if the action is locked.
”Why did the runtime restart?”	Skill updates and runtime config changes can restart the runtime so the new package or setting can load.
”Should I change the release policy?”	Only change the release policy when new runtime groups or hubs should receive a different image target.

Update Management Is Done When

Update management is done when:

• the intended skill, runtime group, or hub shows the expected target;
• runtime sync has reported ready when core and messagebus changed;
• hub sync has reported ready when listener or preview bridge changed;
• Dashboard no longer shows an unexpected update prompt;
• Live Map still shows the expected client connection state;
• Billing has been checked for any remaining locked action.