---
title: Node Compatibility
description: How Sencho handles version differences across nodes and gracefully degrades features that aren't available on older instances.
---

When you manage multiple nodes, each running its own Sencho instance, those instances may be on different versions. A node running v0.28 won't have features that shipped in v0.31. Sencho detects this automatically and disables features that the active node doesn't support — no errors, no broken pages.

## How it works

Every Sencho instance exposes a `/api/meta` endpoint that returns its version and a list of **capabilities** — feature flags describing what that instance supports. When you switch to a node, your primary instance fetches this metadata and caches it for 5 minutes.

Features that require a capability the active node doesn't have are visually dimmed with an explanation overlay. Core features like stack management, containers, and resource monitoring are always available on every Sencho version.

## What you'll see

### Version in the node switcher

The sidebar node switcher shows each node's Sencho version next to its name. If a node is too old to report its version (pre-compatibility era), no version is shown.

### Disabled features

When you switch to a node that lacks a capability, the affected feature appears dimmed with a pill overlay explaining why:

> **Fleet Management** is not available — prod-server is running v0.28.0

The feature content is still visible (blurred) so you can see what you're missing, but it's non-interactive. Switch to a node that supports the feature, or update the remote node to the latest Sencho version.

### Connection test details

When you test a remote node's connection in **Settings > Nodes**, the result now includes the remote Sencho version alongside Docker info, container counts, and system stats.

## Capability list

Every Sencho release includes a static list of capabilities. Here are the capabilities tracked as of the current version:

| Capability | Feature |
|-----------|---------|
| `stacks` | Stack management (always available) |
| `containers` | Container operations (always available) |
| `resources` | Resource monitoring (always available) |
| `templates` | App Store (always available) |
| `global-logs` | Global log viewer (always available) |
| `system-stats` | System statistics (always available) |
| `fleet` | Fleet management |
| `auto-updates` | Auto-update policies |
| `labels` | Stack labels |
| `webhooks` | Webhooks |
| `network-topology` | Network topology view |
| `notifications` | Alert notifications |
| `notification-routing` | Notification routing rules |
| `host-console` | Host console |
| `audit-log` | Audit log |
| `scheduled-ops` | Scheduled operations |
| `sso` | SSO authentication |
| `api-tokens` | API token management |
| `users` | User management |
| `registries` | Private registry management |

<Note>
  Capabilities are flag-based, not version-based. Sencho never compares version numbers — it checks whether the remote node explicitly advertises support for a feature. This means the system stays forward-compatible as new features are added.
</Note>

## Handling older nodes

Nodes running a Sencho version from before the compatibility system was introduced (pre-v0.32) don't have the `/api/meta` endpoint. Sencho handles this gracefully:

- The version shows as blank in the node switcher
- All gated features appear as unavailable on that node
- Core features (stacks, containers, resources, logs) work normally
- No errors are thrown — the UI degrades cleanly

The fix is straightforward: update the remote node to the latest Sencho version. See the [upgrade guide](/operations/upgrade) for instructions.

## Interaction with license tiers

Some features require both a license tier (Skipper or Admiral) **and** node capability support. When both gates apply:

1. The license gate is checked first — if you're on the Community tier, you see the upgrade prompt
2. If your license covers the feature but the node doesn't support it, you see the compatibility overlay instead

This means you won't see confusing "upgrade to unlock" messages for features that wouldn't work on the active node anyway.
