6 Εναλλακτικές του Dockerfile (Και Πότε Δεν Χρειάζεσαι Κανένα) [2026]

6 Εναλλακτικές του Dockerfile (Και Πότε Δεν Χρειάζεσαι Κανένα) [2026]

Αν άνοιξες αυτό το άρθρο επειδή η συγγραφή ενός Dockerfile σου φαίνεται αγγαρεία, καλά νέα: το 2026 οι περισσότερες εφαρμογές δεν χρειάζονται κανένα. Στο Railway, το προεπιλεγμένο εργαλείο build είναι πλέον το Railpack, όχι μια χειρόγραφή εικόνα node:20-slim. Εργαλεία όπως το Railpack και τα Cloud Native Buildpacks διαβάζουν τον κώδικά σου, ανιχνεύουν τη γλώσσα και παράγουν την εικόνα container για εσένα. Άρα το πραγματικό ερώτημα δεν είναι «πώς γράφω ένα Dockerfile;» Είναι «ποια από αυτές τις εναλλακτικές του Dockerfile ταιριάζει στην εφαρμογή μου;» Ας το ξεκαθαρίσουμε.

Γρήγορη απάντηση:

• Συνήθως δεν χρειάζεται να γράψεις χειροκίνητα ένα Dockerfile. Οι zero-config builders ανιχνεύουν τον κώδικά σου και φτιάχνουν την εικόνα για εσένα.
• Στο Railway, το Railpack είναι πλέον η προεπιλογή (το Nixpacks είναι σε κατάσταση συντήρησης). Το Heroku Fir και το Paketo χρησιμοποιούν Cloud Native Buildpacks.
• Τα static sites (Astro, Next export, απλό HTML) συχνά δεν χρειάζονται καθόλου build container.

Χρειάζεσαι Κανένα Dockerfile;

Όχι, συνήθως δεν χρειάζεται να γράψεις Dockerfile. Αν κάνεις deploy σε μια πλατφόρμα όπως το Railway, το Render ή το Heroku, ένας zero-config builder (Railpack, Nixpacks ή Cloud Native Buildpacks) ανιχνεύει τη γλώσσα σου και φτιάχνει την εικόνα για εσένα. Γράψε Dockerfile μόνο όταν χρειάζεσαι λεπτομερή έλεγχο.

Αυτή είναι η ανατροπή που χάνουν οι περισσότεροι οδηγοί. Ένα Dockerfile είναι ένα αρχείο κειμένου γεμάτο οδηγίες (FROM, COPY, RUN) που λέει στο Docker ακριβώς πώς να συναρμολογήσει την εικόνα σου, στρώμα προς στρώμα. Είναι πανίσχυρο, αλλά γράφεις και συντηρείς ο ίδιος κάθε γραμμή. Οι zero-config builders το αντιστρέφουν αυτό: επιθεωρούν το package.json ή το requirements.txt, μαντεύουν τη σωστή βασική εικόνα και τις εντολές και χτίζουν χωρίς να γράψεις εσύ τίποτα.

Άρα η επιλογή buildpacks ή Dockerfile συνήθως καταλήγει σε έλεγχο εναντίον ευκολίας. Η ίδια η σύγκριση μεθόδων containerization της Google Cloud καταλήγει στον ίδιο διαχωρισμό: buildpacks για ταχύτητα και συνέπεια, Dockerfile όταν χρειάζεται να λυγίσεις τους κανόνες.

Θέλεις ακόμα ένα πραγματικό Dockerfile όταν χρειάζεσαι μια custom βασική εικόνα, συγκεκριμένα πακέτα συστήματος (σκέψου το ffmpeg ή κάποια περίεργη βιβλιοθήκη C) ή ακριβή multi-stage έλεγχο για να κόψεις megabyte. Όλα τα υπόλοιπα; Ένας builder πιθανότατα τα χειρίζεται. Πλατφόρμες όπως το Modal το πάνε παραπέρα, αφού το Modal χτίζει εικόνες από τον κώδικά σου χωρίς καθόλου Dockerfile.

Το Dockerfile δεν είναι πια ο προεπιλεγμένος τρόπος για να χτίσεις ένα container. Είναι η διέξοδος κινδύνου για όταν το zero-config δεν αρκεί.

Οι 6 Εναλλακτικές του Dockerfile με μια Ματιά

Ορίστε όλες οι μέθοδοι δίπλα-δίπλα, για να τις σκανάρεις πριν διαβάσεις. (Ναι, το «να γράψεις Dockerfile» είναι στη λίστα. Παραμένει μία από τις επιλογές σου, απλά όχι η μόνη.)

Τώρα οι έξι λεπτομερώς. Η καθεμία έχει ένα απλό «τι είναι» και ένα ξεκάθαρο «διάλεξέ το αν».

1. Dockerfile (Πλήρης Χειροκίνητος Έλεγχος)

Το Dockerfile είναι η αρχική, γράφεις-κάθε-οδηγία βάση. Είναι ένα script που λέει: ξεκίνα από αυτή τη βασική εικόνα, αντιγραψε αυτά τα αρχεία, τρέξε αυτές τις εντολές, άνοιξε αυτή τη θύρα. Τίποτα δεν ανιχνεύεται για εσένα, κι αυτό ακριβώς είναι το νόημα.

Επειδή ελέγχεις κάθε στρώμα, ένα βελτιστοποιημένο Dockerfile μπορεί να παράγει τη μικρότερη εικόνα από κάθε μέθοδο εδώ. Ένα multi-stage build (μεταγλώττιση σε ένα μεγάλο builder stage, αντιγραφή μόνο του αποτελέσματος σε ένα μικροσκοπικό τελικό stage) είναι ο τρόπος που οι ομάδες ρίχνουν μια εικόνα Node κοντά στα 120 MB. Το layer caching κρατά τα rebuild γρήγορα μόλις ολοκληρωθεί το πρώτο build.

Το κόστος είναι η συντήρηση. Εσύ αναλαμβάνεις τις ενημερώσεις της βασικής εικόνας, τα security patch και κάθε ιδιοτροπία. Για μια εφαρμογή Express πέντε γραμμών, αυτό είναι υπερβολή. Για μια εφαρμογή που χρειάζεται ένα συγκεκριμένο πακέτο OS ή έναν καρφιτσωμένο compiler, είναι η μόνη τίμια επιλογή.

Διάλεξέ το αν χρειάζεσαι μια custom βασική εικόνα, συγκεκριμένες εξαρτήσεις συστήματος ή ακριβή multi-stage έλεγχο στο τελικό μέγεθος της εικόνας σου.

2. Railpack: Η Zero-Config Προεπιλογή του Railway

Το Railpack είναι το open-source (MIT) εργαλείο build του Railway και, σύμφωνα με τα docs του Railway, είναι πλέον η προεπιλογή: «Το Railway χρησιμοποιεί το Railpack για να χτίζει και να κάνει deploy τον κώδικά σου χωρίς καμία ρύθμιση.» Είναι χτισμένο πάνω στο BuildKit (η σύγχρονη μηχανή build του Docker) και χρησιμοποιεί το Mise για να καρφιτσώνει τις εκδόσεις γλωσσών. Το Railway το ανακοίνωσε τον Μάρτιο του 2025 ως διάδοχο του Nixpacks και το repo του Railpack δείχνει ενεργές κυκλοφορίες μέχρι το 2026. Δεν πρόκειται για κάποιο παράπλευρο project σε beta.

Να γιατί έχει σημασία: το Railway λέει ότι το Railpack παράγει βασικές εικόνες περίπου 38% μικρότερες για Node και 77% μικρότερες για Python σε σχέση με το Nixpacks, χάρη στο καλύτερο διαχωρισμό στρωμάτων του BuildKit. Διάβασε την πλήρη αναμέτρηση Nixpacks εναντίον Docker αν θέλεις το βαθύ «γιατί» πίσω από αυτούς τους αριθμούς· κρατάμε τα εσωτερικά εκεί, ώστε αυτό το άρθρο να μένει μια σύνοψη.

Οι μικρότερες εικόνες δεν είναι απλά τακτοποιημένες. Κατεβαίνουν γρηγορότερα, κάνουν cold-start γρηγορότερα και κοστίζουν λιγότερο σε αποθήκευση και μετακίνηση, κάτι που μετράει όταν κρατάς χαμηλά το κόστος cloud. Μπορείς να μείνεις πλήρως zero-config ή να ρίξεις ένα railpack.json για να παρακάμψεις εκδόσεις και εντολές όταν το χρειαστείς.

railpack build

Διάλεξέ το αν κάνεις deploy στο Railway ή θέλεις τη μικρότερη zero-config εικόνα με ενσωματωμένο BuildKit caching.

3. Nixpacks: Ο Παλιότερος Zero-Config Builder

Το Nixpacks ήταν η προηγούμενη προεπιλογή του Railway και παραμένει ένας ικανός zero-config builder με ευρεία αυτόματη ανίχνευση γλωσσών (Node, Python, Go, PHP και άλλα). Αν το stack σου χρησιμοποιεί κάτι εξειδικευμένο που το Railpack δεν ανιχνεύει ακόμα, το Nixpacks μπορεί να το αναγνωρίσει.

Μία τίμια επιφύλαξη: βρίσκεται σε maintenance mode. Το README του repo του Nixpacks το λέει πλέον ευθέως και προτείνει το Railpack ως αντικαταστάτη. Δεν έχει πεθάνει. Ακόμα δουλεύει και ακόμα χτίζει· απλά δεν αποκτά νέα χαρακτηριστικά. Οι εικόνες του Nixpacks επίσης βγαίνουν μεγάλες, λόγω του τρόπου που στρώνει το Nix store στην τελική εικόνα. Αυτός είναι ένας γνωστός συμβιβασμός και αναλύουμε την πλήρη ιστορία στη βαθιά μας σύγκριση Nixpacks εναντίον Docker αντί να την ξαναπαράγουμε εδώ.

Άρα θεώρησε το Nixpacks ως την επιλογή «υποστηρίζεται ακόμα, αλλά ορίστε ο διάδοχος». Τα νέα project στο Railway παίρνουν αυτόματα το Railpack· θα κατέφευγες στο Nixpacks κυρίως σε κάποιο παλιό setup.

Διάλεξέ το αν είσαι σε κάποια παλιά ρύθμιση του Railway ή χρειάζεσαι μια γλώσσα που το Railpack δεν ανιχνεύει αυτόματα ακόμα.

4. Heroku και Cloud Native Buildpacks

Η νεότερη γενιά Fir του Heroku χτίζει την εφαρμογή σου με Cloud Native Buildpacks (CNB), ένα ανοιχτό πρότυπο για τη μετατροπή πηγαίου κώδικα σε εικόνες container OCI χωρίς Dockerfile. Σύμφωνα με το Heroku Dev Center, το Fir χρησιμοποιεί τον builder heroku/builder:24. Τα κλασικά buildpacks δεν υποστηρίζονται στο Fir, οπότε ξανακάνεις deploy μια εφαρμογή Cedar στο Fir αντί να την μεταφέρεις επί τόπου.

Το ωραίο μέρος: τα CNB τρέχουν παντού, όχι μόνο στους server του Heroku. Το pack CLI από το buildpacks.io σού επιτρέπει να χτίσεις τοπικά ακριβώς την ίδια εικόνα που θα έχτιζε το Heroku στο cloud. Τα buildpacks έχουν ισχυρό caching και είναι συνθέσιμα, οπότε ένα security patch σε ένα βασικό στρώμα μπορεί να κυλήσει σε κάθε εφαρμογή χωρίς να αγγίξεις μεμονωμένα repo.

pack build myapp --builder heroku/builder:24

Αυτή η αναπαραγωγιμότητα είναι η πραγματική έλξη για τις ομάδες. Κανένα Dockerfile ανά repo που να πρέπει να συγχρονίζεις, καμία απόκλιση μεταξύ των developers.

Διάλεξέ το αν είσαι στο Heroku Fir ή θέλεις τυποποιημένα, αναπαραγώγιμα builds σε όλο τον οργανισμό χωρίς να συντηρείς ένα Dockerfile ανά project.

5. Paketo Buildpacks

Το Paketo Buildpacks είναι μια ακόμα υλοποίηση Cloud Native Buildpacks και αποτελεί project σε φάση CNCF Incubating (σύμφωνα με τη σελίδα Buildpacks του CNCF). Επειδή ακολουθεί το spec του CNB, το ίδιο Paketo build τρέχει σε οποιαδήποτε πλατφόρμα υποστηρίζει buildpacks: Cloud Foundry, Kubernetes, Tekton pipelines ή το laptop σου μέσω του pack.

Σκέψου το Paketo ως τον ανεξάρτητο-από-πλατφόρμα ξάδερφο των buildpacks του Heroku. Παίρνεις την ίδια εμπειρία «ανίχνευσε τη γλώσσα, χτίσε την εικόνα, χωρίς Dockerfile», αλλά δεν είσαι δεμένος σε έναν host. Αυτή η φορητότητα είναι ο λόγος που εμφανίζεται σε setups Kubernetes και CI/CD όπου οι ομάδες θέλουν συνεπή builds σε πολλές υπηρεσίες.

Βρίσκεται ένα σκαλί ψηλότερα στην κλίμακα ελέγχου από τα CNB του Heroku, αφού μπορείς να αναμείξεις και να ταιριάξεις buildpacks και να ρυθμίσεις τον builder.

Διάλεξέ το αν θέλεις Cloud Native Buildpacks αλλά δεν είσαι στο Heroku, για παράδειγμα σε Kubernetes, Tekton ή οποιοδήποτε ανεξάρτητο-από-πλατφόρμα build pipeline.

6. Static (Χωρίς Καθόλου Build)

Μερικές φορές η καλύτερη εναλλακτική του Dockerfile είναι να μην χτίσεις τίποτα. Αν η εφαρμογή σου μεταγλωττίζεται σε static αρχεία (ένας static site generator όπως το Astro, ένα static export του Next.js ή απλό HTML, CSS και JS) συχνά δεν χρειάζεσαι καθόλου εικόνα container.

Οι static hosts όπως το Netlify, το Cloudflare Pages, το GitHub Pages και το static tier του Vercel παίρνουν τα χτισμένα αρχεία σου και τα σερβίρουν απευθείας από CDN. Δεν υπάρχει server runtime, καμία θύρα να εκθέσεις, καμία εικόνα να στείλεις. Κάνεις push, αυτά κάνουν deploy. Είναι το γρηγορότερο και φθηνότερο μονοπάτι που υπάρχει και είναι αόρατο στις περισσότερες λίστες με «εναλλακτικές του Docker» επειδή παρακάμπτει εντελώς τα container.

Το κόλπο είναι προφανές: αυτό δουλεύει μόνο όταν δεν υπάρχει server-side runtime. Τη στιγμή που θα χρειαστείς ένα API, μια σύνδεση βάσης δεδομένων ή server-rendered σελίδες σε κάθε request, γυρίζεις πίσω σε μία από τις παραπάνω επιλογές builder.

Αν η εφαρμογή σου μεταγλωττίζεται σε static αρχεία, το γρηγορότερο container build είναι αυτό που παραλείπεις εντελώς.

Διάλεξέ το αν η έξοδός σου είναι καθαρά static αρχεία χωρίς server runtime να τρέξει.

Πώς Διαλέγεις; Ένα Απλό Δέντρο Απόφασης

Η επιλογή καταλήγει σε τέσσερις γρήγορες ερωτήσεις για την έξοδο, τις ανάγκες ελέγχου και την πλατφόρμα σου. Η static έξοδος παραλείπει τα container· η ανάγκη για λεπτό έλεγχο σημαίνει Dockerfile· αλλιώς η πλατφόρμα σου διαλέγει τον builder. Ακολούθησε τα παρακάτω κλαδιά.

• Στέλνεις ένα static site ή έξοδο SSG (HTML, Astro, Next export); → Static hosting, δεν χρειάζεται build container.
• Χρειάζεσαι λεπτομερή έλεγχο (custom βασική εικόνα, εξαρτήσεις συστήματος, multi-stage); → Dockerfile.
• Στο Railway; → Railpack (η προεπιλογή· το Nixpacks μόνο για παλιά project).
• Στο Heroku Fir; → Heroku CNB Buildpacks μέσω του heroku/builder:24.
• Οπουδήποτε αλλού, σε Kubernetes ή θέλεις φορητό CNB; → Paketo Buildpacks (ή το pack CLI).

Δεν έχεις διαλέξει καν πλατφόρμα ακόμα; Αυτή η απόφαση καθορίζει ποιον builder κληρονομείς από προεπιλογή, οπότε ξεκίνα από εκεί. Η ανάλυσή μας Railway εναντίον Render εναντίον Fly.io σε καθοδηγεί στο ερώτημα πού να κάνεις deploy πριν καν σκεφτείς μεθόδους build.

Η Γνώμη Μας: Τι Πιάνουμε Πραγματικά

Χτίσαμε την ίδια μικροσκοπική Express «hello world» με τρεις τρόπους και μετρήσαμε τον καθένα. Η εφαρμογή ήταν ίδια κάθε φορά: ένα index.js, μία εξάρτηση (Express), χωρίς κόλπα. Το τρέξαμε σε ένα Apple Silicon Mac με Docker 29.4, Nixpacks 1.41 και Railpack 0.23, χτίζοντας κάθε εικόνα από το μηδέν χωρίς cache. Να τι βγήκε:

Μερικές τίμιες σημειώσεις. Το χειρόγραφο Dockerfile κέρδισε στο μέγεθος, όπως αναμενόταν, αλλά γράψαμε και ρυθμίσαμε ένα multi-stage build για να φτάσουμε εκεί. Η εικόνα του Railpack βγήκε περίπου 40% μικρότερη από του Nixpacks (416 MB έναντι 689 MB) για την ακριβώς ίδια εφαρμογή και μηδενική ρύθμιση από εμάς, που είναι ολόκληρος ο λόγος που το Railway άλλαξε την προεπιλογή του. Το Nixpacks ήταν το βαρύτερο με μεγάλη διαφορά και μπορείς να δεις γιατί στη βαθιά μας ανάλυση Nixpacks εναντίον Docker. Θεώρησε τους χρόνους build ενδεικτικούς: είναι μεμονωμένες εκτελέσεις και κυμαίνονται ανάλογα με το caching και το δίκτυο, οπότε το μέγεθος εικόνας είναι ο αριθμός που πραγματικά εμπιστευόμαστε εδώ.

Άρα τι πιάνουμε πραγματικά; Για τα περισσότερα PaaS deploy, το Railpack. Είναι zero-config, είναι η μικρότερη zero-config εικόνα που δοκιμάσαμε και είναι ούτως ή άλλως η προεπιλογή του Railway. Γράφουμε Dockerfile μόνο όταν πραγματικά χρειαζόμαστε μια custom βασική εικόνα ή μια εξάρτηση συστήματος που ένας builder δεν θα προσθέσει. Για static έξοδο, παραλείπουμε εντελώς το container.

Στη Techsy, παίρνουμε τέτοιες αποφάσεις build-and-deploy για εφαρμογές πελατών κάθε εβδομάδα, διαλέγοντας την πλατφόρμα deployment και τη μέθοδο build που κρατούν τις εικόνες μικρές και την αποστολή γρήγορη. Αν κολλάς στο ποιο μονοπάτι ταιριάζει στο stack σου, κλείσε μια δωρεάν συμβουλή και θα το συζητήσουμε.

Σχετικά με τον Συγγραφέα

Ο Mert Batur Gurbuz είναι Συνιδρυτής του Techsy.io, όπου η ομάδα παραδίδει AI agents, συστήματα αυτοματισμού και voice/SDR pipelines για B2B πελάτες. Σπουδάζει στο Πανεπιστήμιο του Birmingham και γράφει για το LLM tooling stack που η ομάδα της Techsy χρησιμοποιεί πραγματικά στην παραγωγή. Συνδέσου στο LinkedIn.

Mert Batur Gurbuz, Συνιδρυτής, Techsy.io, Πανεπιστήμιο του Birmingham

Συχνές Ερωτήσεις

Χρειάζομαι Dockerfile;

Συνήθως όχι. Αν κάνεις deploy στο Railway, το Render ή το Heroku, ένας zero-config builder όπως το Railpack, το Nixpacks ή τα Cloud Native Buildpacks ανιχνεύει τη γλώσσα σου και χτίζει την εικόνα container για εσένα. Γράψε Dockerfile μόνο όταν χρειάζεσαι μια custom βασική εικόνα, συγκεκριμένα πακέτα συστήματος ή λεπτομερή multi-stage έλεγχο στην τελική εικόνα.

Ποια είναι η διαφορά μεταξύ Buildpacks και Dockerfile;

Ένα Dockerfile είναι ένα χειροκίνητο script όπου γράφεις ο ίδιος κάθε οδηγία build. Τα buildpacks ανιχνεύουν αυτόματα τη γλώσσα και το framework σου και μετά χτίζουν την εικόνα με μία εντολή (pack build) χωρίς να απαιτείται Dockerfile. Τα buildpacks ανταλλάσσουν μέρος του ελέγχου και του μεγέθους εικόνας με συνέπεια και μηδενική συντήρηση, που είναι η βασική επιλογή buildpacks εναντίον Dockerfile.

Είναι το Railpack καλύτερο από το Nixpacks;

Για τις περισσότερες νέες εφαρμογές στο Railway, ναι. Το Railpack είναι η τρέχουσα προεπιλογή του Railway, είναι χτισμένο πάνω στο BuildKit και παράγει αισθητά μικρότερες εικόνες (το Railway αναφέρει περίπου 38% μικρότερες για Node). Το Nixpacks ακόμα δουλεύει και ανιχνεύει ένα ευρύ σύνολο γλωσσών, αλλά βρίσκεται σε maintenance mode, οπότε το Railpack είναι η προτεινόμενη πορεία προς τα εμπρός.

Έχει πεθάνει το Nixpacks;

Όχι. Το Nixpacks βρίσκεται σε maintenance mode, δεν έχει εγκαταλειφθεί. Το ίδιο του το README στο GitHub λέει ότι δεν είναι υπό ενεργή ανάπτυξη και προτείνει το Railpack ως αντικαταστάτη. Οι υπάρχουσες εφαρμογές ακόμα χτίζονται μια χαρά και η ανίχνευση γλωσσών του είναι ευρεία, αλλά νέα χαρακτηριστικά δεν έρχονται, οπότε το Railway πλέον θέτει από προεπιλογή τα νέα project στο Railpack.

Μπορώ να κάνω deploy χωρίς κανένα βήμα build;

Ναι, αν η εφαρμογή σου είναι static. Οι static site generators (Astro, Next static export) και η έξοδος απλού HTML κάνουν deploy απευθείας σε static hosts όπως το Netlify, το Cloudflare Pages ή το GitHub Pages χωρίς καθόλου build container. Αυτό δουλεύει μόνο όταν δεν υπάρχει server runtime. Τη στιγμή που θα χρειαστείς ένα API ή server-rendered σελίδες, χρειάζεσαι έναν builder.

Τι είναι το pack CLI;

Το pack CLI είναι το επίσημο εργαλείο γραμμής εντολών από το buildpacks.io για το χτίσιμο εικόνων με Cloud Native Buildpacks τοπικά. Τρέχεις pack build myapp --builder heroku/builder:24 και παράγει την ίδια εικόνα OCI που θα έχτιζε μια πλατφόρμα όπως το Heroku στο cloud, κάτι που κάνει τις τοπικές δοκιμές και τα αναπαραγώγιμα builds απλά.

Είναι τα Buildpacks πιο αργά από τα Dockerfile;

Συχνά λίγο, στο πρώτο κρύο build, επειδή τα buildpacks ανιχνεύουν και συναρμολογούν στρώματα αυτόματα. Αλλά το layer caching ανά buildpack κάνει τα rebuild γρήγορα και ένα καλά cached buildpack build μπορεί να φτάσει ένα βελτιστοποιημένο Dockerfile. Ο μεγαλύτερος συμβιβασμός είναι το μέγεθος εικόνας και ο έλεγχος, όχι η καθαρή ταχύτητα για τις περισσότερες καθημερινές εφαρμογές.

Τι γίνεται με το Podman, είναι αυτό εναλλακτική του Dockerfile;

Όχι ακριβώς. Το Podman αντικαθιστά τη μηχανή Docker (το runtime που χτίζει και τρέχει τα container), όχι το ίδιο το Dockerfile· ακόμα διαβάζει την ίδια σύνταξη Dockerfile. Αν θέλεις να παραλείψεις τη συγγραφή Dockerfile, θέλεις έναν zero-config builder όπως το Railpack ή τα Buildpacks. Το Podman είναι εναλλακτική του Docker-ως-runtime, ένα εντελώς διαφορετικό ερώτημα.

Ποια εναλλακτική του Dockerfile φτιάχνει τη μικρότερη εικόνα;

Ένα χειροβελτιστοποιημένο multi-stage Dockerfile μπορεί να παράγει τη μικρότερη εικόνα από όλες (255 MB στη δοκιμή μας). Ανάμεσα στους zero-config builders, το Railpack κερδίζει (416 MB για μια εφαρμογή Node έναντι 689 MB για το Nixpacks, ίδια εφαρμογή). Το static hosting δεν χρειάζεται καθόλου εικόνα, οπότε αν η έξοδός σου είναι static, αυτό είναι μακράν το μικρότερο αποτύπωμα.