.env File dalam pengembangan mobile: apa itu, tujuan dan prinsip kerja

Apa itu .env File dan mengapa diperlukan

.env File adalah file konfigurasi yang menyimpan variabel lingkungan dalam format teks sederhana KEY=VALUE. Setiap baris berisi satu variabel: nama kunci dan nilainya dipisahkan dengan tanda sama dengan.

File .env memecahkan masalah fundamental pengembangan modern: lingkungan yang berbeda (lokal, pengujian, produksi) memerlukan pengaturan yang sangat berbeda. URL server API di mesin lokal adalah http://localhost:8080, di server produksi — https://api.production.com. Jika nilai-nilai ini dikodekan secara langsung ke dalam kode aplikasi, setiap build untuk lingkungan yang berbeda memerlukan perubahan kode sumber.

Praktik menyimpan konfigurasi di luar kode utama aplikasi telah distandarisasi dalam manifesto The Twelve-Factor App (2011), yang menetapkan variabel lingkungan sebagai satu-satunya cara yang benar untuk mengonfigurasi aplikasi. Menurut survei JetBrains Developer Ecosystem (2024), lebih dari 67% pengembang mobile menggunakan file .env dalam proyek mereka.

Untuk pengembangan mobile, .env memberikan keuntungan tambahan: nilai disubstitusi pada tahap build melalui Gradle (Android) atau xcconfig (iOS), memungkinkan pembuatan build terpisah untuk pengembangan, staging, dan produksi tanpa mengubah kode sumber.

.env sangat berguna saat bekerja dalam tim: setiap pengembang membuat .env lokal sendiri dengan pengaturan untuk lingkungannya (jalur ke DB lokal, kunci API debug), dan pengaturan bersama ditetapkan dalam .env.example di repositori. Ini menghilangkan situasi ketika setelah git pull build pengembang rusak karena variabel lingkungan yang tidak diketahui. Anggota tim baru cukup menyalin .env.example ke .env dan mengisi nilai lokalnya.

Sintaks dan struktur .env File

Format .env sangat sederhana: setiap baris adalah satu variabel dalam bentuk KEY=VALUE. Spasi di sekitar tanda sama dengan biasanya diabaikan, tetapi di sebagian besar pustaka dianggap sebagai bagian dari nilai, jadi lebih baik dihindari.

Aturan dasar penulisan

Komentar dimulai dengan simbol # — seluruh baris setelahnya diabaikan. Baris kosong juga dilewati. Jika nilai mengandung spasi, ditempatkan dalam tanda kutip ganda atau tunggal.

# Pengaturan lingkungan utama
APP_NAME=MyMobileApp
APP_ENV=development

# Konfigurasi API
API_BASE_URL=http://localhost:3000/api
API_TIMEOUT=30000

# Data sensitif
DB_PASSWORD=secret_password_123
JWT_SECRET=your_jwt_secret_key

Tipe nilai dan escaping

Semua variabel dalam .env adalah string, tetapi pustaka pemuat dapat mengonversinya ke tipe yang diperlukan. Untuk escaping karakter khusus digunakan backslash dan tanda kutip. Jika nilai mengandung simbol # sebagai bagian dari teks, harus di-escape sebagai \#.

• String — tanpa tanda kutip atau dalam tanda kutip: KEY=value atau KEY="value with spaces"
• Angka — ditulis tanpa tanda kutip: PORT=8080
• Nilai boolean — string true/false: DEBUG=true
• Multibaris — backslash di akhir baris: KEY=line1\
line2
• Substitusi — di beberapa parser: DB_URL=${DB_HOST}:${DB_PORT}

Saat memuat .env, pustaka dapat melakukan interpolasi variabel — mensubstitusi nilai dari satu kunci ke dalam kunci lainnya. Misalnya, variabel DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@localhost/db akan memperluas DB_USER dan DB_PASS dari file yang sama.

Integrasi .env File dalam proyek mobile

Cara menghubungkan .env tergantung pada platform. Android menggunakan plugin Gradle, iOS — file konfigurasi xcconfig, dan solusi lintas platform seperti Flutter — pustaka khusus.

Android dan Gradle: konfigurasi BuildConfig

Di Android, .env dimuat melalui plugin gradle-dotenv. Plugin membaca .env dari root proyek dan menambahkan nilai ke BuildConfig, setelah itu tersedia dalam kode Kotlin atau Java melalui field yang dihasilkan.

// build.gradle.kts (app level)
plugins {
    id("co.uzzu.dotenv") version "4.0.0"
}

android {
    buildFeatures {
        buildConfig = true
    }
}

kotlin {
    // Akses dalam kode: BuildConfig.API_BASE_URL
    buildConfigField("String", "API_BASE_URL",
        "\"" + dotenv.get("API_BASE_URL") + "\"")
}

iOS dan Xcode: menghubungkan Config

Di iOS, variabel lingkungan biasanya dikonfigurasi melalui file xcconfig. Untuk memuat .env di Swift, digunakan pustaka DotEnv atau mekanisme bawaan Info.plist dengan kunci khusus.

// Memuat .env di proyek Swift
import DotEnv

struct AppConfig {
    static func load() {
        let env = DotEnv(Bundle.main)
        env.load()

        let apiURL = ProcessInfo.processInfo
            .environment["API_BASE_URL"] ??
            "https://default.api.com"
    }
}

Flutter dan Dart: pustaka flutter_dotenv

Untuk Flutter, terdapat paket flutter_dotenv yang memuat variabel dari .env saat inisialisasi aplikasi. File .env ditempatkan di root proyek, dan variabel tersedia melalui kelas dotenv.

// pubspec.yaml
dependencies:
  flutter_dotenv: ^5.1

// main.dart — memuat saat startup
import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: '.env');
  var apiUrl = dotenv.get('API_BASE_URL');
  runApp(MyApp(baseUrl: apiUrl));
}

Ketiga pendekatan memiliki prinsip yang sama: .env dimuat pada tahap build atau saat startup aplikasi, nilai di-cache dan digunakan dalam kode melalui konstanta yang dihasilkan. Ini mencegah masuknya data sensitif ke repositori.

Untuk React Native digunakan paket react-native-config, yang pada tahap build secara otomatis menghasilkan kelas BuildConfig untuk Android dan konstanta di Info.plist untuk iOS dari satu file .env di root proyek. Ini sangat nyaman untuk startup yang menggunakan Expo atau bare workflow: satu .env di tingkat root sudah cukup, dan semua platform menerima variabel lingkungan yang sama tanpa duplikasi konfigurasi.

Keamanan dan praktik terbaik .env File

Meskipun memiliki banyak kelebihan, .env bukanlah solusi lengkap untuk menyimpan rahasia di lingkungan produksi. Ini memberikan tingkat perlindungan dasar, tetapi jika digunakan secara tidak benar dapat menyebabkan kebocoran data rahasia.

Perlindungan melalui .gitignore

Aturan terpenting — .env tidak boleh masuk ke sistem kontrol versi. File ditambahkan ke .gitignore segera setelah dibuat, dan hanya file contoh .env.example dengan nilai kosong atau palsu yang di-commit ke repositori.

# .env.example — di-commit ke repositori
APP_NAME=
APP_ENV=development
API_BASE_URL=http://localhost:3000
API_TIMEOUT=30000
# DB_PASSWORD — jangan cantumkan bahkan dalam contoh!
# JWT_SECRET — jangan cantumkan bahkan dalam contoh!

# .gitignore
# File Dotenv
.env
.env*.local

Alternatif untuk lingkungan produksi

Untuk proyek produksi, disarankan menggunakan solusi manajemen rahasia profesional. .env di produksi hanya diizinkan jika file berada di luar document-root server dan memiliki hak akses yang ketat.

• AWS Secrets Manager — penyimpanan rahasia cloud dengan rotasi kunci dan audit akses
• Google Secret Manager — layanan Google Cloud untuk menyimpan kunci API dan kata sandi
• HashiCorp Vault — alat dengan rahasia dinamis dan enkripsi sisi server
• Firebase Remote Config — konfigurasi cloud dengan pengujian A/B untuk aplikasi mobile
• GitLab CI/CD Variables — penyimpanan rahasia bawaan untuk pipeline build

Menurut Snyk State of Open Source Security (2024), kebocoran file .env melalui repositori menjadi penyebab lebih dari 12% dari semua insiden pengungkapan kunci API di antara perusahaan yang disurvei. Penggunaan manajer rahasia terpisah dapat mengurangi risiko ini menjadi nol.

Perlindungan tambahan dicapai dengan menerapkan hook pre-commit menggunakan alat seperti husky dan lint-staged, yang memeriksa apakah pengembang secara tidak sengaja menambahkan .env ke commit. Alat seperti git-secrets (AWS) dan talisman memindai setiap commit untuk pola kunci API, token, dan kata sandi, memblokir commit saat terdeteksi. Untuk pipeline CI, disarankan menambahkan pemeriksaan detect-secrets — pemindai otomatis yang tidak akan membiarkan file .env masuk ke repositori bahkan jika pengembang melakukan kesalahan.