🎁
Bonus Top-up 50%!Promo Terbatas
Upvote
helipackdockerfilebuildotomatishelipod

Helipack: Cara Helipod Generate Dockerfile Otomatis untuk Aplikasimu

Tim Helipod

7 menit baca

Kenalan dengan Helipack — engine di balik Helipod yang otomatis mendeteksi framework aplikasimu dan generate Dockerfile production-ready tanpa kamu tulis satu baris pun.

Salah satu pertanyaan paling sering masuk ke tim Helipod: "Apa itu Helipack?"

Kalau kamu pernah deploy ke Helipod dan tidak perlu tulis Dockerfile sendiri — itulah Helipack yang bekerja. Dia adalah engine build internal Helipod yang bertanggung jawab mendeteksi framework aplikasimu dan menghasilkan Dockerfile yang optimal secara otomatis.

Artikel ini menjelaskan cara Helipack bekerja dari dalam — supaya kamu tahu apa yang terjadi di balik layar setiap kali klik Deploy.

Masalah yang Helipack Selesaikan

Dockerfile itu bukan hal yang trivial. Untuk satu aplikasi Laravel, kamu perlu tahu:

  • PHP version berapa yang dipakai
  • Mana yang lebih baik: FrankenPHP atau Nginx + PHP-FPM
  • Extensions PHP apa yang dibutuhkan (pdo_mysql, mbstring, bcmath, dll)
  • Cara setup Composer dengan benar
  • Cara inject environment variables dengan aman saat build
  • Cara bikin multi-stage build supaya image tidak bloat

Untuk Next.js, ada masalah lain lagi:

  • Harus aktifkan output: "standalone" dulu
  • Multi-stage build yang benar untuk minimalkan ukuran
  • Cara copy .next/static dan public/ ke runner stage

Kalau kamu harus melakukan semua ini sendiri untuk setiap project — itu membuang waktu yang seharusnya kamu pakai untuk nulis fitur.

Helipack menghilangkan semua kerumitan itu.

Cara Helipack Mendeteksi Runtime

Saat kamu connect repository ke Helipod, Helipack melakukan deteksi runtime berdasarkan file yang ada di repository:

Deteksi PHP

File yang Ditemukan Runtime
artisan + composer.json Laravel
composer.json + symfony.lock Symfony
wp-config.php WordPress
composer.json (generic) PHP Generic

Untuk Laravel, Helipack juga mendeteksi:

  • Versi PHP dari composer.json → menentukan pakai FrankenPHP atau Nginx+FPM
  • Ada octane di dependencies → pakai Laravel Octane + Swoole
  • Ada package.json dengan script build → ada Vite/Mix, perlu Node builder stage

Deteksi Node.js / Bun

File yang Ditemukan Framework
next.config.js/ts atau "next" di dependencies Next.js
nuxt.config.js/ts atau "nuxt" di dependencies Nuxt
"@nestjs/core" di dependencies NestJS
"remix" di dependencies Remix
"astro" di dependencies Astro
bun.lockb ada Runtime: Bun (bukan Node)
package.json generic Node.js Generic

Package manager juga dideteksi dari lock file:

  • package-lock.json → npm
  • yarn.lock → Yarn
  • pnpm-lock.yaml → pnpm
  • bun.lockb → Bun

Deteksi Python

File yang Ditemukan Framework
manage.py + "django" di requirements Django
"fastapi" di requirements FastAPI
"starlette" di requirements Starlette
"flask" di requirements Flask
pyproject.toml + poetry.lock Python + Poetry
pyproject.toml + uv.lock Python + uv
requirements.txt (generic) Python Generic

Dockerfile yang Dihasilkan per Framework

Laravel + FrankenPHP (PHP 8.2+)

Untuk Laravel dengan PHP 8.2 ke atas, Helipack memilih FrankenPHP — PHP server modern berbasis Caddy yang menggantikan kebutuhan nginx + PHP-FPM dengan satu binary:

# syntax=docker/dockerfile:1
FROM dunglas/frankenphp:latest-php8.3-alpine AS base
WORKDIR /app

COPY --from=mlocati/php-extension-installer /usr/bin/install-php-extensions /usr/local/bin/
RUN install-php-extensions pdo_mysql pdo_pgsql mbstring xml bcmath pcntl intl zip sodium

COPY --from=composer:2 /usr/bin/composer /usr/bin/composer

FROM base AS deps
WORKDIR /app
COPY composer.json composer.lock ./
RUN --mount=type=cache,target=/root/.composer \
    --mount=type=secret,id=build_env,dst=/app/.env \
    composer install --no-dev --no-scripts --no-autoloader --prefer-dist

FROM base AS runner
WORKDIR /app
COPY . .
COPY --from=deps /app/vendor ./vendor
RUN composer dump-autoload --optimize --no-dev --no-scripts

RUN --mount=type=secret,id=build_env,dst=/app/.env \
    php artisan config:cache \
    && php artisan route:cache \
    && php artisan view:cache || true

ENV APP_ENV=production
ENV SERVER_NAME=:8000
ENV CADDY_GLOBAL_OPTIONS="auto_https off"
EXPOSE 8000
CMD ["frankenphp", "run", "--config", "/etc/caddy/Caddyfile"]

Laravel + Nginx + PHP-FPM (PHP < 8.2)

Jika PHP di bawah 8.2, Helipack otomatis fallback ke setup klasik:

FROM php:8.1-fpm-alpine AS base
RUN apk add --no-cache nginx icu-dev
# ... install extensions, composer, dll
EXPOSE 8000
CMD sh -c "php-fpm -D && nginx -g 'daemon off;'"

Next.js (Standalone Mode)

Helipack menggunakan 4-stage build untuk Next.js:

  1. base — Alpine + tini
  2. deps — install semua dependencies (termasuk devDeps untuk build)
  3. builder — jalankan next build
  4. runner — copy hanya standalone output, tanpa source code atau node_modules penuh

Hasilnya: image production Next.js yang sangat kecil — biasanya 150–300MB dibanding 1GB+ jika tidak dioptimasi.

Django / FastAPI / Flask

Untuk Python, Helipack menggunakan 2-stage build:

  1. deps — install packages ke virtual environment
  2. runner — copy packages, copy source, jalankan server

Environment variable PYTHONDONTWRITEBYTECODE=1 dan PYTHONUNBUFFERED=1 selalu di-set untuk best practice Python di Docker.

NestJS / Node Generic

Multi-stage build dengan pemisahan deps:

  1. deps — install semua deps (termasuk devDeps untuk TypeScript compile)
  2. prod-deps — install production deps only
  3. builder — compile TypeScript → JavaScript
  4. runner — copy dist/ + prod node_modules saja

Fitur Keamanan Bawaan

Build Secrets — Env Vars Tidak Muncul di Layer

Salah satu masalah umum di Docker adalah environment variable yang dipakai saat build bisa tersimpan di image layer dan bisa di-extract orang lain.

Helipack menggunakan BuildKit secrets untuk mengatasi ini:

RUN --mount=type=secret,id=build_env,dst=/app/.env \
    npm run build

File .env hanya ada selama command RUN berjalan — tidak tersimpan di layer manapun. Ini berarti environment variables kamu aman meski image di-inspect oleh orang lain.

Non-root User

Semua Dockerfile yang dihasilkan Helipack menjalankan aplikasi sebagai non-root user:

RUN addgroup --system --gid 1001 appgroup && \
    adduser  --system --uid 1001 appuser
USER appuser

Ini adalah best practice keamanan container — jika ada vulnerability di aplikasi, attacker tidak punya akses root ke container.

Tini sebagai Init Process

Untuk Node.js dan PHP, Helipack menggunakan tini sebagai init process:

RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["node", "server.js"]

tini memastikan signal handling yang benar (SIGTERM saat container di-stop) dan zombie process cleanup — penting untuk graceful shutdown saat redeploy.

Cache Layer yang Efisien

Helipack menyusun Dockerfile dengan urutan layer yang optimal untuk memanfaatkan Docker build cache:

# Layer yang jarang berubah → di atas
FROM base AS deps
COPY package.json package-lock.json ./  # hanya copy file deps dulu
RUN npm ci                              # layer ini di-cache jika deps tidak berubah

# Layer yang sering berubah → di bawah
FROM builder
COPY . .                                # copy source code (sering berubah)
RUN npm run build

Dengan urutan ini, jika kamu hanya mengubah source code tanpa mengubah package.json, Helipod akan memakai cache untuk tahap install dependencies — build jadi jauh lebih cepat.

Jika Kamu Punya Dockerfile Sendiri

Jika repository kamu sudah punya Dockerfile, Helipack tidak akan generate yang baru — dia akan menggunakan Dockerfile yang ada. Ini memberi kamu kontrol penuh jika butuh kustomisasi yang sangat spesifik.

Kamu juga bisa menentukan path Dockerfile kustom di helipack.json:

{
  "build": {
    "dockerfile": "docker/Dockerfile.production"
  }
}

Melihat Generated Dockerfile

Penasaran Dockerfile apa yang dihasilkan Helipack untuk project kamu? Kamu bisa lihat di Build logs saat deploy. Cari baris yang dimulai dengan FROM untuk melihat struktur image yang dibuild.

Atau jika kamu pakai Helipack CLI (untuk development local), set environment variable HELIPACK_KEEP_DOCKERFILE=1 sebelum build — Helipack akan menyimpan Dockerfile yang dihasilkan sebagai .helipack.Dockerfile di root project.

Apa yang Tidak Bisa Helipack Deteksi?

Helipack sangat baik untuk framework-framework populer, tapi ada beberapa kasus di mana kamu perlu bantuan tambahan:

Binary atau bahasa lain — Helipack saat ini mendukung Node.js/Bun, PHP, dan Python. Untuk Go, Rust, Ruby, Java — kamu perlu Dockerfile sendiri.

Monorepo kompleks — Project dengan multiple apps dalam satu repository mungkin butuh konfigurasi manual via helipack.json untuk menentukan mana yang di-build.

Custom build pipeline — Jika proses build kamu sangat spesifik (misalnya generate code dulu, lalu build), override dengan Dockerfile sendiri atau konfigurasi helipack.json.

Untuk semua kasus di atas, kamu masih bisa deploy di Helipod — cukup sertakan Dockerfile sendiri di repository.

Kesimpulan

Helipack adalah "DevOps engineer virtual" yang tahu cara deploy Laravel, Next.js, Django, FastAPI, NestJS, Flask, dan puluhan framework lain dengan benar — secara otomatis, setiap kali kamu push code.

Ingin customize perilaku Helipack? Baca Panduan helipack.json untuk semua opsi konfigurasi yang tersedia.

Belum coba Helipod? Daftar gratis di helipod.io — tidak perlu kartu kredit.

Punya pertanyaan? Hubungi kami di support@helipod.id atau bergabung ke komunitas di hangar.helipod.io.

Siap coba Helipod?

Deploy aplikasi kamu sekarang. Gratis, tanpa kartu kredit.

Mulai Gratis →