netcup ARM-Server: Docker-Images und Software vor dem Umzug auf arm64 prüfen

netcup bietet neben den x86-Servern eigene ARM-Tarife an, etwa den VPS 500 ARM G12.5, mit Prozessoren vom Typ Ampere Altra Max. Wer von x86 umziehen will, stellt sich zuerst eine Frage: Läuft meine Software dort überhaupt? Ein ARM-Server kann laut netcup keine x86-Anwendungen ausführen. Diese Anleitung zeigt Schritt für Schritt, wie Sie Ihre Docker-Images, Pakete und Programme vor dem Umzug auf arm64 prüfen, und zwar bequem vom bestehenden x86-Server aus. Alle Befehle und Ausgaben stammen von unserem Testserver, einem VPS 500 G12.5 (x86) mit Ubuntu 24.04.5 und Docker 29.9.2, am 03.11.2026.

Dies ist Teil 18 der Reihe „netcup Spezial“.

Was Sie brauchen

• Ihren bestehenden Server mit Docker, von dem aus Sie prüfen
• die Liste Ihrer Images, am einfachsten Ihre Compose-Dateien
• Root-Zugang per SSH, um das Prüfskript unter /usr/local/bin abzulegen

Einen ARM-Server brauchen Sie für die Prüfung noch nicht. Die Abfragen der Images lesen nur die Angaben in der Registry.

Schritt 1: ARM bei netcup einordnen

Die ARM-Server von netcup laufen laut Produktseite mit ARMv8 und AArch64, unter Linux heißt diese Architektur aarch64, bei Docker und Debian-Paketen arm64. Die ARM-Server sind bei netcup eigene Tarife, von VPS 500 ARM G12.5 bis VPS 8000 ARM G12.5. Planen Sie den Wechsel deshalb als Umzug: neuen ARM-Server bestellen, Software einrichten, Daten übertragen. Wie das mit rsync geht, zeigt Teil 1 der Reihe.

Zwei Grenzen nennt netcup selbst: x86-Anwendungen laufen auf ARM nicht, und Windows lässt sich auf ARM64-Servern nicht betreiben. Auch nicht jede bereitgestellte CD oder DVD passt zu jedem Server.

Prüfen Sie zuerst die Architektur Ihres aktuellen Servers:

uname -m
dpkg --print-architecture

x86_64
amd64

Verifizieren: Ihr aktueller Server meldet x86_64. Auf einem ARM-Server stünde dort aarch64 und arm64.

Schritt 2: Plattformen eines Docker-Images abfragen

Die meisten bekannten Images sind Mehrarchitektur-Images. Unter einem Namen wie nginx:1.29-alpine liegt eine Liste mit einer Variante je Plattform. Docker lädt automatisch die passende. Welche es gibt, zeigt dieser Befehl:

docker buildx imagetools inspect nginx:1.29-alpine

In der Ausgabe steht für jede Variante eine Zeile Platform:. Für nginx fanden wir unter anderem linux/amd64, linux/arm64/v8 und linux/arm/v7. Für einen netcup-ARM-Server zählt nur linux/arm64, mit oder ohne den Zusatz /v8. Varianten wie arm/v7 sind für ältere 32-Bit-Geräte gedacht.

Zwischen den Plattformen tauchen oft Einträge mit unknown/unknown auf. Das sind keine Images, sondern Begleitdaten zum Build, sogenannte Attestations. Sie können sie ignorieren.

Verifizieren: Die Ausgabe enthält eine Zeile mit linux/arm64. Dann gibt es eine native Variante für ARM-Server.

Schritt 3: Images ohne Plattformliste erkennen

Manche Images haben keine Liste, sondern genau eine Variante. Dann fehlen die Zeilen Platform: ganz. So war es bei Microsoft SQL Server:

docker buildx imagetools inspect mcr.microsoft.com/mssql/server:2022-latest

Name:      mcr.microsoft.com/mssql/server:2022-latest
MediaType: application/vnd.docker.distribution.manifest.v2+json
Digest:    sha256:cf8f0ab2ebe61feec2eed2629061a07d247f791c2a8ddda74a4ac9f06a291718

Der MediaType manifest.v2+json steht für ein einzelnes Image. Die Architektur fragen Sie dann direkt ab:

docker buildx imagetools inspect mcr.microsoft.com/mssql/server:2022-latest --format '{{.Image.Architecture}}'

amd64

Verifizieren: Steht hier amd64, gibt es von diesem Image keine ARM-Variante. Suchen Sie eine Alternative oder bleiben Sie für diesen Dienst bei x86.

Schritt 4: Was passiert, wenn das falsche Image startet

Ein Image für eine fremde Architektur lässt sich herunterladen, startet aber nicht. Wir haben das umgekehrt nachgestellt und auf dem x86-Server ein arm64-Image erzwungen:

docker run --rm --platform linux/arm64 alpine:3.22 uname -m

exec /bin/uname: exec format error

Dieselbe Meldung erscheint auf einem ARM-Server bei Images, die nur aus einer einzigen amd64-Variante bestehen, wie SQL Server aus Schritt 3. Wenn ein Container nach dem Umzug sofort mit exec format error beendet wird, liegt es meist an der Architektur.

Hat ein Image dagegen eine Plattformliste ohne die gesuchte Variante, bricht schon das Herunterladen ab. Das haben wir mit einer Plattform nachgestellt, die nginx nicht anbietet:

docker pull --platform linux/mips64le nginx:1.29-alpine

Error response from daemon: no matching manifest for linux/mips64le in the manifest list entries: no match for platform in manifest: not found

Auf einem ARM-Server steht an dieser Stelle linux/arm64 oder linux/arm64/v8.

Verifizieren: Mit docker logs und dem Namen des Containers sehen Sie exec format error, falls ein Container nach dem Umzug nicht hochkommt. Scheitert schon docker pull, steht der Grund mit no matching manifest direkt in der Ausgabe.

Schritt 5: Unser Ergebnis für verbreitete Images

Wir haben zwölf Images geprüft, die im Selfhosting häufig vorkommen. Stand ist der 03.11.2026.

Image	arm64
nginx:1.29-alpine	ja
mariadb:12.3	ja
postgres:17	ja
louislam/uptime-kuma:2.5.5-slim	ja
vaultwarden/server:latest	ja
nextcloud:stable	ja
gitea/gitea:latest	ja
traefik:v3.7	ja
ghcr.io/linuxserver/baseimage-alpine:3.20	ja
portainer/portainer-ce:latest	ja
grafana/grafana:latest	ja
mcr.microsoft.com/mssql/server:2022-latest	nein, nur amd64

Das Ergebnis gilt für genau diese Tags. Ein anderer Tag desselben Images kann andere Plattformen haben. Prüfen Sie deshalb immer den Tag, den Sie wirklich einsetzen.

Verifizieren: Sie haben die Tags aus Ihren eigenen Compose-Dateien geprüft, nicht nur die Beispiele aus dieser Tabelle.

Schritt 6: Alle Images einer Compose-Datei auf einmal prüfen

Damit Sie nicht jedes Image einzeln abfragen müssen, haben wir ein kleines Skript geschrieben. Es liest die Images aus einer Compose-Datei oder aus der Befehlszeile und meldet für jedes, ob es eine arm64-Variante gibt. Legen Sie es als /usr/local/bin/arm-check an:

nano /usr/local/bin/arm-check

#!/bin/bash
# Prüft, ob Docker-Images eine Variante für linux/arm64 haben
# Aufruf: arm-check IMAGE ...   oder   arm-check -f compose.yaml
if [ "$1" = "-f" ]; then
  set -- $(docker compose -f "$2" config --images)
fi
[ $# -eq 0 ] && { echo "Keine Images gefunden" >&2; exit 2; }
fehlt=0
for img in "$@"; do
  plattformen=$(docker buildx imagetools inspect "$img" 2>/dev/null | awk '/Platform:/ && $2!="unknown/unknown" {print $2}')
  if [ -z "$plattformen" ]; then
    arch=$(docker buildx imagetools inspect "$img" --format '{{.Image.Architecture}}' 2>/dev/null)
    plattformen="linux/${arch:-unbekannt}"
  fi
  if echo "$plattformen" | grep -q '^linux/arm64'; then
    echo "OK     $img"
  else
    echo "FEHLT  $img (nur: $(echo $plattformen))"
    fehlt=1
  fi
done
exit $fehlt

chmod 755 /usr/local/bin/arm-check

Rufen Sie es im Ordner Ihres Projekts mit der Compose-Datei auf. Unsere Test-Datei enthielt nginx, MariaDB und SQL Server:

arm-check -f compose.yaml

FEHLT  mcr.microsoft.com/mssql/server:2022-latest (nur: linux/amd64)
OK     nginx:1.29-alpine
OK     mariadb:12.3

Einzelne Images prüfen Sie so:

arm-check vaultwarden/server:latest louislam/uptime-kuma:2.5.5-slim

OK     vaultwarden/server:latest
OK     louislam/uptime-kuma:2.5.5-slim

Das Skript endet mit dem Rückgabewert 1, sobald ein Image fehlt, und mit 0, wenn alle eine arm64-Variante haben. Findet es gar keine Images, etwa weil die Compose-Datei fehlt oder fehlerhaft ist, meldet es Keine Images gefunden und endet mit 2. So können Sie es auch in eigene Abläufe einbauen. Meldet es linux/unbekannt, hat es das Image in keiner Registry gefunden. Das passiert bei einem Tippfehler im Namen oder Tag, wenn die Registry eine Anmeldung verlangt, oder bei einem Dienst, den Compose mit build: aus einem eigenen Dockerfile baut. Unser Test mit einem solchen Dienst namens eigen ergab:

OK     nginx:1.29-alpine
FEHLT  armcheck-eigen (nur: linux/unbekannt)

Für selbst gebaute Images gilt Schritt 9.

Verifizieren: Jedes Image Ihrer Compose-Datei steht mit OK oder FEHLT in der Ausgabe. Für jedes FEHLT brauchen Sie vor dem Umzug eine Lösung.

Schritt 7: Programme außerhalb von Docker prüfen

Pakete aus den Ubuntu-Quellen sind in der Regel kein Problem. Ubuntu baut seine Pakete auch für arm64 und liefert sie über einen eigenen Spiegel aus, ports.ubuntu.com statt archive.ubuntu.com. Der Spiegel war in unserem Test erreichbar. Auf dem neuen ARM-Server zeigt grep -h ^URIs /etc/apt/sources.list.d/*.sources, ob ports.ubuntu.com eingetragen ist.

Kritischer sind Programme, die Sie von Hand installiert haben, etwa als Binärdatei aus einem GitHub-Release, aus einem eigenen Herstellerrepository oder als .deb-Datei. Suchen Sie diese Dateien auf dem alten Server:

ls -l /usr/local/bin /opt
grep -rh ^deb /etc/apt/sources.list.d/ 2>/dev/null
grep -h ^URIs /etc/apt/sources.list.d/*.sources 2>/dev/null

Auf unserem Testserver stand dabei die Docker-Paketquelle mit einer festen Architektur:

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu   noble stable

Solche Zeilen dürfen Sie nicht unverändert auf den ARM-Server kopieren. Dort muss arch=arm64 stehen, sonst findet apt keine Pakete. Am sichersten richten Sie Fremdquellen auf dem neuen Server nach der Anleitung des Herstellers neu ein. Docker selbst schreibt in seiner Anleitung arch=$(dpkg --print-architecture), dann passt die Zeile auf beiden Architekturen.

Für jedes Programm aus dieser Liste prüfen Sie, ob der Hersteller eine arm64-Version anbietet. Bei Releases auf GitHub steht die Architektur meist im Dateinamen. Für das Backup-Programm restic fanden wir zum Beispiel restic_0.19.1_linux_amd64.bz2 und restic_0.19.1_linux_arm64.bz2. Bei Herstellerrepositorys suchen Sie in der Anleitung des Herstellers nach arm64 oder aarch64. Ob eine fertige Binärdatei zur Architektur passt, verrät der Befehl file. Auf unserem x86-Server nannte er für /usr/bin/ls unter anderem ELF 64-bit LSB pie executable, x86-64. Für die entpackte arm64-Fassung von restic meldete er ELF 64-bit LSB executable, ARM aarch64.

Verifizieren: Für jedes Programm außerhalb der Ubuntu-Quellen wissen Sie, woher Sie die arm64-Fassung bekommen.

Schritt 8: Warum Emulation keine Lösung ist

Linux kann mit QEMU Programme einer fremden Architektur emulieren. Für Docker richtet das ein Hilfs-Image ein. Wir haben es auf dem x86-Server getestet, damit dort arm64-Images laufen. Das Hilfs-Image braucht --privileged, weil es die Emulatoren im Kernel registriert:

docker run --privileged --rm tonistiigi/binfmt:qemu-v10.0.4 --install arm64
docker run --rm --platform linux/arm64 alpine:3.22 uname -m

aarch64

Das funktioniert, ist aber langsam. Wir haben in beiden Varianten eine SHA-256-Prüfsumme über 200 MB berechnet, gemessen samt Start des Containers:

docker run --rm --platform linux/arm64 alpine:3.22 sh -c 'head -c 200000000 /dev/zero | sha256sum'

Variante	1. Lauf	2. Lauf
nativ (amd64 auf x86)	2,7 s	1,8 s
emuliert (arm64 auf x86)	25,5 s	25,2 s

Emuliert dauerte es in beiden Läufen gut neunmal so lange oder länger. Auf einem ARM-Server arbeitet die Emulation von amd64-Images nach demselben Prinzip. Für einen Dauerbetrieb taugt Emulation daher nicht. Gut eignet sie sich für einen anderen Zweck: Auf dem x86-Server können Sie damit eigene Images gleich für beide Plattformen bauen. Lassen Sie die Emulation dafür für Schritt 9 noch aktiv. Die Registrierung übersteht keinen Neustart des Servers, nach einem Neustart führen Sie den Befehl erneut aus.

Verifizieren: docker run --rm --platform linux/arm64 alpine:3.22 uname -m meldet aarch64.

Schritt 9: Eigene Images für beide Plattformen bauen

Bauen Sie eigene Images aus einem Dockerfile, können Sie mit docker buildx eine Variante für amd64 und eine für arm64 erzeugen. Wir haben dafür einen eigenen Builder mit dem Treiber docker-container angelegt und die Emulation aus Schritt 8 genutzt. Unser Test-Dockerfile:

FROM alpine:3.22
RUN apk add --no-cache curl
CMD ["sh","-c","echo Architektur: $(uname -m)"]

docker buildx create --name multi --use
docker buildx build --platform linux/amd64,linux/arm64 -t meinimage:1.0 --output type=oci,dest=meinimage.tar .

Bei uns lief der Build durch. In der Ausgabe stand exporting manifest list, und die Datei meinimage.tar mit beiden Varianten war rund 12 MB groß. Wer eine eigene Registry nutzt, ersetzt die Option --output durch --push und lädt das Image mit beiden Varianten direkt hoch. Zum Schluss entfernen Sie Builder und Emulation:

docker buildx rm multi
docker run --privileged --rm tonistiigi/binfmt:qemu-v10.0.4 --uninstall qemu-aarch64

Verifizieren: Der Build meldet exporting manifest list, und die Datei meinimage.tar liegt vor. Nach dem Entfernen meldet das arm64-Image aus Schritt 8 wieder exec format error, und in /proc/sys/fs/binfmt_misc/ steht kein Eintrag qemu-aarch64 mehr.

Checkliste vor dem Umzug auf ARM

• Alle Images mit arm-check geprüft, für jedes FEHLT eine Alternative gefunden
• Programme außerhalb von Docker und Herstellerrepositorys auf arm64-Versionen geprüft
• eigene Images für beide Plattformen gebaut
• kein Windows und keine x86-Software, die nur als Binärdatei vorliegt
• Umzug mit rsync geplant, siehe Teil 1

Typische Fehler

• exec format error beim Start eines Containers: Das Image besteht nur aus einer amd64-Variante. Prüfen Sie es mit arm-check und suchen Sie eine Alternative.
• no matching manifest for linux/arm64/v8 beim Herunterladen: Das Image hat eine Plattformliste, aber keine arm64-Variante darin.
• Ein Image läuft auf ARM, aber auffällig langsam: Prüfen Sie, ob auf dem Server eine Emulation aktiv ist. Steht in /proc/sys/fs/binfmt_misc/ ein Eintrag qemu-x86_64, startet Docker amd64-Images emuliert, statt mit exec format error abzubrechen.
• apt findet nach dem Umzug keine Pakete aus einer Fremdquelle: In der Quelle steht noch arch=amd64. Ändern Sie sie auf arch=arm64 oder richten Sie sie neu ein.
• arm-check meldet linux/unbekannt: Name oder Tag sind falsch geschrieben, die Registry verlangt eine Anmeldung, oder der Dienst wird mit build: selbst gebaut. Prüfen Sie das Image mit docker buildx imagetools inspect direkt.

Häufige Fragen

Wie komme ich von meinem x86-VPS auf ARM?

Die ARM-Server sind bei netcup eigene Tarife. Planen Sie den Wechsel als Umzug auf einen neuen Server, wie in Teil 1 beschrieben.

Reicht es, wenn das Image arm/v7 anbietet?

Das ist nicht gleichwertig, denn arm/v7 ist eine 32-Bit-Variante. Achten Sie auf linux/arm64.

Was mache ich mit einem Image, das nur amd64 hat?

Suchen Sie ein gleichwertiges Image mit arm64-Variante, bauen Sie es aus dem Quellcode selbst für arm64 oder betreiben Sie diesen Dienst weiter auf einem x86-Server.

Muss ich den Tag latest besonders beachten?

Ja. Der Inhalt von latest ändert sich mit jeder neuen Version. Prüfen Sie vor dem Umzug genau den Tag, den Sie dann auch einsetzen.

Fazit

Ob Ihre Dienste auf einem netcup-ARM-Server laufen, können Sie schon vor der Bestellung klären. Die Registry verrät für jedes Image die Plattformen, arm-check prüft eine ganze Compose-Datei in einem Durchgang. In unserem Test hatten elf der zwölf geprüften Selfhosting-Images eine arm64-Variante. Kritisch sind einzelne Images nur für amd64 und Programme, die Sie von Hand installiert haben. Emulation hilft beim Bauen, nicht im Betrieb.

Weiterführende Anleitungen und Quellen

• Teil 1: Von G12 auf G12.5 umziehen
• Docker Compose unter Linux: die Grundlage
• netcup: ARM-Server
• Docker: Multi-platform builds
• tonistiigi/binfmt auf GitHub