Unter Apps findest du eine Sammlung vorkonfigurierter Anwendungen (Webanwendungen, Datenbanken, Tools und Dienste), die du auf deinem Server bereitstellen kannst, ohne eine Zeile YAML zu schreiben oder die Kommandozeile zu benutzen. Jede App ist bereits verpackt, getestet und mit sinnvollen Standardwerten versehen, sodass die Installation nur einen Klick auf Installieren erfordert.

Apps benötigen ein Docker-basiertes Image auf deinem Server. Der Menüpunkt Apps bleibt in jedem Fall sichtbar. Solange kein kompatibles Image läuft, wird eine entsprechende Meldung angezeigt.

1. Melde dich im Server Control Panel (SCP) an.
2. Gehe zu deinem Server und öffne Medien › Images.
3. Gehe in die Registerkarte App-Images.
4. Installiere eines der aufgelisteten Images auf deinem Server.

Wenn du Apps im SCP zum ersten Mal benutzt, gelangst du in den Menüpunkt Apps installieren. Hier siehst du eine Liste mit den Apps, die du installieren kannst, jeweils inklusive einer kurzen Beschreibung. Klicke auf die Schaltfläche der App, die du installieren möchtest. Falls du eine bestimmte App suchst, kannst du hierfür die Suchleiste rechts verwenden.

Die folgenden Screenshots zeigen die Installation einer App mit folgenden Pflichtfeldern:

In der Registerkarte Basiskonfiguration kannst du neben den Pflichtfeldern optional einen Spitz- und Hostnamen für deine App eingeben, um sie leichter zu unterscheiden. Für Hostnamen kannst du optional eine SSL-Verschlüsselung per Schieberegler aktivieren.

In der Registerkarte Erweiterte Konfiguration kannst du weitere Einstellungen vornehmen, welche aber nicht unbedingt erforderlich sind.

In der Registerkarte Benutzerdefinierte Konfiguration kannst du deinen Containern benutzerdefinierte Variablen hinzufügen. Klicke hierfür rechts auf Hinzufügen und trage in den entsprechenden Feldern Variablenname und Wert ein. Zudem kannst du sie hier wieder löschen.

Nachdem du alle Pflichtfelder und die von dir gewünschten Felder ausgefüllt sowie unten rechts auf Installieren geklickt hast, wird dir folgender Hinweis angezeigt:

Klicke unten rechts auf OK, wenn du damit einverstanden bist, die Sicherheit, Konfiguration und den Betrieb der App selbst zu übernehmen.

Anschließend startet der Download und du springst automatisch in den Menüpunkt Übersicht, wo dir die installierte App angezeigt wird. Der Ladebalken oben rechts zeigt dir den Downloadfortschritt an.

Im Menüpunkt Übersicht werden dir deine installierten Apps angezeigt. Hier werden dir je App Name, Instanz, Spitzname, Status, Aktualisierungsstatus und Aktionen angezeigt.

Jede Installation erhält eine eigene Instanz-ID (z. B. a63o), sodass du mehrere Installationen derselben App unterscheiden kannst.

1. Klicke auf Öffnen.
2. Klicke im sich anschließend öffnenden Pop-up-Fenster Anmeldeinformationen unten rechts auf Weiter zur App. Hier werden dir ebenfalls deine vorher angegebenen Pflichtfelder wie z. B. Admin Name, Admin Email und Admin Password angezeigt.

3. Folge den weiteren Anweisungen in der App.

Klicke auf Konfiguration, um deine eingetragenen Daten einzusehen. Hier werden dir erneut die 3 Registerkarten Basiskonfiguration, Erweiterte Konfiguration und Benutzerdefinierte Konfiguration angezeigt. In der Registerkarte Basiskonfiguration kannst du Spitz- und Hostname deiner App ändern sowie in der Registerkarte Benutzerdefinierte Konfiguration Variablen hinzufügen. Konfiguration ist deaktiviert, solange ein Update für die App verfügbar ist.

Bestätige deine Änderungen mit einem Klick auf Speichern & Neustarten unten rechts. Zudem kannst du über die entsprechenden Schaltflächen die Logs und die App öffnen.

Klicke auf Logs, um den Live-Log der Container einzusehen, die auf deinem Server laufen. Hier kannst du ebenfalls mithilfe des Drop-down-Menüs nach Container filtern sowie zur neuesten Zeile scrollen und Zeitstempel anzeigen lassen, indem du die jeweiligen Schieberegler aktivierst. 

Klicke auf Aktualisieren, um deine App zu aktualisieren.

Klicke auf Löschen, um deine App zu löschen.

Die folgenden Abschnitte beschreiben, wie Apps im Hintergrund funktionieren. Für die Installation oder Verwaltung von Apps benötigst du das nicht. Es ist jedoch nützlich, wenn du dich für die Architektur interessierst oder das Docker-Setup deines Servers direkt untersuchst.

SCP Server Satellite ist der kleine Agent, der deinen Server mit SCP verbindet und App-Deployments in dessen Auftrag ausführt. Er besteht aus 2 zusammenarbeitenden Containern.

• server-satellite-vsock-proxy: Er lauscht auf der vsock-Schnittstelle und leitet den Datenverkehr über eine lokale Verbindung an den Agenten weiter. Nur dieser Teil greift direkt auf vsock zu.
• server-satellite: Dies ist der eigentliche Agent. Er empfängt die weitergeleiteten Anfragen, spricht mit der lokalen Docker-Swarm-Engine, um Apps bereitzustellen, zu aktualisieren oder zu entfernen und meldet Status, Zustand und Logs an SCP zurück.

vsock (virtio-vsock) ist ein Kommunikationskanal, der nur zwischen dem KVM-Hypervisor (dem Host) und deinem Server besteht. Er ist keine Netzwerkverbindung und weder aus dem Internet noch von anderen Servern erreichbar. SCP nutzt diesen Kanal, um Verwaltungsbefehle an SCP Server Satellite zu senden, sodass App-Deployment und -Verwaltung nicht von der Netzwerkkonfiguration, den Firewall-Regeln oder der Erreichbarkeit der öffentlichen IP deines Servers abhängen.

Docker Swarm ist die in Docker integrierte Cluster- und Orchestrierungs-Engine. Statt eines einzelnen Containers per docker run werden Apps als Services bereitgestellt.

• Selbstheilung: Stürzt ein Container ab, startet Swarm ihn automatisch neu.
• Rolling Updates: Swarm kann Container bei einem Update nacheinander austauschen, statt die ganze App abzuschalten.
• Deklarative Konfiguration: Der Sollzustand der App (Image, Replikate, Ports, Volumes) wird als Service-Definition gespeichert.
• Isolation: Jede App läuft in ihrem eigenen Swarm-Stack/-Netzwerk und beeinflusst andere Apps standardmäßig nicht.

Dein Server wird bei Aktivierung von Apps automatisch als Einzelknoten-Swarm initialisiert. Du musst den Swarm-Cluster nicht selbst verwalten.

1. Du konfigurierst und übermittelst eine App über Apps [Beta] in SCP.
2. SCP sendet die Deployment-Anfrage über den privaten KVM-vsock-Kanal an deinen Server.
3. server-satellite-vsock-proxy empfängt sie auf der vsock-Seite und leitet sie über eine lokale Verbindung an server-satellite weiter.
4. server-satellite übersetzt die Anfrage in eine Docker-Swarm-Service-Definition und stellt sie bereit.
5. Die Docker-Engine deines Servers im Swarm-Modus plant die Container der App, kümmert sich um Neustarts und hält sie am Laufen.
6. server-satellite meldet Status, Zustand und Logs an SCP zurück. Das siehst du in Apps [Beta].

Apps werden über einen Reverse-Proxy auf deinem Server (Traefik) veröffentlicht. Dadurch ist der Standard-Hostname sofort über HTTPS erreichbar und Traefik übernimmt die Let’s-Encrypt-Zertifikatsausstellung für jeden zusätzlichen Hostnamen. Ein eigener Hostname muss ein vollqualifizierter Domainname sein (z. B. app.example.com). Traefik nutzt ihn, um eingehende Anfragen an die richtige App weiterzuleiten. Wenn du einen eigenen Hostnamen hinzufügst und Let’s Encrypt dafür deaktivierst, fordert Traefik kein Zertifikat automatisch an. Du bist dann selbst für die Zertifikatskonfiguration auf dem Server unter /opt/apps/traefik/conf/ssl-certs.yaml verantwortlich.

• Die interne Kommunikation zwischen den Containern einer App (z. B. einer App und ihrer Datenbank) läuft über ein privates, für diese App angelegtes Docker-Swarm-Netzwerk und ist nicht aus dem Internet erreichbar, sofern die App keinen Port explizit veröffentlicht.
• SCP selbst erreicht deine App nie direkt über das Internet, um sie zu verwalten. Der Verwaltungsverkehr läuft über den vsock-Kanal zu SCP Server Satellite, der dann in deinem Auftrag mit der lokalen Docker-Swarm-API spricht.

Das Image enthält seine Lizenz unter /licenses/LICENSE, entsprechend der Red-Hat-UBI-Konvention für die Platzierung von Lizenzen. Da der ENTRYPOINT des Images die Anwendung selbst startet, lies die Datei über docker create/docker cp, ohne die Anwendung zu starten:

(docker cp ... - streamt die Datei als Tar-Stream nach stdout. Leite sie durch tar -O -x, wenn du den reinen Text möchtest: docker cp "$id":/licenses/LICENSE - | tar -Ox.)

Das Image gibt seine Lizenz zusätzlich maschinenlesbar über das OCI-Label org.opencontainers.image.licenses an:

Das Image enthält den exakten Quellcode, aus dem es gebaut wurde, als Archiv unter /usr/share/doc/server-satellite/source.tar.gz: mvnw, pom.xml, .mvn/ und src/. Dies dient der MIT-Attribution/Auditierung und wird für den Betrieb der Anwendung nicht benötigt.

Wird das Image mit docker buildx build --sbom=true gebaut, wird eine SPDX-SBOM direkt als native OCI-Attestierung in das veröffentlichte Image eingebettet. Da diese SBOM bereits existiert, musst du das Dateisystem des Images nicht erneut scannen, um es auf bekannte Schwachstellen zu prüfen. Extrahiere stattdessen die mitgelieferte SBOM und prüfe diese.

Dies liest die zur Build-Zeit angehängte SBOM-Attestierung. Dabei werden weder die Layer des Images geladen noch dessen Dateisystem untersucht. Beachte das .SPDX am Ende: docker buildx imagetools inspect verschachtelt das eigentliche SBOM-Dokument unter einem .SPDX-Schlüssel innerhalb von .SBOM (BuildKits Standard-SBOM-Generator erzeugt SPDX, kein CycloneDX.). Wird nur .SBOM ohne .SPDX extrahiert, entsteht ein Wrapper-Objekt, das Trivy nicht parsen kann ("Detected SBOM format format=unknown"). Bei einem Multi-Plattform-Image zuerst nach Plattform indizieren: {{ json (index .SBOM "linux/amd64").SPDX }}.

trivy sbom gleicht die bereits in sbom.json aufgeführten Pakete mit der Schwachstellendatenbank von Trivy ab, das Container-Image selbst wird dabei nie berührt. Das unterscheidet sich von trivy image ..., das eine eigene, unabhängige Prüfung des Dateisystems des Images durchführt und dabei eine separate (meist aber ähnliche) Paketliste erzeugt.