Claude Self-Hosted Runner: Setup dan Security

Claude Self-Hosted Runner: Cara Kerja, Setup, Security, dan Kapan Layak Dipakai

Claude bisa dipasang ke workflow GitHub lalu diberi akses untuk membaca issue, mereview pull request, mengubah kode, menjalankan test, dan membuat commit. Ketika workflow itu dipindahkan ke self-hosted runner, tim mendapat kontrol lebih besar atas mesin eksekusinya.

Tapi ada satu salah kaprah yang perlu dibereskan sejak awal:

"Claude self-hosted runner" bukan berarti model Claude berjalan lokal di server Anda.

Yang berjalan di mesin Anda adalah GitHub Actions runner, Claude Code, tool, script, dan command yang dibutuhkan workflow. Proses inference tetap memanggil provider model yang dipilih, seperti Anthropic API, Amazon Bedrock, Google Vertex AI, atau Microsoft Foundry.

Perbedaan ini penting. Self-hosted runner bisa memberi akses ke private network, dependency internal, hardware khusus, dan environment yang sudah disiapkan perusahaan. Di sisi lain, Anda juga mengambil alih patching, isolasi job, pengelolaan secret, observability, dan incident response.

Kalau setup-nya asal, kita tidak sedang mendapat "AI coding yang lebih privat". Kita hanya memindahkan blast radius dari runner GitHub ke server sendiri.

Ringkasan cepat

Istilah yang lebih tepat adalah Claude Code GitHub Action yang dijalankan pada GitHub self-hosted runner.
Action dan command berjalan di infrastruktur Anda, tetapi request model tetap keluar ke provider Claude yang dipilih.
Self-hosted runner cocok ketika workflow membutuhkan akses ke service internal, tool khusus, hardware tertentu, atau kontrol environment yang tidak tersedia di GitHub-hosted runner.
Runner persistent yang dipakai bergantian oleh banyak repository membawa risiko state dan artefak tertinggal antar-job.
Untuk production, pilihan yang lebih aman adalah ephemeral runner, satu runner untuk satu job, clean environment, dan akses repository yang dibatasi.
Gunakan least privilege, OIDC atau Workload Identity Federation bila tersedia, action yang dipin ke full commit SHA, dan runner group khusus.
Per 7 Agustus 2026, satu kasus stale prompt pada runner non-ephemeral sudah diperbaiki. Namun ada issue terbuka tentang buffer inline comment pada path tetap di /tmp yang berpotensi terbawa lintas run atau repository pada runner bersama.

1. Apa sebenarnya Claude self-hosted runner?

Secara resmi, komponen utamanya terpisah:

GitHub Actions menerima event dari issue, pull request, komentar, jadwal, atau trigger lain.
Self-hosted runner mengambil job dan menjalankannya di mesin yang Anda kelola.
Claude Code GitHub Action menyiapkan konteks, menjalankan Claude Code, memakai tool yang diizinkan, lalu mengirim hasilnya kembali ke GitHub.
Provider model menerima request inference dan mengembalikan respons Claude.

Repository resmi anthropics/claude-code-action menjelaskan bahwa action dieksekusi pada runner milik pengguna. Panggilan model tetap menuju provider yang dipilih.

Artinya, self-hosting memberi Anda kontrol atas execution plane, bukan otomatis atas model inference plane.

Yang tetap berada di runner Anda antara lain:

checkout repository;
command build, lint, test, dan migration dry-run;
CLI internal;
koneksi ke package registry atau artifact store privat;
akses ke database staging atau service internal, jika memang diizinkan;
file sementara dan log job.

Yang perlu dikirim ke provider model adalah prompt dan context yang diperlukan Claude untuk mengerjakan task. Karena itu, kebijakan data tetap harus mengikuti provider, jenis akun, konfigurasi cloud, dan aturan internal perusahaan. Jangan menganggap semua kode otomatis tetap on-prem hanya karena label workflow memakai self-hosted.

2. Kenapa tim memilih self-hosted runner?

GitHub-hosted runner sudah cukup untuk banyak workflow. Mesinnya siap pakai, bersih untuk setiap job, dan maintenance dasarnya ditangani GitHub.

Self-hosted runner masuk akal ketika kebutuhan Anda lebih spesifik.

Perbandingan Claude Code pada GitHub-hosted runner dan self-hosted runner: kontrol environment, akses privat, serta tanggung jawab operasional

Akses ke private network

Claude bisa menjalankan test terhadap service yang hanya tersedia melalui VPC, VPN, Tailscale, private DNS, atau jaringan kantor. Contohnya:

API staging yang tidak dibuka ke internet;
package registry internal;
database integration test;
monorepo dependency yang berada di network privat;
perangkat atau service on-premise.

Ini salah satu alasan paling kuat. Bukan karena self-hosted terdengar lebih advanced, tetapi karena workflow memang tidak bisa selesai dari runner publik.

Environment yang konsisten

Tim bisa membuat image runner yang sudah membawa:

compiler dan SDK versi tertentu;
browser atau emulator;
dependency native;
security scanner internal;
CLI perusahaan;
certificate authority internal;
cache dependency yang dikontrol sendiri.

Untuk codebase besar, environment yang sudah dipanaskan bisa memangkas waktu setup. Namun cache hanya berguna jika lifecycle dan isolasinya jelas. Cache global yang tidak dikelola dapat berubah menjadi jalur kebocoran antar-job.

Hardware khusus

Self-hosted runner memberi pilihan CPU, RAM, storage, arsitektur, GPU, atau perangkat yang tidak tersedia pada runner standar. Ini relevan untuk build besar, mobile pipeline, game engine, computer vision, atau test yang memerlukan perangkat tertentu.

Kontrol compliance dan network egress

Anda dapat menentukan:

image dasar runner;
region mesin;
firewall egress;
log retention;
endpoint yang boleh diakses;
mekanisme secret injection;
integrasi SIEM dan audit log.

Tetapi kontrol bukan manfaat gratis. Setiap kontrol baru menambah tanggung jawab operasional.

3. Apa yang berubah ketika Claude diberi akses ke runner sendiri?

Claude Code bukan sekadar chatbot yang memberi saran. Dalam workflow yang diizinkan, ia dapat membaca file, mengedit kode, memanggil shell, menjalankan test, memakai GitHub API, dan menyiapkan perubahan.

Kemampuan itu produktif karena Claude berada dekat dengan tool eksekusi. Alasan yang sama juga membuat desain security-nya harus serius.

Anggap setiap job sebagai proses yang dapat menjalankan gabungan berikut:

instruksi dari workflow;
konten issue atau pull request;
source code dari branch;
script project;
hook dan konfigurasi repository;
dependency pihak ketiga;
output dari model.

Sebagian input tersebut bisa tidak tepercaya.

Dokumentasi security action Anthropic secara eksplisit mengingatkan risiko prompt injection dari konten eksternal. Sanitasi terhadap hidden content dan environment scrubbing dapat mengurangi risiko, tetapi tidak menghapusnya. Input allowed_non_write_users juga ditandai berisiko karena memungkinkan pengguna tanpa write access memicu action. Begitu pula allowed_bots: '*' pada repository publik.

Rule sederhananya:

Jangan memberi Claude akses yang lebih besar daripada akses yang berani Anda berikan kepada workflow tidak tepercaya.

4. Persistent runner adalah titik risiko terbesar

Self-hosted runner tidak wajib bersih setelah satu job. Mesin yang sama bisa menerima job berikutnya dengan filesystem, process, cache, atau konfigurasi yang masih tersisa.

GitHub menjelaskan bahwa runner self-hosted tidak memiliki jaminan virtual machine ephemeral dan bersih seperti GitHub-hosted runner. Kode tidak tepercaya dapat meninggalkan state atau bahkan mengompromikan environment secara persisten.

Risikonya membesar ketika satu runner organisasi dipakai oleh banyak repository:

file sementara dari repository A dapat terbaca oleh job repository B;
credential atau token bisa tertinggal di process, file, atau log;
toolchain yang dimodifikasi satu job dipakai job berikutnya;
Docker socket membuka akses luas ke host;
cache atau working directory menyimpan source code lama;
runner yang sudah dikompromikan terus menerima job baru.

Memakai container saja belum tentu cukup. Jika beberapa container berbagi Docker daemon, volume, host path, cache, atau credential helper yang sama, boundary-nya tetap lemah.

Untuk production, desain yang lebih waras adalah:

satu runner menerima paling banyak satu job;
runner didaftarkan sebagai ephemeral atau just-in-time;
environment dibuat dari image bersih;
mesin atau container dihancurkan setelah job;
log runner dikirim ke storage eksternal sebelum environment dibuang;
runner group membatasi repository dan workflow yang boleh memakainya.

GitHub merekomendasikan autoscaling dengan ephemeral self-hosted runners dan tidak merekomendasikan persistent runners untuk autoscaling. Parameter --ephemeral membuat runner otomatis deregister setelah memproses satu job. Namun deregister saja belum membersihkan hardware. Jika host atau disk dipakai ulang, provisioning layer tetap harus melakukan wipe atau membuat environment baru.

5. Dua kasus nyata yang penting dipahami

Bagian ini bukan alasan untuk panik. Ini bukti kenapa lifecycle runner tidak boleh dianggap detail kecil.

Risiko state lintas job pada persistent self-hosted runner dibandingkan ephemeral runner satu job satu environment

Kasus 1: stale prompt terbawa ke job berikutnya

Issue #1287 melaporkan prompt lama di ${RUNNER_TEMP}/claude-prompts/ terbawa ke invocation berikutnya pada non-ephemeral self-hosted runner. Dalam laporan tersebut, user request dari repository sebelumnya masuk ke context job lain yang memakai runner sama.

Masalah ini sudah diperbaiki melalui commit 9441a7f. Implementasi sekarang membersihkan direktori prompt sebelum menulis file baru.

Pelajarannya bukan "Claude Action bocor selamanya". Pelajarannya adalah action yang aman di VM ephemeral dapat menunjukkan perilaku berbeda di runner persistent.

Kasus 2: buffer inline comment memakai path tetap di `/tmp`

Issue #1542 melaporkan buffer inline comment memakai path machine-wide:

/tmp/inline-comments-buffer.jsonl

Pelapor menemukan comment dari repository sebelumnya ikut dibaca oleh run lain pada shared self-hosted runner. Pada kasus yang dilaporkan, GitHub menolak comment karena path file tidak cocok, sehingga comment tidak terbit di repository yang salah.

Per 7 Agustus 2026, issue tersebut masih open. Saya juga memeriksa source pada rilis terbaru saat riset, v1.0.187. Entrypoint terkait masih membaca path tetap tersebut dan belum menghapus file sesudah proses posting.

Ini belum sama dengan security advisory atau CVE resmi. Namun untuk operator persistent shared runner, sinyalnya cukup jelas: jangan menunggu advisory baru membuat boundary.

Mitigasi sementara yang masuk akal:

jangan berbagi persistent runner antar-repository sensitif;
gunakan ephemeral runner dengan environment baru per job;
jika masih terpaksa memakai persistent runner sequential, hapus buffer sebelum dan sesudah action;
jangan menjalankan beberapa job Claude secara bersamaan pada host yang berbagi /tmp;
pantau upstream issue dan upgrade setelah fix resmi tersedia.

Contoh cleanup sementara:

- name: Clear Claude inline-comment buffer
 shell: bash
 run: rm -f /tmp/inline-comments-buffer.jsonl

- name: Run Claude
 uses: anthropics/claude-code-action@FULL_COMMIT_SHA
 with:
 # authentication dan konfigurasi lain

- name: Clean Claude inline-comment buffer
 if: always()
 shell: bash
 run: rm -f /tmp/inline-comments-buffer.jsonl

Cleanup ini hanya mitigasi untuk runner sequential. Ia bukan pengganti isolasi. Pada host dengan job paralel, satu job dapat menghapus buffer milik job lain.

6. Arsitektur yang saya rekomendasikan

Untuk repository privat yang penting, baseline-nya seperti ini:

Runner khusus untuk Claude

Jangan mencampur job Claude dengan deployment production, signing release, atau workflow yang memegang credential bernilai tinggi. Buat runner group khusus, misalnya claude-private-runners, lalu batasi repository dan workflow yang boleh mengaksesnya.

Ephemeral atau just-in-time

Setiap runner menerima satu job lalu dihancurkan. Pilih salah satu:

VM sementara;
container dengan node/VM boundary yang benar-benar dibersihkan;
Kubernetes runner scale set melalui Actions Runner Controller;
just-in-time runner melalui REST API GitHub.

Untuk organisasi yang sudah memakai Kubernetes dan punya tim platform yang mampu mengelolanya, GitHub menyebut Actions Runner Controller sebagai solusi reference untuk autoscaling. Kalau workload kecil, VM ephemeral sederhana sering lebih mudah diaudit daripada cluster yang dibangun hanya demi terlihat modern.

Network egress minimum

Runner butuh koneksi keluar ke GitHub dan provider model. Tambahkan domain package registry atau service internal hanya jika workflow membutuhkannya.

Jangan memberi runner route bebas ke seluruh production network. Gunakan segmentasi, firewall, service account khusus, dan endpoint staging yang scope-nya sempit.

Secret jangka pendek

Untuk Anthropic direct API, Workload Identity Federation dapat menukar GitHub OIDC token dengan access token Anthropic berumur pendek. Ini menghilangkan kebutuhan menyimpan API key statis di GitHub Secrets.

Untuk Bedrock, Vertex AI, atau Foundry, gunakan identity federation/OIDC sesuai provider. Prinsipnya sama: credential sementara lebih baik daripada secret panjang umur yang dapat dipakai ulang.

Token dan permission minimum

Mulai dari read-only. Naikkan hanya izin yang dibutuhkan job.

Code review: contents: read dan pull-requests: write mungkin cukup, tergantung flow.
Implementasi perubahan: baru pertimbangkan contents: write.
Issue triage: batasi ke issues: write dan hindari akses lain.
Jangan memakai personal access token jika GITHUB_TOKEN atau GitHub App token dengan scope sempit sudah cukup.

Pisahkan workflow review, triage, dan implementation. Satu workflow super-agent dengan semua permission memang praktis, tetapi blast radius-nya buruk.

7. Contoh workflow yang lebih aman

Contoh berikut memakai runner group khusus, label ephemeral, WIF, permission terbatas, dan action yang dipin ke full commit SHA yang diverifikasi saat penulisan.

name: Claude PR Review

on:
 pull_request:
 types: [opened, synchronize, reopened, ready_for_review]

permissions:
 contents: read
 pull-requests: write
 id-token: write

jobs:
 review:
 if: github.event.pull_request.draft == false
 runs-on:
 group: claude-private-runners
 labels: claude-ephemeral

 steps:
 - name: Checkout repository
 uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803
 with:
 fetch-depth: 1

 - name: Clear temporary Claude state
 shell: bash
 run: rm -f /tmp/inline-comments-buffer.jsonl

 - name: Review pull request with Claude
 uses: anthropics/claude-code-action@1623c36729ac1cd5895198cded705a287de7db79
 with:
 anthropic_federation_rule_id: ${{ vars.ANTHROPIC_FEDERATION_RULE_ID }}
 anthropic_organization_id: ${{ vars.ANTHROPIC_ORGANIZATION_ID }}
 anthropic_workspace_id: ${{ vars.ANTHROPIC_WORKSPACE_ID }}
 prompt: |
 Review perubahan pada pull request ini.
 Fokus pada bug, security, regression, dan test yang hilang.
 Jangan mengubah kode dan jangan menjalankan deployment.
 claude_args: |
 --max-turns 8
 --allowedTools Read,Grep,Glob

 - name: Clean temporary Claude state
 if: always()
 shell: bash
 run: rm -f /tmp/inline-comments-buffer.jsonl

Beberapa catatan:

Full commit SHA Claude Code Action di atas mengarah ke rilis v1.0.187 yang saya verifikasi pada 7 Agustus 2026. actions/checkout juga dipin ke commit resmi v6 yang aktif saat penulisan. Jangan menganggap kedua SHA ini akan selamanya menjadi versi terbaik. Buat proses Dependabot atau review berkala untuk memperbaruinya.
Step checkout diperlukan agar Claude dapat membaca source repository melalui tool seperti Read, Grep, dan Glob. Dokumentasi Anthropic terbaru juga menempatkan actions/checkout sebelum Claude Code Action pada workflow yang membutuhkan file repository.
GitHub menyebut full-length commit SHA sebagai cara immutable yang paling aman untuk memakai action. Tag seperti @v1 lebih nyaman, tetapi tag dapat bergerak.
id-token: write diperlukan untuk flow OIDC/WIF. Jangan menambahkan permission itu jika authentication flow Anda tidak memakainya.
Daftar --allowedTools harus disesuaikan dengan task. Untuk review, Claude tidak perlu akses deploy, database production, atau shell tanpa batas.
Contoh ini sengaja review-only. Workflow yang mengedit kode sebaiknya dibuat terpisah dan membutuhkan trigger serta approval yang lebih ketat.

8. Checklist hardening sebelum go-live

Runner lifecycle

[ ] Runner ephemeral atau just-in-time.
[ ] Satu runner hanya memproses satu job.
[ ] Environment benar-benar dibersihkan atau dihancurkan setelah job.
[ ] Tidak ada job paralel yang berbagi host path, /tmp, Docker socket, atau credential helper.
[ ] Log runner dikirim ke storage eksternal.

Scope akses

[ ] Runner group hanya tersedia untuk repository yang disetujui.
[ ] Workflow yang boleh memakai runner dibatasi.
[ ] Public repository tidak memakai self-hosted runner untuk kode dari fork.
[ ] Repository privat pun tetap menganggap branch dan PR content sebagai input berisiko.

Authentication

[ ] OIDC atau Workload Identity Federation diprioritaskan.
[ ] Static secret, jika masih diperlukan, punya scope minimum dan rotasi jelas.
[ ] GITHUB_TOKEN memakai permission minimum.
[ ] Tidak ada personal token panjang umur tanpa alasan kuat.

Claude Code Action

[ ] Action dipin ke full commit SHA.
[ ] Release dan security change upstream dipantau.
[ ] allowed_non_write_users tidak diaktifkan kecuali use case sangat terbatas.
[ ] allowed_bots: '*' tidak digunakan pada public repository.
[ ] Tool Claude dibatasi sesuai job.
[ ] show_full_output dan debug log tidak diaktifkan pada environment sensitif.
[ ] Mitigasi issue buffer /tmp diterapkan sampai fix upstream tersedia, jika runner masih persistent.

Host dan network

[ ] Runner memakai user non-root.
[ ] Tidak ada SSH key, cloud credential, atau file production yang menetap di host.
[ ] Passwordless sudo tidak diberikan secara luas.
[ ] Docker socket tidak diekspos tanpa boundary yang dipahami.
[ ] Egress hanya menuju endpoint yang diperlukan.
[ ] Production network tersegmentasi dari runner review.

9. Biaya: runner bisa gratis, operasionalnya tidak

GitHub tidak mengenakan biaya pemakaian GitHub Actions untuk self-hosted runner. Namun mesin, bandwidth, storage, patching, image build, autoscaling, log, monitoring, dan tenaga operasional tetap menjadi biaya Anda.

Perhitungan yang jujur harus memasukkan:

biaya compute saat idle dan saat job berjalan;
waktu engineer mengelola runner;
pembuatan dan update base image;
log retention;
security monitoring;
failure recovery;
biaya model Claude;
biaya cloud provider jika memakai Bedrock, Vertex AI, atau Foundry;
dampak antrean ketika runner tidak tersedia.

Self-hosted tidak otomatis lebih murah. Untuk volume rendah dan workflow umum, GitHub-hosted runner sering lebih ekonomis karena maintenance-nya hampir nol.

Self-hosted mulai menarik ketika salah satu kondisi ini benar:

runner perlu akses ke network privat;
build membutuhkan hardware khusus;
volume cukup tinggi sehingga autoscaling sendiri masuk akal;
compliance menuntut kontrol environment tertentu;
waktu setup pada hosted runner terlalu mahal dan bisa dipangkas secara terukur.

Kalau motivasinya hanya "server kantor sedang menganggur", biasanya hitungannya belum lengkap.

10. Kapan sebaiknya dipakai?

Layak dipakai

Repository privat dengan kebutuhan akses ke service internal.
Code review yang membutuhkan dependency atau tool proprietary.
Monorepo besar dengan build environment khusus.
Mobile, embedded, GPU, atau hardware-in-the-loop testing.
Perusahaan yang sudah punya platform ephemeral runner dan observability matang.
Workflow yang memerlukan kontrol egress atau identity federation tertentu.

Sebaiknya tetap GitHub-hosted

Repository publik dengan kontribusi dari fork.
Workflow sederhana yang hanya lint, unit test, atau review biasa.
Tim belum punya owner untuk patching dan incident response runner.
Satu-satunya opsi saat ini adalah VPS persistent yang juga menjalankan service production.
Runner harus memegang banyak credential agar workflow bisa selesai.
Tidak ada mekanisme wipe, isolation, dan log eksternal.

Kesimpulan operasional

Claude Code di self-hosted runner dapat menjadi operator engineering yang kuat: ia dekat dengan repository, tool, dan service internal yang dibutuhkan untuk menyelesaikan pekerjaan nyata.

Tetapi nilai utamanya bukan "Claude berjalan lokal". Nilainya adalah kontrol atas tempat Claude Code mengeksekusi pekerjaan.

Kontrol itu layak diambil kalau organisasi juga siap memegang tanggung jawabnya.

Baseline yang saya rekomendasikan:

gunakan repository privat;
buat runner group khusus Claude;
gunakan ephemeral atau just-in-time runner;
satu job per runner dan clean environment;
pakai OIDC/WIF dan token berumur pendek;
mulai dari permission read-only;
pin action ke full commit SHA;
batasi tool dan trigger;
jangan berbagi persistent runner antar-repository sensitif;
pantau issue upstream sebelum upgrade.

Kalau belum bisa memenuhi baseline ini, pakai GitHub-hosted runner lebih dulu. Lebih baik automation-nya sedikit lebih lambat daripada cepat tetapi meninggalkan state, secret, dan akses internal pada mesin yang terus dipakai ulang.

Referensi resmi dan verifikasi teknis

Tags: #Claude Code #Claude self-hosted runner #GitHub Actions #self-hosted runner #OIDC #WIF #DevSecOps #AI coding

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital