Nixpacks проти Docker: Повний гід по розміру, швидкості та причини переходу Railway

Вибір між Nixpacks та Docker колись був простим: пожертвувати контролем заради зручності. Але у 2025 році команда Railway, яка створила Nixpacks, перевела його в режим підтримки (maintenance mode) і випустила Railpack як заміну. Це повністю змінює рівняння. Це повне порівняння docker та nixpacks з реальними розмірами образів, даними про швидкість збірки, кодом пліч-о-пліч та фреймворком для прийняття рішень, який враховує реальний стан речей у 2026 році.

Nixpacks проти Docker: Короткий огляд

Якщо вам потрібно зробити деплой без Dockerfile і ваш стек підтримується, Nixpacks (або його наступник Railpack) запустить вас за лічені секунди. Якщо ж вам важливий розмір образу, швидкість збірки або оптимізація для продакшену, власний Dockerfile завжди перемагає.

Одне, що варто зрозуміти одразу: Nixpacks не замінює Docker. Він генерує Dockerfile «під капотом» і використовує BuildKit від Docker для створення образів, сумісних з OCI. Це шар абстракції поверх Docker, а не альтернатива йому.

Що таке Nixpacks? (І чим він відрізняється від Nix)

Nixpacks — це інструмент збірки, створений Railway, який автоматично визначає мову та фреймворк вашого додатка, а потім генерує контейнерний образ без будь-якої конфігурації. Ви пушите код, Nixpacks робить решту. Таке гасло, і для простих додатків воно дійсно працює.

Ось як виглядає збірка Nixpacks:

# Zero config -- Nixpacks detects your stack automatically
nixpacks build . --name my-app

# Or with a custom start command
nixpacks build . --name my-app --start-cmd "node dist/index.js"

Nixpacks сканує ваш вихідний код на наявність файлів на кшталт package.json, requirements.txt або go.mod і вибирає відповідного «провайдера» (так вони називають рецепти збірки для конкретних мов). Він був розроблений, щоб бути швидшим і простішим за buildpacks у стилі Heroku, і певний час був стандартним білдером у Railway.

Як Nixpacks виявляє ваш стек

Конвеєр виявлення досить простий: Nixpacks переглядає корінь вашого проекту в пошуках відомих конфігураційних файлів. Знайшли package.json? Провайдер Node.js. Знайшли requirements.txt або pyproject.toml? Провайдер Python. Він навіть частково обробляє монорепозиторії, хоча з нестандартними структурами проектів можуть виникнути проблеми.

Nix проти Nixpacks: Це не одне й те саме

Це заплутує майже всіх (включно з більшістю статей, які ранжуються за цим запитом). Nix — це функціональний менеджер пакетів і система збірки, орієнтована на відтворюваність. Nixpacks — це конкретний інструмент, який використовує пакети Nix всередині для вирішення залежностей. Вони пов'язані, але різні, наче сказати, що «npm» і «create-react-app» — це одне й те саме, тому що одне використовує інше.

Критичний контекст для 2026 року: Nixpacks перебуває в режимі підтримки. Railway припинила додавати нові функції і створила Railpack, щоб усунути фундаментальні обмеження. Існуючі проекти все ще працюють, але дорожньої карти покращень немає.

Docker та Dockerfiles: Індустріальний стандарт

Ви знаєте, що таке Docker. Тому пропустимо абзац «Docker — це платформа контейнеризації» і зосередимося на тому, що важливо для цього порівняння.

Dockerfile дає вам явний, покроковий контроль над вашим контейнерним образом. Ви обираєте базовий образ, контролюєте, які файли копіюються, точно вказуєте, які залежності встановлюються, та оптимізуєте кінцевий результат за допомогою багатостадійних збірок. Ось приклад, готовий до продакшену:

# Multi-stage Node.js Dockerfile -- optimized for size
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

Ключові функції Docker, актуальні для цього порівняння: багатостадійні збірки дозволяють відокремити залежності часу збірки від образу виконання. Кешування шарів через BuildKit робить наступні збірки швидкими та передбачуваними. А вибір базового образу (Alpine, distroless, scratch) дає вам прямий контроль над розміром образу та поверхнею атаки.

Знання Docker також є універсально переносними. Кожен хмарний провайдер, кожна CI/CD платформа, кожне цільове середовище деплою розуміє Dockerfile.

Nixpacks проти Docker: Пряме порівняння

Налаштування та конфігурація

Найбільша перевага Nixpacks — це деплой без налаштувань. Для стандартного додатка на Node.js вам буквально не потрібен жоден конфігураційний файл. Запуште код, отримайте контейнер. З Docker вам потрібно написати та підтримувати Dockerfile.

Коли вам потрібно кастомізувати Nixpacks, ви використовуєте nixpacks.toml:

# nixpacks.toml -- customize Nixpacks behavior
[phases.setup]
nixPkgs = ["...", "ffmpeg"]  # Add system dependencies

[phases.build]
cmds = ["npm run build"]

[start]
cmd = "node dist/index.js"

Еквівалентний Dockerfile більш багатослівний, але набагато зрозуміліший:

FROM node:20-alpine
RUN apk add --no-cache ffmpeg
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

Для хакатону або прототипу Nixpacks економить вам реальний час. Для всього, що ви будете підтримувати довше ніж вихідні, цей Dockerfile окупає себе завдяки можливостям налагодження та оптимізації.

Вердикт: Нічия. Nixpacks перемагає за швидкістю деплою. Docker перемагає за довгостроковою підтримуваністю. Обирайте залежно від ваших термінів.

Розмір образу

Саме тут порівняння стає жорстоким. Образы Nixpacks великі. Не «трохи більші», а в 10–17 разів більші, ніж оптимізований Dockerfile для того самого додатка.

Один добре документований випадок: розробник мігрував додаток Next.js з Nixpacks на власний Dockerfile і побачив, як розмір образу зменшився з 1.3 ГБ до 76.83 МБ, тобто зменшення в 17 разів. Це не рідкість.

Причина криється в архітектурі. Nixpacks скидає все в /nix/store: інструменти збірки, компілятори, символи налагодження, бібліотеки, які вам ніколи не знадобляться під час виконання, — все в одному масивному шарі. Багатостадійні збірки Docker дозволяють викинути все, окрім самих артефактів виконання.

Вердикт: Docker впевнено перемагає. Це навіть не близько. Якщо розмір образу важливий для вашого проекту (а для продакшену це майже завжди так), Docker — єдиний реальний варіант.

Швидкість збірки та кешування

Перші збірки з Nixpacks зазвичай повільніші, оскільки він завантажує пакети Nix з нуля. Згідно з власними даними Railway, типова збірка Nixpacks займає близько 1 хвилини 27 секунд, проти 15 секунд для збірки Dockerfile та 6 секунд для попередньо зібраного образу.

Наступні збірки розповідають більш нюансовану історію. Бінарне кешування Nix може пришвидшити процес, але воно менш передбачуване, ніж кешування шарів Docker. Зміна у вашому package.json широко інвалідує кеш Nix, тоді як кешування шарів Docker перебудовує лише шари, починаючи зі зміненого кроку.

Кешування шарів Docker також більш прозоре. Ви бачите, які саме шари змінилися і чому. Кешування Nixpacks більше схоже на чорну скриньку: воно або спрацьовує, або ні, а налагодження промахів кешу в сховищі Nix вимагає експертизи, якої немає у більшості команд.

Вердикт: Docker перемагає. Більш передбачуваний, швидший як для перших, так і для кешованих збірок, і легший у налагодженні, коли кешування ламається.

Підтримка мов та фреймворків

Nixpacks автоматично виявляє близько 20 мов і фреймворків: Node.js, Python, Go, Rust, Java, Ruby, PHP, .NET, Elixir та інші. Для підтримуваних стеків виявлення дійсно вражає: він вибирає правильну версію середовища виконання, налаштовує команду збірки та автоматично конфігурує команду запуску.

Docker підтримує все, для чого ви можете написати Dockerfile. Це фактично необмежено. Екзотичні середовища виконання, користувацькі інструментарії, багатомовні монорепозиторії — якщо це працює на Linux, Docker це обробить.

Різниця у фіксації версій важливіша, ніж здається. Nixpacks використовує версіонування на основі комітів для пакетів Nix. Ви не можете сказати «Python 3.11.4», ви отримуєте ту версію, яку надає коміт Nix. Docker дає вам точний контроль версій: FROM python:3.11.4-slim є детермінованим.

Вердикт: Docker перемагає за гнучкістю. Nixpacks зручний, якщо ваш стек є у списку підтримуваних. Docker обробляє все, з точним контролем версій.

Готовність до продакшену та безпека

Образи Nixpacks містять набагато більше пакетів, ніж реально потрібно вашому додатку. Це означає більшу поверхню атаки: більше бінарних файлів — більше потенційних вразливостей. Роздутий шар /nix/store містить компілятори, інструменти збірки та бібліотеки, яким не місце в продакшн-образі.

Docker дає вам такі опції, як Alpine (мінімальний), distroless (без оболонки, без менеджера пакетів) або навіть FROM scratch для компільованих мов. Ці мінімальні образи містять лише те, що потрібно вашому додатку для роботи, різко зменшуючи поверхню атаки.

Налагодження — ще одна прогалина. Образы Nixpacks мають незвичну структуру каталогів, зосереджену навколо /nix/store з шляхами на основі хешів. Якщо щось піде не так у продакшені, ви витратите час на розуміння структури файлової системи, перш ніж зможете почати виправлення проблем.

Вердикт: Docker перемагає для продакшену. Менша поверхня атаки, знайомі інструменти налагодження та встановлені конвеєри сканування безпеки — все на боці Docker.

Досвід розробника

Ось де Nixpacks дійсно сяє. Для розробника, який ніколи не писав Dockerfile, перехід від коду до запущеного контейнера однією командою — це магія. nixpacks build ., готово. Жодного синтаксису для вивчення, жодного базового образу для вибору, жодного порядку шарів, про який треба думати.

Крива навчання Docker не крута, але вона реальна. Написання ефективного Dockerfile вимагає розуміння кешування шарів, багатостадійних збірок, .dockerignore та різниці між COPY і ADD. Це знання, яке окупається, але потребує часу для набуття.

Довгостроковий компроміс варто врахувати. Знання Nixpacks специфічні для платформи: вони корисні на Railway, Coolify та кількох інших платформах. Знання Docker універсальні та переносні на будь-яку роботу, будь-якого хмарного провайдера, будь-яке цільове середовище деплою.

Вердикт: Nixpacks перемагає для старту. Docker перемагає за корисністю протягом усієї кар'єри. Якщо ви навчаєтеся, почніть з Nixpacks, щоб швидко випустити продукт, а потім вивчіть Docker для продакшену.

Плеч-о-пліч: Той самий додаток, двома способами

Подивімося на практичну різницю. Ось API на Node.js Express, налаштоване для обох інструментів.

Nixpacks (без конфігурації, файл не потрібен):

# Nixpacks auto-detects Node.js from package.json
# No configuration file required
nixpacks build . --name express-api

# Result: ~900MB image

Для Nixpacks вам навіть не потрібен nixpacks.toml, якщо ваш додаток стандартний. Він читає package.json, виявляє скрипт збірки та налаштовує команду запуску.

Docker (оптимізований багатостадійний Dockerfile):

# Dockerfile for the same Express API
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY ./src ./src
EXPOSE 3000
CMD ["node", "src/index.js"]

Тепер додаток на Python FastAPI:

Nixpacks (без конфігурації):

# Nixpacks detects Python from requirements.txt
nixpacks build . --name fastapi-app

# Result: ~1.1GB image

Docker (оптимізований Dockerfile):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY ./app ./app
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Ось вивід пліч-о-пліч:

# Image size comparison
$ docker images
REPOSITORY          TAG       SIZE
express-api-nix     latest    924MB    # Nixpacks build
express-api         latest    83MB     # Docker multi-stage
fastapi-nix         latest    1.12GB   # Nixpacks build
fastapi-app         latest    92MB     # Docker slim

Версія Nixpacks «просто працює» без жодних зусиль. Версія Docker займає 10–15 хвилин на написання, але створює образ, який в 10 разів менший, деплоїться швидше і коштує менше для зберігання та передачі.

Проблема розміру образу: Чому Nixpacks створює контейнеры на 800 МБ

Роздуття образу — це не баг, який можна виправити конфігурацією, це фундаментальний наслідок того, як Nix працює під капотом.

Що насправді всередині образу на 1.3 ГБ

Коли Nixpacks збирає ваш додаток, менеджер пакетів Nix вирішує всі залежності (включаючи ті, що потрібні лише для збірки) і копіює їх у /nix/store. Це сховище стає одним масивним шаром у вашому контейнерному образі. Всередині типового образу Node.js, зібраного Nixpacks, ви знайдете:

• Компілятори збірки (gcc, g++), які були потрібні лише під час npm install
• Заголовки розробки для нативних модулей, які ви можете навіть не використовувати
• Символи налагодження, які додають сотні мегабайт
• Невикористовувані системні бібліотеки, підтягнуті як транзитивні залежності Nix
• Всю метадату сховища Nix: хеші, посилання на деривації та графи залежностей

Чому ви не можете просто оптимізувати це

Docker вирішує це за допомогою багатостадійних збірок: компілюйте на одному етапі, копіюйте лише вивід на чистий етап виконання. У Nixpacks немає еквівалентного механізму. Архітектура /nix/store розглядає всі пакети як єдиний атомарний блок. Ви не можете вибирати, які саме пакети Nix потраплять у фінальний образ.

Ви можете спробувати обмежити пакети в nixpacks.toml, явно вказавши aptPkgs та пакети Nix, але основні залежності середовища виконання Nix все одно будуть включені. Практична межа оптимізації Nixpacks все одно залишає вам образи, які в 5–8 разів більші за еквівалентну збірку Docker.

Реальна вартість образів понад 800 МБ: повільніші деплої, вищі витрати на зберігання в реєстрі контейнерів, довший холодний старт на serverless-платформах та більше споживання пропускної здатності щоразу, коли вузол тягне образ. Для стартапу, який запускає 10 реплік з частими деплоями, ці зайві гігабайти накопичуються як у часі, так і в грошах.

Коли розмір образу має значення (а він має значення для всього, окрім прототипу), відповідь проста: напишіть Dockerfile.

Фактор Railpack: Чому Railway відмовилася від Nixpacks

Це той контекст, який змінює все в дискусії nixpacks проти docker. У березні 2025 року Railway, команда, яка створила Nixpacks і використала його для 14 мільйонів збірок додатків, оголосила, що йде далі.

Їхні причини були конкретними та технічними:

1. Версіонування на основі комітів: пакети Nix не використовують semver. Ви не можете запросити «Node 20.11.1». Ви отримуєте ту версію, яку надає конкретний коміт Nix, що ускладнює відтворюваність збірок більше, ніж слід.
2. Масивні розміри образів: Архітектура /nix/store зробила оптимізацію структурно неможливою. Понад 200 000 користувачів Railway деплоїли непотрібно роздуті образи.
3. Непередбачуване кешування: Бінарне кешування Nix працювало нестабільно, що призводило до повільних збірок і розчаровувало розробників.

Що Railpack покращує порівняно з Nixpacks

Railpack повністю відмовляється від Nix. Він використовує базу Ubuntu зі стандартними менеджерами пакетів (apt, інструментарій для конкретних мов) та належними багатофазними збірками. Результати значні:

• Образи Node.js: на 38% менші, ніж у Nixpacks
• Образи Python: на 77% менші, ніж у Nixpacks
• Правильна підтримка semver: запитайте node@20 або [email protected] і отримаєте саме це
• Передбачуване кешування: стандартне кешування на основі шарів, зрозуміле розробникам

Railpack все ще у бета-версії. Наразі він підтримує Node.js, Python, Go, PHP та статичний HTML. Rust, Ruby, Java та кілька інших мов, які обробляє Nixpacks, поки що недоступні в Railpack.

Docker проти Nixpacks проти Railpack: Зведена таблиця

Підтримка платформ: Де працює кожен інструмент

Вибір контейнеризації частково залежить від того, куди ви деплоїте. Ось які сучасні платформи деплою підтримують які інструменти збірки:

Кілька висновків: Docker — єдиний інструмент збірки, який підтримується всюди. Якщо важлива портативність платформи, Dockerfile — ваш найбезпечніший варіант. Підтримка Nixpacks зосереджена в self-hosted PaaS-інструментах (Coolify, Dokploy) та кількох керованих платформах (Kinsta). Railpack поки що ексклюзивний для Railway.

Коли використовувати кожен: Фреймворк для прийняття рішень

Ось матриця рішень. Якщо ваша ситуація відповідає рядку, рекомендація була перевірена на реальних проектах.

Три прості правила:

1. Прототипуєте? Використовуйте інструменти без налаштувань (Nixpacks, Railpack). Не витрачайте час на написання Dockerfile для того, що ви, можливо, викинете.
2. Виходите в продакшн? Напишіть Dockerfile. 30 хвилин, які ви вкладете, заощадять години налагодження роздутих образів та непредбачуваних збірок.
3. Вже на Nixpacks? Не панікуйте і не мігруйте одразу. Заплануйте перехід на Railpack або Docker, коли ваш проект природним чином досягне важливої віхи.

Як Techsy підходить до деплою контейнерів

Ми запустили продакшн-додатки як з Nixpacks, так і з власними Dockerfile, тож ось наша чесна думка.

Для клієнтських прототипів та MVP ми часто починаємо з білдерів без налаштувань. Вони усувають тертя на етапі, коли ви щодня ітеруєте функції і ще не знаєте, чи «полетить» проект. Nixpacks (або тепер Railpack на Railway) ідеальний для цього: деплой за секунди, фокус на продукті.

Як тільки проект досягає продакшену, ми переходимо на оптимізовані Dockerfile. Наш процес виглядає так:

1. Аудит поточного образу: перевірка розміру, виявлення непотрібних пакетів, сканування на вразливості
2. Написання багатостадійного Dockerfile: відокремлення залежностей збірки від середовища виконання
3. Налаштування правильного кешування шарів: упорядкування інструкцій COPY для максимізації попадань у кеш
4. Вибір правильного базового образу: Alpine для більшості додатків, distroless для критичних до безпеки сервісів
5. Інтеграція в CI/CD: збірка, тестування, пуш у реєстр, деплой

Ми допомагали стартапам перейти від образів Nixpacks розміром понад 1 ГБ до образів Docker менше 100 МБ, скоротивши час деплою в 5 разів і заощадивши значні кошти на витратах реєстру контейнерів.

Створюєте щось і не впевнені щодо налаштувань деплою? Отримайте безкоштовну консультацію, ми допоможемо вам обрати правильний підхід для вашого проекту.

Часті запитання

Чи застарів Nixpacks?

Так. Nixpacks перебуває в режимі підтримки з 2025 року. Railway (його творець) створив Railpack як наступника. Існуючі проекти Nixpacks все ще працюють і отримують виправлення критичних помилок, але нові функції або провайдери мов не додаються. Для нових проектів розгляньте Railpack або власний Dockerfile.

Що замінило Nixpacks?

Railpack, створений Railway (та ж команда, що стоїть за Nixpacks). Він повністю відмовляється від залежності Nix, використовуючи збірки на базі Ubuntu зі стандартними менеджерами пакетів. Результат: образи Node.js на 38% менші та образи Python на 77% менші порівняно з Nixpacks, з правильною підтримкою версій semver.

Чому образи Nixpacks такі великі?

Архітектура сховища Nix копіює всі пакети, включаючи залежності часу збірки, такі як компілятори та символи налагодження, в один великий шар. Немає еквівалента багатостадійних збірок Docker, щоб видалити непотрібні файли. Простий додаток Node.js зазвичай створює образ 800 МБ – 1.3 ГБ через Nixpacks проти 50–100 МБ з оптимізованим Dockerfile.

Чи варто використовувати Nixpacks чи Docker?

Для швидкого прототипування на підтримуваних платформах Nixpacks дозволяє зробити деплой без налаштувань. Для продакшн-додатків, де важливі розмір образу, безпека та продуктивність збірки, власний Dockerfile дає образи в 10–50 разів менші та набагато більший контроль. Враховуючи застарілий статус Nixpacks, Docker є безпечнішою довгостроковою інвестицією.

Чи можна використовувати Nixpacks і Docker разом?

Так. Nixpacks генерує Dockerfile «під капотом» і використовує рушій BuildKit від Docker для створення образів. Багато команд використовують Nixpacks для середовищ розробки та стейджингу (швидка ітерація, без налаштувань), підтримуючи власний Dockerfile для продакшн-деплоїв.

Яка різниця між Nix та Nixpacks?

Nix — це функціональний менеджер пакетів і система збірки, орієнтована на відтворюваність. Nixpacks — це інструмент збірки, створений Railway, який використовує пакети Nix для автоматичного виявлення мов та контейнеризації додатків. Це пов'язані, але різні інструменти: Nix — це базова технологія, Nixpacks — це думковий оберточний шар, побудований поверх неї.

Чи підтримує Railway Nixpacks?

Railway все ще підтримує Nixpacks для існуючих проектів, але стандартним білдером для нових проектів тепер є Railpack. Ви також можете використовувати власний Dockerfile на Railway. Щоб переключитися, просто додайте Dockerfile до кореня вашого проекту; Railway автоматично виявить його і використає замість Nixpacks.

Чи швидший Nixpacks за Docker?

Загалом ні. Перші збірки з Nixpacks повільніші через завантаження пакетів Nix (приблизно 1 хвилина 27 секунд проти 15 секунд для збірки Dockerfile, згідно з бенчмарками Railway). Кешовані збірки можуть бути порівнянними для простих змін, але кешування шарів Docker загалом більш передбачуване та гранулярне.

Як перейти з Nixpacks на Dockerfile на Railway?

Додайте Dockerfile до кореня вашого проекту. Railway автоматично виявить його і надасть йому пріоритет над Nixpacks, жодних змін налаштувань не потрібно. Напишіть багатостадійний Dockerfile, оптимізований для вашого стеку, запуште його, і Railway зробить решту.

Які платформи використовують Nixpacks?

Coolify, Dokploy, Kinsta та Dokku (через плагін) все ще активно використовують Nixpacks. Railway перейшла на Railpack як на стандарт. Render, Fly.io та Vercel використовують власні пропрієтарні системи збірки. Docker — єдиний підхід до збірки, який підтримується на всіх платформах.

Чи хороший Nixpacks для продакшену?

Nixpacks більше підходить для розробки та стейджингу, ніж для продакшену. Великі розміри образів (понад 800 МБ), обмежені можливості оптимізації та застарілий статус роблять його ризикованим вибором для продакшн-навантажень. Для продакшену власний Dockerfile або Railpack (якщо ви на Railway) є сильнішими варіантами.

Фінальний вердикт

Docker — кращий вибір для більшості розробників, яких турбує якість продакшену. Він перемагає у п'яти з семи категорій, а дві категорії, де перемагає Nixpacks (швидкість налаштування, DX для початківців), найбільш важливі під час прототипування — фази, яка за визначенням є тимчасовою.

Nixpacks виконав реальну мету: він довів, що контейнеризація без налаштувань можлива та цінна. Але його фундаментальні обмеження — роздуті образи, непредбачуване кешування, версіонування на основі комітів — змусили його власних творців створити щось краще. Railpack може згодом запропонувати найкраще з обох світів (без налаштувань із розумними розмірами образів), але він все ще у бета-версії з обмеженою підтримкою мов.

Ось практична рекомендація: якщо ви починаєте новий проект на Railway, дозвольте Railpack обробляти ваші збірки. Якщо ви деплоїте десь інде або прямуєте до продакшену, витратьте 30 хвилин, щоб написати належний Dockerfile. Ця невелика початкова вартість заощадить вам від налагодження образів на 1 ГБ, повільних деплоїв та інструменту збірки, який більше не розвивається.

Джерела

• Чому ми відходимо від Nix - Блог Railway
• Офіційна документація Nixpacks
• Заміна Nixpack на Docker Image на Railway - Apvarun
• Найкращі практики Docker - Офіційна документація
• Офіційна документація Railpack
• Репозиторій GitHub Nixpacks