Bagaimana Anda mengelola konfigurasi dan rahasia di Node?

Question

Accepted Answer

Konfigurasi (URL database, kunci API, port, bendera fitur) harus berada **di luar kode Anda** dalam variabel lingkungan — tidak pernah hardcoded. Ini menjaga rahasia keluar dari kontrol sumber dan memungkinkan kode yang sama berjalan di dev, staging, dan production dengan pengaturan berbeda.

## Prinsip: konfigurasi dari lingkungan

```js
// ❌ NEVER hardcode secrets — they end up in git history forever
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ read from the environment
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Ini mengikuti prinsip **twelve-factor app**: pemisahan ketat konfigurasi dari kode, sehingga deploy ke lingkungan baru berarti mengubah env var, bukan kode.

## Pengembangan lokal: file `.env`

```bash
# .env — local values, GITIGNORED (never committed)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// load .env into process.env (older: dotenv; newer Node: --env-file flag)
import "dotenv/config";        // or: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

File `.env` menyimpan konfigurasi lokal; file ini **harus gitignored**. Commit `.env.example` (dengan kunci tetapi tanpa nilai nyata) untuk mendokumentasikan apa yang diperlukan.

## Validasi konfigurasi saat startup

```js
import { z } from "zod";

const env = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(16),
  PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ fail FAST at startup if config is missing/invalid
```

Menvalidasi env var saat boot (dengan zod/envalid) berarti rahasia yang hilang atau salah format langsung crash dengan pesan yang jelas — jauh lebih baik daripada kegagalan runtime yang membingungkan di dalam permintaan.

## Rahasia di production

```text
Dev:        .env file (gitignored)
Production: injected by the platform/orchestrator —
            cloud secret managers (AWS Secrets Manager, GCP Secret Manager, Vault),
            container/orchestrator env vars, CI/CD secrets.
Never put production secrets in .env files committed or shipped with the app.
```

## Sentralisasi akses

```js
// config.js — one validated config module the app imports (don't sprinkle process.env everywhere)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## Mengapa ini penting

Manajemen konfigurasi dan rahasia yang tepat adalah kebutuhan baik **keamanan** maupun **operasional**.

Hardcoding rahasia membocorkannya ke dalam kontrol versi (pelanggaran serius, umum); mencampur konfigurasi ke dalam kode membuat deployment di berbagai lingkungan menjadi menyakitkan.

Pendekatan standar — env var, `.env` gitignored untuk dev lokal, `.env.example` untuk dokumentasi, validasi saat startup, dan manajer rahasia platform di production — menjaga rahasia tetap aman, membuat aplikasi portabel di berbagai lingkungan, dan menunjukkan konfigurasi salah sejak dini.

Ini adalah fondasi untuk menjalankan aplikasi Node secara bertanggung jawab.

Prinsip: konfigurasi dari lingkungan

Pengembangan lokal: file .env

Validasi konfigurasi saat startup

Rahasia di production

Sentralisasi akses

Mengapa ini penting

Pengembangan lokal: file `.env`