Once you have a support channel, two questions matter: how fast will someone answer, and how fast do security fixes reach your nodes? Your plan sets both. You reach us by email, or on a shared Slack channel if you run Dedicated.

## Channels

Which channel you use depends on whether Syself hosts your management cluster or you run it in your own account.

- **Syself-hosted**: email [support@syself.com](mailto:support@syself.com).
- **Dedicated**: use your organization's shared Slack channel with Syself. Response times follow the SLA in your contract.

If you are unsure which channel applies, your primary contact at Syself confirms it.

Include the case details support needs on the first message. See [What to collect first](/docs/hetzner/apalla/support/what-to-collect-first).

## Severity

Support ranks a case by impact. A whole cluster down outranks a single degraded node, which outranks a question about configuration. The severity you and support agree on sets how fast the case is worked and how far it escalates.

The concrete severity levels, their definitions, and the response target for each come from the SLA in your contract. Your primary contact has the set that applies to your plan.

## CVE patch SLA

This is the second commitment, and it is separate from the support-response one above. It is not about how fast a case is answered. It is about how fast Syself ships a fix once a vulnerability is public.

Syself patches a CVE in the node image within a window set by the CVE's severity. The clock starts at the CVE's publication date, so delaying triage cannot extend it.

| Severity | Patch window |
| -------- | ------------ |
| Critical | 72 hours     |
| High     | 7 days       |
| Medium   | 30 days      |
| Low      | 90 days      |

A CVE on CISA's Known Exploited Vulnerabilities (KEV) list is treated as Critical, so it takes the 72-hour window whatever its base rating. A newly found CVE with no decision yet has a separate 7-day triage window, also measured from the publication date: it is assessed first, then patched on the window for its severity. A CVE left open past its window becomes a Critical finding and fails the release gate.

### Not every reported CVE affects Syself Autopilot

A CVE published against a piece of software does not automatically mean your nodes are exposed, so the raw CVE feed and the list Syself actually acts on will not line up. Before the patch clock starts, Syself triages each CVE against the image that actually ships:

- **Is the component even in the image?** Much of a normal Linux distribution is stripped out. If the affected component is not shipped, the CVE does not apply.
- **Is the vulnerable code built and reachable?** A component can ship without the vulnerable feature compiled in, or with the code present but never run: no service started, no port open, no interpreter to invoke it. If nothing can reach it, it cannot be exploited.
- **Is it already handled?** A newer version, or something already locked down on the node, may cover it.

Each of these decisions is recorded as a VEX (Vulnerability Exploitability eXchange) statement, with the justification, and ships with the image. When a scanner runs against a Syself node image, it reads those statements and skips anything marked not affected, so you do not get a wall of alerts that do not apply. Only the CVEs that genuinely affect the shipped image go on the windows above.

> [!NOTE]
> These windows are the rule the release pipeline enforces on every node image. Each image is scanned against several vulnerability sources before it ships, and a release is blocked if any CVE is past its window. KEV is CISA's Known Exploited Vulnerabilities catalog, the list of CVEs known to be exploited in the wild.

## What the two options change

Where the management cluster runs changes support routing, not the product.

- **Syself-hosted** runs the management cluster in Syself's account.
- **Dedicated** runs it in your own account. That moves etcd key custody and audit scope to you, and your contract sets the response times. The workload-cluster experience is the same either way.

See [Run a dedicated management cluster in your own account](/docs/hetzner/apalla/security/dedicated-management-cluster) for the full comparison.

## Escalation

If a case stops moving or its impact grows, raise the severity through your primary contact. On Dedicated, escalate in the shared Slack channel and name the new impact and the deadline you are working against.

## What stays your responsibility

Support covers the platform Syself operates. The rest of the cluster is a shared-responsibility split. Syself ships some controls on by default: immutability, audit policy, mTLS, the node firewall, and RBAC. You configure and operate the rest: etcd encryption, OIDC login, SSH lockdown, log shipping, and PodDisruptionBudgets.

Knowing which side of the line a problem sits on tells you whether it is a support case or a change you make. See [What you own, what Syself manages, and compliance](/docs/hetzner/apalla/concepts/ownership/ownership-and-shared-responsibility).

## Related

- [Get support](/docs/hetzner/apalla/support/get-support)
- [What to collect first](/docs/hetzner/apalla/support/what-to-collect-first)
- [What you own, what Syself manages, and compliance](/docs/hetzner/apalla/concepts/ownership/ownership-and-shared-responsibility)
- [Security](/docs/hetzner/apalla/concepts/ownership/security-model)