CI/CD Pipeline untuk CodeIgniter 4: Dari git push ke Coolify Deploy

Saya ingin berbagi pengalaman setup CI/CD pipeline untuk project CodeIgniter 4 yang saya kerjakan. Project ini menggunakan GitLab sebagai repository, GitLab Container Registry untuk menyimpan Docker image, dan Coolify sebagai platform deployment.

Tantangannya: bagaimana membuat workflow yang otomatis — setiap kali push ke branch master, pipeline jalan, build Docker image, push ke registry, lalu trigger deploy ke Coolify?

Berikut langkah-langkahnya.

Arsitektur Pipeline

Pipeline kami terdiri dari 2 stage sederhana:

Build → Docker build & push ke GitLab Container Registry Deploy → Trigger Coolify via webhook

git push → master
  └─ build (docker build + push image)
      └─ deploy (curl ke Coolify)

Sederhana, tapi ada beberapa hal yang perlu diperhatikan.

1. GitLab CI Pipeline

File .gitlab-ci.yml di root project:

stages:
  - build
  - deploy

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  IMAGE_LATEST: $CI_REGISTRY_IMAGE:latest

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $IMAGE_TAG -t $IMAGE_LATEST .
    - docker push $IMAGE_TAG
    - docker push $IMAGE_LATEST
  only:
    - master

deploy_to_coolify:
  stage: deploy
  image: curlimages/curl:latest
  needs: [build]
  script:
    - echo "Memicu deployment ke Coolify..."
    - >
      curl -L -X POST
      -H "CF-Access-Client-Id: $COOLIFY_CF_CLIENT_ID"
      -H "CF-Access-Client-Secret: $COOLIFY_CF_CLIENT_SECRET"
      -H "Authorization: Bearer $COOLIFY_API_TOKEN"
      "$COOLIFY_DEPLOY_URL"
  only:
    - master

Penjelasan:

  • Build stage menggunakan Docker-in-Docker (dind). GitLab secara built-in menyediakan $CI_REGISTRY_USER dan $CI_REGISTRY_PASSWORD untuk login ke Container Registry-nya sendiri — tidak perlu bikin token manual.
  • Image di-push dengan 2 tag: $CI_COMMIT_SHORT_SHA (unique per commit) dan latest (selalu yang terbaru).
  • Deploy stage menggunakan curlimages/curl — image kecil (~5MB) yang isinya cuma curl. Lebih efisien daripada pakai alpine penuh.
  • Header Cloudflare Access (CF-Access-Client-*) diperlukan karena server Coolify di belakang Cloudflare Tunnel.

CI Variables yang perlu diset di GitLab → Settings → CI/CD → Variables:

VariableDeskripsi
COOLIFY_CF_CLIENT_IDCloudflare Access Client ID
COOLIFY_CF_CLIENT_SECRETCloudflare Access Client Secret
COOLIFY_API_TOKENCoolify API token
COOLIFY_DEPLOY_URLEndpoint deploy dari Coolify

2. Production Docker Compose

Untuk development lokal kami pakai docker-compose.yml biasa yang build dari source. Tapi untuk production di Coolify, kami buat file terpisah: docker-compose.prod.yml.

Perbedaan utamanya:

  • Menggunakan pre-built image dari registry, bukan build langsung.
  • Healthcheck — Coolify bisa monitor apakah container benar-benar siap.
  • Semua env variable via ${VAR:-default} — nilainya diisi dari Coolify UI.
services:
  cldu-app:
    image: registry.gitlab.com/username/nama-project:latest
    pull_policy: always
    container_name: cldu_app
    ports:
      - "${APP_FORWARD_PORT:-8070}:80"
    environment:
      APP_BASEURL: "${APP_BASEURL}"
      CI_ENVIRONMENT: "${CI_ENVIRONMENT}"
      DB_HOST: "${DB_HOST}"
      DB_DATABASE: "${DB_DATABASE}"
      DB_USERNAME: "${DB_USERNAME}"
      DB_PASSWORD: "${DB_PASSWORD}"
    volumes:
      - cldu_writable:/var/www/writable
    depends_on:
      - cldu-db
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/robots.txt"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Di Coolify, kita arahkan deployment ke file docker-compose.prod.yml ini.

3. Masalah: Pull Access Denied

Pas pertama kali deploy, muncul error:

Error: pull access denied for registry.gitlab.com/username/nama-project,
repository does not exist or may require 'docker login'

Coolify tidak punya akses untuk pull image dari GitLab Container Registry karena registry-nya private. Wajar — kita perlu memberikan credentials.

Awalnya saya coba setting COOLIFY_CONTAINER_REGISTRY_USERNAME dan COOLIFY_CONTAINER_REGISTRY_PASSWORD di environment variable Coolify, tapi ternyata tidak bekerja. Variabel-variabel itu mungkin untuk versi Coolify tertentu atau cara yang berbeda.

Saya juga coba docker login di terminal server, tapi akan kerepotan jika ada banyak project dengan registry berbeda. Karena tiap registry akan ada username dan token masing-masing dari gitlab.

4. Solusi: DOCKER_AUTH_CONFIG + GitLab Deploy Token

Setelah searching, akhirnya nemu referensi tentang DOCKER_AUTH_CONFIG — environment variable standar yang digunakan Docker Engine untuk menyimpan credentials registry. Biasanya ini dibuat otomatis saat docker login dan disimpan di ~/.docker/config.json. Ternyata environment variable ini bisa di-inject langsung.

Ini masuk akal: di belakang layar, docker login nulis file config.json, Coolify bisa membaca varian env-nya langsung tanpa perlu file. Solusi yang akhirnya bekerja adalah DOCKER_AUTH_CONFIG. Ini adalah konfigurasi standar Docker untuk login ke registry — jadi pasti didukung oleh environment manapun, termasuk Coolify.

Langkah 1: Buat GitLab Deploy Token

Buka project di GitLab → Settings → Repository → Deploy Tokens.

Buat token baru dengan scope read_registry:

Name: coolify-deploy-token
Scope: ✅ read_registry

GitLab akan generate username (misal: gitlab+deploy-token-123456) dan password. Simpan password-nya, karena tidak bisa dilihat lagi setelah halaman di-refresh.

Langkah 2: Generate Base64

Deploy token adalah username:password biasa. Kita perlu meng-encode-nya ke base64:

echo -n "gitlab+deploy-token-123456:token-secret-xxx" | base64

Output: Z2l0bGFiK2RlcGxveS10b2tlbi14eHhhOnRva2VuLXNlY3JldC14eHg=

Langkah 3: Set DOCKER_AUTH_CONFIG di Coolify

Di Coolify, buka Resource → Envs, tambahkan variable baru:

DOCKER_AUTH_CONFIG = {"auths":{"registry.gitlab.com":{"auth":"Z2l0bGFiK2RlcGxveS10b2tlbi14eHhhOnRva2VuLXNlY3JldC14eHg="}}}

Setelah itu, redeploy. Sekarang Coolify bisa login ke GitLab Container Registry dan pull image dengan sukses.

Deploy Flow End-to-End

Setelah semuanya beres, beginilah workflow lengkapnya:

1. Developer: git push ke master
       ↓
2. GitLab CI Runner mendeteksi perubahan
       ↓
3. Build stage:
   - docker build -t image:abc1234 -t image:latest .
   - docker push image:abc1234
   - docker push image:latest
       ↓
4. Deploy stage:
   - curl -X POST -H "Authorization: Bearer coapi_xxx" \
     "https://coolify.domain/api/v1/deploy?uuid=xxx"
       ↓
5. Coolify menerima webhook
       ↓
6. Coolify login ke registry (via DOCKER_AUTH_CONFIG)
       ↓
7. docker compose -f docker-compose.prod.yml up -d
       ↓
8. Healthcheck: cek /robots.txt di localhost
       ↓
9. App live! 🚀

Total waktu dari git push sampai app hidup biasanya sekitar 1-2 menit, tergantung ukuran image dan kecepatan build.

Troubleshooting

Beberapa error yang sempat saya alami dan solusinya:

Pull Access Denied

Error: pull access denied for registry.gitlab.com/...

Solusi: Set DOCKER_AUTH_CONFIG dengan base64 dari GitLab Deploy Token (scope read_registry).

Pipeline gagal — Docker not found

Error: docker: not found atau Cannot connect to the Docker daemon

Solusi: Pastikan GitLab Runner menggunakan executor docker dengan privileged = true. Ini diperlukan untuk menjalankan Docker-in-Docker.

Image tidak ditemukan

Error: manifest for registry.gitlab.com/... not found

Solusi: Pipeline build belum pernah jalan. Push ke master atau trigger manual pipeline dulu.

Penutup

Dengan pipeline ini, deploy jadi semudah git push. Tidak perlu SSH ke server, tidak perlu build manual, tidak perlu copy file. Semua otomatis.

Yang saya pelajari: masalah yang paling tricky bukan di GitLab CI-nya, tapi di autentikasi antara Coolify dan registry. Solusi DOCKER_AUTH_CONFIG adalah standar Docker yang bekerja di mana saja — tidak hanya Coolify, tapi juga di Kubernetes, Docker Swarm, atau VPS biasa.

Buat Jaringan Internet Antar Kantor Dengan Point to Point

Sudah lama saya berfikir, bagaimana menghubungkan jaringan internet dari lokasi B ke lokasi A yang memiliki jarak sekitar 150 meter. Jalur internet utama ada di lokasi A dan saya ingin agar lokasi B punya akses internet melalui jaringan di lokasi A. Sementara ini saya hanya menggunakan router 4G dari TP-link sebagai akses internet di lokasi B.

Saya melakukan explorasi sekenario dan perangkat. Kemudian saya melihat review di youtube untuk mencari case yang sama. Konsultasi dengan AI juga saya lakukan untuk melihat solusi dan menambah wawasan skenari dari sudut pandang yang berbeda. Dari berbagai opsi perangkat dan skenario, saya memutuskan untuk menggunakan metode Point to Point menggunakan Totolink CP300.

Sambil menunggu barang datang, saya mencari spot dimana perangkat akan saya pasang diatas atap. Saya naik ke tempat toren air dan memasang HP di tongkat tongsis untuk melihat pandangan yang lebih luas. Saya berharap mendapat LOS atau Line of Sight yang tidak terhalang oleh apapun. Dari sini saya menemukan spot yang rasanya bisa dipertimbangkan dan dicoba, walaupun tidak free dari penghalang, tapi masih kelihatan disela-sela ranting pohon.

Lokasi A – Mode Access Point

Setelah Totolink CP300 datang, saya langsung melakukan uji coba. Dua perangkat saya nyalakan dan saling terhubung satu sama lain. Setelah saya yakin dengan skenario setup, saya naik ke area toren dan pasang satu Totolink CP300 di lokasi A dengan mode Access Point. Saya pasang di titik yang sudah saya tentukan sebelumnya dan saya hadapkan ke arah lokasi B.

Lokasi B – Mode Client

Selanjutnya di lokasi B, saya pasang Totolink CP300 juga dengan lokasi diatas teras dan menghadap ke lokasi A ke arah dimana Access Point dipasang. Sebelumnya sudah saya setting pengaturannya sehingga ketika diatas, langsung sat-set pasang dan atur pengkabelan dibawah. Nyalakan PoE dan cek halaman website pengaturan, didapatlah kekuatan sinyal 90 persen keatas. Kecepatan internet juga tidak jauh beda dengan lokasi A. Terus terang sangat puas dengan eksperimen ini dan saya putuskan untuk setup tempat kerja di lokasi B.

Mon, Dec 29, 2025

Nyobain Shinobi dan Frigate

Beberapa hari terakhir ini saya sedang explore perangkat server untuk menggantikan server raspi dan pc tua yang mulai terasa kewalahan. Pilihan mulai dari mini pc second seperti lenovo thinkcenter sampai server xeon lawas. setiap pilihan berimplikasi dengan desain server yang akan dipasang.

Awalnya sempet mau pakai mini pc karena murah, simpel, daya listrik kecil, wah cocok ini saya pikir. Tapi kemudian saya teringat kalau saya butuh slot untuk hdd 3.5 in yang akan dipakai buat storage media dan cctv. Akhirnya pilihan ini saya tunda dan mencoba eksplore pc biasa dan juga xeon.

Belum selesai explore hardware, saya secara paralel mengexplore dari sisi software. Saya petakan dan coba software mana yang nanti akan menggantikan sistem yang sudah ada. Salah satu sistemnya yaitu cctv. Sempet beberapa muncul di beranda tentang instalasi NVR untuk cctv tanpa perangkat khusus NVR. System ini pakai software NVR yang dipasang di PC biasa sehingga bisa dijadikan NVR seperti layaknya perngkat NVR.

Ada dua yang sudah sempet saya coba yaitu Shinobi dan Frigate. Dari referensi sih dua-duanya bisa dipakai untuk NVR dan masing-masing punya kelebihan sendiri. Secara umum Frigate lebih kuat di bidang AI dan Shinobi lebih unggul di fleksibilitas dan kompleksitas NVR.

Dari sisi penambahan kamera dan konfigurasi masing-masing punya pendekatan sendiri. Untuk Frigate, konfigurasi penambahan kamera dan semua hal yang mengikutinya dilakukan di file yml, sedangkan untuk Shinobi bisa dilakukan di GUI berbasis web.

Saat mencoba menjalankan Frigate, CPU bekerja sangat keras. Bahkan kipas CPU sampai meraung-raung berputar kencang. Saya amati memang sepertinya dari proses AI yang berjalan secara realtime mendeteksi dan menganalisa gambar-gambar dari berbagai kamera memakan processing power yang besar sekali. Ini tentu menjadi perhatian khusus karena daya juga pasti makan besar.

Untuk shinobi sepertinya lebih sederhana dari sisi AI fiturnya, tetapi lebih banyak pengaturan seperti layaknya NVR perangkat pada umumnya tetapi lebih kompleks. Penggunaan CPU dan kipas juga tidak sampai meraung-raung. Hanya saja, pengaturan yang kompleks ini membutuhkan waktu tambahan untuk mempelajarinya.

Ini kira-kira impresi pertama saya mencoba keduanya. Dan oh iya, keduanya saya jalankan dalam lingkungan terkontainerisasi menggunakan Docker. Tinggal nanti selanjutnya ntah explore yang mana lagi sebelum memutuskan upgrade server kemana jadinya….

Thu, 11 Des 2025

Membuat Modul IoT Membaca Banyak Device dengan RS485

Postingan ini sebenarnya sudah ada judulnya dari beberapa bulan lalu, tapi baru sempet menulis isinya sekarang. Saat itu, sistem PLTS saya baru ada inverter dan baterai, belum ada panel surya, sehingga saya fokus pada komponen IoT-nya dulu.

Saya sudah membuat desain jalur kabel dan flow arusnya. Mulai dari string panel surya yang sudah saya persiapkan menjadi dua string, sampai arah inverter dan baterai. Tiap titik bagian sudah saya rencanakan akan dipasang sensor untuk mengetahui parameter yang akan saya ukur. Salah satu parameter misalnya voltase dan energi dari baterai ke inverter. Ini sudah bisa saya implementasikan sebelum menunggu panel surya terpasang.

Pada tahap awal ini, saya akan memasang 4 sensor, dua untuk memantau arus DC dan dua lagi untuk memantau arus AC. Dua arus DC adalah dari SCC ke inverter serta baterai dan satu lagi dari baterai dan SCC ke inverter. Dua sensor ini untuk memantau berapa banyak energi yang dipanen dari SCC dan berapa besar energi yang terpakai. Sedangkan untuk arus AC, saya memasang sensor untuk arus dari PLN dan satu lagi untuk memantau arus keluaran dari Inverter. Ini untuk memantau berapa besar energi PLN dan PLTS yang terpakai.

Saya menggunakan PZEM016 dan PZEM017. Dua alat ini memiliki interface RS485 sehingga saya membutuhkan modul RS485. Untuk modul kontrolernya saya menggunakan ESP dari keluarga ESP8266 yaitu ESP Wemos D1 Mini. Saya berencana membuat satu modul ini untuk memantau banyak device RS485.

Sat, 29 Nov 2025

Pengalaman Setup Printer Canon G2010 untuk Mac dalam Jaringan

1. Setup Awal: Wavlink + Windows = Lancar Jaya

Awalnya, printer Canon G2010 saya terhubung ke jaringan lokal menggunakan print server Wavlink. Di lingkungan Windows, semuanya berjalan mulus: printer terdeteksi otomatis, driver tersedia, dan proses cetak berlangsung cepat tanpa hambatan. Ini solusi ideal untuk rumah atau kantor kecil yang ingin berbagi printer tanpa harus colok langsung ke satu komputer.

2. Masuk Mac: Driver Ada, Tapi Lemot dan Gagal

Masalah muncul saat mencoba mencetak dari MacBook. Saya menambahkan printer lewat System Preferences → Printers & Scanners, memilih driver Canon G2000 series (karena G2010 tidak muncul). Awalnya, printer bisa menerima job dan mulai mencetak. Tapi…

  • Proses cetak sangat lambat
  • Sering berhenti di tengah jalan
  • Kadang hang total dan harus restart printer

Setelah frustrasi berkali-kali, saya cek langsung ke situs resmi Canon — dan ternyata: Canon G2010 memang tidak mendukung macOS secara resmi. Tidak ada driver native, dan solusi workaround tidak stabil.

3. Jalan Alternatif: CUPS + Raspberry Pi

Karena saya sudah punya Raspberry Pi yang standby di jaringan, saya coba eksperimen: jadikan Pi sebagai print server berbasis CUPS (Common Unix Printing System).

Langkah-langkahnya:

  • Install CUPS di Raspberry Pi:bashsudo apt update && sudo apt install cups printer-driver-gutenprint
  • Tambahkan user ke grup lpadmin dan aktifkan sharing
  • Akses web interface CUPS di http://raspberrypi.local:631
  • Tambahkan printer Canon G2010 menggunakan driver dari Gutenprint

Hasilnya?

  • Printer bisa ditambahkan ke Mac via IPP (Internet Printing Protocol)
  • Proses cetak berhasil sampai selesai
  • Masih agak lambat, tapi jauh lebih stabil dibanding metode sebelumnya