Nixpacks vs. Dockerfile: Welchen Build sollten Sie verwenden?

Die Entscheidung Nixpacks vs. Dockerfile legt fest, wer für die Build-Definition verantwortlich ist. Nixpacks leitet aus einem konventionell aufgebauten Repository einen Build-Plan ab, während der Autor eines Dockerfiles die einzelnen Schritte zur Erstellung des Images definiert. Dockup unterstützt beide Varianten: Ein Dockerfile im Repository hat Vorrang, Nixpacks dient automatisch als Fallback, wenn kein Dockerfile vorhanden ist.

Keine der beiden Optionen ist grundsätzlich professioneller. Der richtige Build ist derjenige, den Ihr Team ohne unnötige Komplexität reproduzieren, debuggen, absichern und warten kann.

Wie funktioniert die automatische Build-Erkennung mit Nixpacks?

Nixpacks untersucht die Dateien eines Repositorys, um das Anwendungs-Ökosystem, die Installations-, Build- und Startphase sowie benötigte Pakete zu erkennen. Zu den gängigen Signalen gehören Paket-Manifeste, Lockfiles, Framework-Konfigurationen und bekannte Projektstrukturen.

Bei einem Dockup-Service wird die automatische Erkennung verwendet, wenn das Repository kein Dockerfile enthält. Ein erster Deploy kann daher so einfach aussehen:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --deploy \
  --wait \
  --json

Das Fehlen von --dockerfile ist kein Fehler. Dockup klont das Repository und lässt Nixpacks den Build-Plan erstellen.

Die automatische Build-Erkennung funktioniert am besten, wenn das Projekt den Konventionen seines Ökosystems folgt:

• Abhängigkeiten sind im Standard-Manifest deklariert.
• Ein Lockfile ist eingecheckt.
• Das reguläre Build-Script trägt den üblichen Namen.
• Die Anwendung wird mit einem Standard-Script gestartet.
• Der Port lässt sich über die Runtime-Umgebung konfigurieren.
• Native Abhängigkeiten sind für den Provider ausreichend verbreitet, um erkannt zu werden.

Nixpacks reduziert den Umfang des Infrastruktur-Codes, den ein kleines Team selbst verwalten muss. Ein Framework-Update kann dadurch häufig eine reine Anwendungsänderung bleiben, ohne dass ein Container neu geschrieben werden muss.

Das offizielle Nixpacks-Modell umfasst eine Planungs- und eine Build-Phase. Für lokale Untersuchungen kann die Nixpacks CLI den generierten Plan ausgeben oder ausführen. In Dockup sind die Build-Logs weiterhin die erste Anlaufstelle, um zu prüfen, was die Plattform ausgewählt hat.

Welche Kontrolle bietet ein Docker-Build?

Ein Dockerfile definiert das Base-Image und jeden wesentlichen Schritt zur Erstellung des Images. Es eignet sich besser, wenn sich die Runtime nicht zuverlässig über Konventionen beschreiben lässt.

Typische Gründe dafür sind:

• Ein privates oder spezialisiertes Base-Image.
• Betriebssystempakete, die nicht automatisch erkannt werden.
• Eine Kompilierung mit mehreren Stages.
• Mehrere Anwendungen in einem Repository mit ungewöhnlichen Grenzen für COPY.
• Ein eigener Runtime-Benutzer ohne Root-Rechte.
• Abhängigkeiten für Browser, Medien, Machine Learning oder native Bibliotheken.
• Ein exakt vorgegebenes Entrypoint- oder Init-Verhalten.
• Compliance-Anforderungen an die Herkunft des Base-Images.

Ein minimales Node.js-Beispiel ist explizit und dennoch gut wartbar:

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
CMD ["node", "dist/server.js"]

Wenn diese Datei am erwarteten Speicherort eingecheckt ist, verwendet Dockup sie anstelle von Nixpacks. Einen abweichenden Pfad können Sie bei der Erstellung des Services mit der dokumentierten Option --dockerfile angeben.

Kontrolle schafft Verantwortung. Das Team ist nun für Updates des Base-Images, die Paketinstallation, das Layer-Caching, kopierte Dateien, Benutzerberechtigungen, das Entrypoint-Verhalten und die Architekturkompatibilität zuständig.

Wie unterscheiden sich Nixpacks und Dockerfile?

Die praktischen Unterschiede sind unten zusammengefasst:

Entscheidungsbereich	Nixpacks	Dockerfile
Ersteinrichtung	In der Regel keine	Image-Anweisungen schreiben und prüfen
Build-Erkennung	Automatisch	Vollständig explizit
Gängige Frameworks	Sehr gut geeignet	Funktioniert, kann aber überflüssig sein
Anpassung des Betriebssystems	Auf unterstützte Konfiguration beschränkt	Vollständige Kontrolle
Base-Image	Vom Build-System ausgewählt	Vom Repository ausgewählt
Builds mit mehreren Stages	Generierte Strategie	Vom Autor definiert
Debugging-Quelle	Generierter Plan und Build-Logs	Dockerfile-Zeile und Build-Logs
Wartung	Provider und Anwendungskonventionen	Anwendungsteam
Portabilität	Hängt von der Verfügbarkeit von Nixpacks ab	Standardmäßiger Container-Build
Sicherheitsverantwortung	Zwischen Build-System und Team geteilt	Vor allem beim Image-Autor
Verantwortung für den Startbefehl	Aus Konventionen generiert	Vom Image-Autor festgelegt
Beste Verwendung	Konventionelle Anwendung	Spezialisierte Runtime

Bei der Entscheidung Nixpacks vs. Dockerfile geht es nicht um „automatisch versus reproduzierbar“. Beide Varianten können reproduzierbar sein, wenn Abhängigkeiten gesperrt und die Umgebung kontrolliert werden. Es geht um „generierter Plan versus vom Repository verwalteter Plan“.

Für einen standardmäßigen Node-, Python-, Go-, Ruby-, PHP- oder ähnlichen Webservice sollten Sie mit Nixpacks beginnen und erst dann ein Dockerfile hinzufügen, wenn eine konkrete Anforderung auftritt. Für einen spezialisierten Worker mit nativen Bibliotheken kann ein explizites Dockerfile langfristig schon ab dem ersten Tag die einfachere Wahl sein.

Welcher Build lässt sich leichter debuggen und reproduzieren?

Beginnen Sie mit der Build-Ausgabe der Plattform:

dockup logs production/api --build --json

Oder verfolgen Sie die Ausgabe live:

dockup logs production/api --build -f --json

Bei Nixpacks sollten Sie das erkannte Ökosystem, den Installationsbefehl, den Build-Befehl und den Startbefehl prüfen. Ein Fehler entsteht häufig durch ein fehlendes Lockfile, ein unerwartetes Monorepo-Root, einen vom üblichen Muster abweichenden Script-Namen oder ein natives Paket, das eine Betriebssystemabhängigkeit benötigt.

Bei einem Dockerfile sollten Sie die fehlerhafte Anweisung und den Build-Kontext untersuchen. Häufige Probleme sind:

• .dockerignore schließt eine benötigte Datei aus.
• Eine Paketinstallation läuft, bevor das relevante Manifest kopiert wurde.
• In der Runtime-Stage fehlt ein kompiliertes Artefakt.
• Der Container lauscht nur auf localhost.
• Das Image startet mit einem Benutzer, der keine Berechtigung zum Lesen kopierter Dateien hat.
• Das Base-Image unterstützt die benötigte Architektur nicht.
• Build-Secrets wurden versehentlich in ein Layer eingebaut.

Reproduzierbarkeit erfordert mehr als nur die Build-Definition. Fixieren Sie Anwendungsabhängigkeiten über Lockfiles. Wählen Sie bewusst Tags für Base-Images. Vermeiden Sie den Download nicht versionierter Binaries. Stellen Sie sicher, dass Builds nicht von Dateien abhängen, die nur auf einem einzelnen Laptop vorhanden sind.

Dockup kann Build- und Startbefehle eines Services überschreiben:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Verwenden Sie Overrides, um eine kleine Abweichung von einer Konvention zu korrigieren. Wenn sich viele individuelle Anforderungen ansammeln, sollten Sie sie in ein geprüftes Dockerfile oder eine klare Repository-Konfiguration verschieben, statt den Build im Dashboard-Zustand zu verbergen.

Wie unterscheiden sich Sicherheit und Image-Wartung?

Jeder Build-Weg erzeugt letztlich ein Image, das gescannt und gewartet werden muss. Dockup prüft das Image bei jedem Deploy auf bekannte CVEs und führt Konfigurationsprüfungen durch:

dockup security production/api --json
dockup security scan production/api --json

Nixpacks-Nutzer sollten die generierte Runtime-Auswahl prüfen, Anwendungsabhängigkeiten aktualisieren und Sicherheitsergebnisse beobachten. Automatisch bedeutet nicht wartungsfrei.

Dockerfile-Nutzer sind zusätzlich verantwortlich für:

1. Auswahl und Aktualisierungsrhythmus des Base-Images.
2. Ausführung mit einem Benutzer ohne Root-Rechte, sofern praktikabel.
3. Secrets aus ARG, ENV und kopierten Dateien heraushalten.
4. Trennung von Build-Tools und Runtime-Stage.
5. Fixierung von Paketen, wenn dies für die Stabilität erforderlich ist.
6. Minimierung unnötiger Betriebssystempakete.
7. Validierung von Health-Checks und Signalverarbeitung.

Bauen Sie Secrets niemals in ARG, ENV, kopierte Dateien oder Build-Logs ein. Die Image-Definition sollte gefahrlos geprüft und neu erstellt werden können, ohne Produktionszugangsdaten einzubetten.

Der Artikel Security Best Practices behandelt die umfassendere Produktionssicherheit. Die Wahl des Builds ersetzt weder das Secret-Management zur Laufzeit noch das Prinzip der geringsten Privilegien.

Wann sollten Sie von einer Build-Methode zur anderen wechseln?

Der Wechsel von Nixpacks zu Dockerfile ist gerechtfertigt, wenn wiederholte Workarounds für automatische Builds schwerer verständlich werden als ein explizites Image. Warnsignale sind:

• Mehrere nicht dokumentierte Overrides für Build-Befehle.
• Native Pakete, die nach Änderungen an der Umgebung immer wieder fehlschlagen.
• Die Notwendigkeit, dasselbe Image lokal, in CI und auf mehreren Plattformen zu standardisieren.
• Strenge Anforderungen an Base-Image oder Benutzer.
• Eine Monorepo-Struktur, die von der automatischen Erkennung wiederholt falsch interpretiert wird.
• Große Images, die eine gezielte Optimierung mit mehreren Stages erfordern.

Der Migrationsprozess ist kontrolliert:

1. Erfassen Sie das erfolgreiche Build- und Startverhalten von Nixpacks.
2. Schreiben Sie ein Dockerfile, das dieses Verhalten lokal reproduziert.
3. Behalten Sie denselben Anwendungsport und dieselbe Health-Route bei.
4. Deployen Sie auf einen Preview- oder nicht produktiven Service.
5. Vergleichen Sie Logs, Startzeit, Sicherheitsergebnisse des Images und Smoke-Tests.
6. Checken Sie das Dockerfile ein und deployen Sie mit --wait.
7. Bewahren Sie eine bekannte vorherige Deployment-ID zur Wiederherstellung auf.

Auch ein Wechsel von Dockerfile zurück zu Nixpacks kann sinnvoll sein. Eine veraltete Container-Definition kann obsolete Base-Images, unnötige Pakete oder kopierte Secrets enthalten. Entfernen Sie sie erst, nachdem Sie validiert haben, dass Nixpacks die korrekten Installations-, Build-, Start- und Port-Einstellungen erkennt.

Verwenden Sie die Deployment-Historie zur Wiederherstellung:

dockup deployments production/api -n 20 --json
dockup rollback <deploymentId> production/api --json

Der Leitfaden vom Git-Repository zur Produktionsumgebung beschreibt den umgebenden Release-Workflow.

Empfehlungen nach Workload

Workload	Empfehlung für den Einstieg	Neu bewerten, wenn
Konventionelle Web-API	Nixpacks	Der Bedarf an nativen Paketen oder OS-Anpassungen wächst
Statisches Frontend, das von einem Anwendungsprozess ausgeliefert wird	Nixpacks	Eine eigene Server-/Image-Richtlinie erforderlich ist
Kompilierter Go-Service	Nixpacks oder Dockerfile	Eine exakte Scratch-/Distroless-Runtime gewünscht ist
Browser-Automatisierung	Dockerfile	Benötigte Browserpakete standardisiert sind
Machine-Learning-Inferenz	Dockerfile	Runtime-Image und native Bibliotheken kontrolliert werden müssen
Monorepo-Service	Zunächst Nixpacks	Die Erkennung den korrekten Workspace nicht isolieren kann
Eigenes Base-Image	Dockerfile	sich Base-Image-Richtlinie oder Runtime-Anforderungen ändern
Kleiner Prototyp	Nixpacks	der Prototyp zu einem spezialisierten Produktionsservice wird

Kosten und Auswirkungen auf den Betrieb

Die Abrechnung bei Dockup basiert auf dem pro Minute gemessenen Verbrauch von CPU, RAM und Festplattenspeicher, nicht darauf, ob der Build mit Nixpacks oder einem Dockerfile erstellt wurde. Die Build-Wahl kann die Runtime-Kosten dennoch indirekt beeinflussen, etwa durch Image-Größe, installierte Prozesse, Speicherverbrauch und Startverhalten.

Ein unnötig großes Image erhöht den Aufwand für Übertragung und Speicherung. Eine Runtime, die Build-Tools enthält, vergrößert die Angriffsfläche. Umgekehrt kann ein überoptimiertes Dockerfile viel Entwicklungszeit kosten, ohne den eigentlichen Service zu verbessern.

Prüfen Sie den CPU-, RAM- und Festplattenverbrauch in app.dockup.ai. Der empfohlene Pro-Tarif kostet 20 $ pro Monat und enthält ein Nutzungsguthaben von 20 $; kostenpflichtige Tarife erlauben unbegrenzt viele Workspaces, Datenbanken und Deployments.

Eine abschließende Entscheidungsregel für Nixpacks vs. Dockerfile

Wählen Sie Nixpacks, wenn das Repository konventionell aufgebaut ist und der generierte Plan verständlich bleibt. Wählen Sie Dockerfile, wenn die Anwendung eine stabile Anforderung hat, die explizit abgebildet werden muss. Wechseln Sie nicht, nur weil eine Option anspruchsvoller klingt.

Das zuverlässigste Ergebnis bei Nixpacks vs. Dockerfile ist der Build, den Ihr Team aus einem sauberen Repository reproduzieren, während eines Incidents erklären, aktuell halten und über ein Health-gated Deployment verifizieren kann.

Lesen Sie die Dockup CLI-Referenz für die aktuellen Befehle zur Erstellung, zu Build-Einstellungen, Logs und Sicherheit. Der Leitfaden für Zero-Downtime-Deployments erklärt, wie beide Image-Typen den Readiness-Gate für die Produktion durchlaufen.

Berücksichtigen Sie die Verantwortlichkeit bei Fehlern

Ein Build-System ist zugleich ein Modell dafür, wer für Fehler verantwortlich ist. Bei Nixpacks lautet die erste Frage, ob die Erkennung den richtigen Provider und die richtigen Phasen ausgewählt hat. Bei einem Dockerfile lautet die erste Frage, ob die Repository-Anweisungen und der Build-Kontext korrekt sind.

Erstellen Sie eine kurze Eskalationsübersicht:

Fehler	Untersuchung bei Nixpacks	Untersuchung beim Dockerfile
Installation von Abhängigkeiten	Manifest, Lockfile, erkannter Paketmanager	Reihenfolge von COPY und Installationsanweisung
Build-Script fehlt	Übliche Script-Namen oder Override	RUN-Befehl und Arbeitsverzeichnis
Native Bibliothek fehlt	Unterstützte Pakete oder Wechsel zu Dockerfile	Basisdistribution und Paketmanager
Runtime-Artefakt fehlt	Generierte Build-/Startphasen	Pfad von COPY --from bei mehreren Stages
Falscher Port	Service-Port und Application-Binding	CMD, Umgebungsvariablen und Application-Binding
Keine Berechtigung	Generierter Runtime-Benutzer bzw. Dateien	USER, Eigentümer und Modi kopierter Dateien
Base-Image nicht verfügbar	Erkannte Runtime oder Provider-Auswahl	FROM-Image und Tag im Dockerfile
Image zu groß	Generierter Plan und Abhängigkeiten	Layer-Design und Runtime-Stage

Diese Tabelle hilft einem Agenten, nicht die falsche Lösung zu wählen. Das Hinzufügen eines Dockerfiles korrigiert keine Anwendung ohne gültiges Start-Script. Das Umschreiben von Package-Scripts behebt kein explizites Image, in dem das kompilierte Ergebnis nicht kopiert wurde.

Bewerten Sie lokale Parität realistisch

Ein Dockerfile ist attraktiv, weil Entwickler lokal dasselbe Image ausführen können. Parität entsteht jedoch nicht automatisch. Die Produktionsplattform stellt weiterhin Umgebungsvariablen, Domains, Networking, Volumes, Ressourcenlimits und Health-Checks außerhalb des Images bereit.

Auch Nixpacks lässt sich lokal mit den entsprechenden Tools testen. Entscheidend ist jedoch die Verhaltensparität: Versionen der Abhängigkeiten, Build-Ergebnis, Startbefehl, Listening-Port und benötigte Runtime-Dateien.

Für beide Build-Varianten gilt:

1. Bauen Sie aus einem sauberen Clone.
2. Entfernen Sie nicht deklarierte globale Tools vom Testsystem.
3. Starten Sie mit produktionsähnlichen Environment-Keys, aber mit Dummy-Werten.
4. Binden Sie denselben Container-Port.
5. Rufen Sie den echten Readiness-Pfad auf.
6. Beenden Sie den Prozess und bestätigen Sie die korrekte Signalverarbeitung.
7. Erstellen Sie den Build nach dem Löschen der Caches erneut.

Ein reproduzierbarer Clean Build ist unabhängig von der Entscheidung Nixpacks vs. Dockerfile ein stärkerer Beleg als „Funktioniert auf meinem Rechner“.

Berücksichtigen Sie Grenzen im Monorepo

Monorepos führen zu Unklarheiten beim Anwendungs-Root, beim Dependency-Graphen und beim Speicherort von Artefakten. Die automatische Erkennung findet möglicherweise das Manifest auf oberster Ebene, obwohl der Service mehrere Verzeichnisse tiefer liegt. Ein Dockerfile kann versehentlich das gesamte Repository kopieren und dadurch bei jeder unabhängigen Änderung das Caching ungültig machen.

Dokumentieren Sie vor der Entscheidung:

• Das Service-Root.
• Gemeinsame Pakete, die zur Build-Zeit benötigt werden.
• Den Speicherort des Lockfiles.
• Den Build-Befehl und das Ausgabeverzeichnis.
• Dateien, die nur für Tests benötigt werden.
• Das Arbeitsverzeichnis zur Laufzeit.
• Den Pfad, der als Docker-Build-Kontext verwendet wird.

Wenn ein kleines Override für den Build-Befehl den vorgesehenen Workspace eindeutig macht, kann Nixpacks weiterhin geeignet sein. Wenn der Build mehrere Workspace-spezifische Copy- und Compile-Stages benötigt, kann ein Dockerfile diese Grenze ehrlicher abbilden.

Lösen Sie Monorepo-Unklarheiten nicht, indem Sie Secrets oder lokale .env-Dateien in den Build-Kontext kopieren. Runtime-Secrets gehören in die Dockup-Umgebungskonfiguration.

Prüfen Sie Start- und Shutdown-Verhalten

Ein erfolgreicher Image-Build ist nur die Mitte des Releases. Der Container muss den vorgesehenen Prozess starten, am konfigurierten Port lauschen, im Vordergrund laufen und beendet werden, wenn die Plattform ein Termination-Signal sendet.

Achten Sie auf folgende Fehlermuster:

• Ein Shell-Script startet den Server im Hintergrund und beendet sich.
• Ein Development-Server lauscht nur auf 127.0.0.1.
• Der Prozess ignoriert die Beendigung und verzögert den Austausch.
• Migrationen laufen bei jedem Neustart des Containers ohne Locking erneut.
• Der Startbefehl startet einen für die Entwicklung vorgesehenen Watcher.
• Ein Dockerfile verwendet ein CMD in Shell-Form, wodurch die Signalweiterleitung verändert wird.

Nixpacks generiert die Startphase aus Framework-Konventionen, während der Autor bei einem Dockerfile CMD oder ENTRYPOINT festlegt. Konfigurieren Sie in beiden Fällen den Dockup-Service-Port und einen aussagekräftigen Health-Gate:

dockup set production/api --port 3000 --json
dockup health production/api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Das Image ist erst produktionsbereit, wenn dieses Runtime-Verhalten vorhersehbar ist.

Erstellen Sie eine Release-Richtlinie für Build-Änderungen

Behandeln Sie den Wechsel zwischen Nixpacks und Dockerfile als Infrastrukturänderung, auch wenn der Anwendungscode unverändert bleibt. Die Änderung sollte von jemandem geprüft werden, der die Runtime versteht. Führen Sie ein Preview-Deployment durch und vergleichen Sie die Sicherheitsergebnisse vor dem Produktions-Deploy.

Der Änderungsnachweis sollte enthalten:

1. Bisherige Build-Methode.
2. Grund für den Wechsel.
3. Base-Image oder erkannte Runtime.
4. Build- und Startbefehle.
5. Sicherheitsbewertung des Images und Findings mit hoher Schwere.
6. Ergebnis des Health-Checks.
7. Ergebnis des Runtime-Smoke-Tests.
8. Vorherige Deployment-ID zur Wiederherstellung.

Diese Richtlinie verhindert, dass ein als „Aufräumarbeit“ gedachtes Dockerfile unbemerkt das Verhalten von Node, Python, Systembibliotheken oder Zertifikaten ändert. Sie verhindert außerdem, dass ein altes Dockerfile entfernt wird, bevor der automatische Plan validiert wurde.

Die Entscheidung Nixpacks vs. Dockerfile kann später neu bewertet werden. Richten Sie sie an den aktuellen Anforderungen aus, nicht an der Identität des Teams.

Machen Sie die Entscheidung sichtbar

Halten Sie die gewählte Build-Methode im Runbook des Services und im Pull-Request-Template fest. Reviewer sollten erkennen können, ob ein neues Dockerfile Nixpacks bewusst ersetzt oder versehentlich hinzugefügt wurde. Dieser eine Hinweis verhindert stille Änderungen an der Build-Verantwortung.

Bewerten Sie Fakten statt Teamzugehörigkeit

Ein Team ist weder „ein Dockerfile-Team“ noch „ein Nixpacks-Team“. Bewerten Sie den Build neu, sobald sich die Anforderungen ändern.

Beginnen Sie mit einem überprüfbaren Deployment

Deployen Sie zunächst den einfachsten repräsentativen Service mit Nixpacks. Führen Sie erst dann ein Dockerfile ein, wenn eine messbare Anforderung die explizite Kontrolle über das Image wertvoll macht.

Kostenlos bei app.dockup.ai starten. Der Free-Tarif kostet 0 $ pro Monat, enthält ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Bevorzugt Dockup ein Dockerfile gegenüber Nixpacks?

Ja. Wenn ein Repository ein Dockerfile enthält, verwendet Dockup dieses. Wenn kein Dockerfile vorhanden ist, greift Dockup auf die automatische Build-Erkennung von Nixpacks zurück.

Ist Nixpacks für den Produktionseinsatz geeignet?

Ja, sofern die Anwendung unterstützten Konventionen folgt, das generierte Build-Verhalten verstanden wurde, die Abhängigkeitsversionen gesperrt sind und die produktiven Health- und Sicherheitsprüfungen erfolgreich abgeschlossen werden.

Wann sollte ich ein Dockerfile schreiben?

Verwenden Sie ein Dockerfile, wenn Sie ein explizites Base-Image, Betriebssystempakete, eine Kompilierung mit mehreren Stages, einen eigenen Runtime-Benutzer, ein ungewöhnliches Monorepo-Verhalten oder eine andere präzise Kontrolle über das Image benötigen.

Wie debugge ich einen Dockup-Build?

Lesen Sie die neuesten Build-Logs mit dockup logs --build --json oder verfolgen Sie sie mit --build -f --json. Trennen Sie Probleme bei der Erkennung von Fehlern in Dockerfile-Anweisungen.

Verändert die Build-Methode die Preise bei Dockup?

Nein. Für Nixpacks gegenüber Dockerfile wird kein direkter Aufpreis berechnet. CPU, RAM und Festplattenverbrauch werden pro Minute gemessen, auch wenn das Image-Design den tatsächlichen Ressourcenverbrauch beeinflussen kann.