Claude Code'u VPS uzerinde tmux ile calistirma

Sorun dizüstü bilgisayarın kapağı, CLI değil

Claude Code dizüstü bilgisayarınızda siz kapağı kapatana kadar sorunsuz çalışır: SSH oturumu sonlanır, kabuk bir SIGHUP sinyali alır ve test çalışmasının üçüncü dakikasındaki aracı da onunla birlikte ölür. CLI'ı asla uyku moduna geçmeyen bir makinede, süreçleri SSH oturumunuzun alt süreci olmayan bir terminal çoğullayıcı (multiplexer) içinde çalıştırın. Tüm mesele budur; yükü taşıyan kısım kurulum değil, tmux'tır.

Bu sayfa, üzerinde aracıların çalışmaya devam edeceği bir sunucuyu yönetmek hakkındadır. Eğer açık bırakabileceğiniz bir Linux sunucunuz yoksa, bu anlatılanların hiçbiri sizin için geçerli değildir. Bu, tek dürüst ön koşuldur. Masaüstünde Linux Mint kullanıyorsanız aşağıdaki apt komutları size tanıdık gelecektir, çünkü Mint de Ubuntu LTS tabanlıdır; yine de sunucuya Mint değil Ubuntu Server kurun, nedeni Linux Mint'in sunucudaki yeri üzerine yazıda anlatılıyor.

tmux aslında ne yapar

SSH ile giriş yaptığınızda, sshd bir shell çatallar (fork) ve ona bir sözde uçbirim (pseudo-terminal) atar; bu shell üzerinden başlattığınız her şey onun bir alt sürecidir. Bağlantıyı kopardığınızda çekirdek pty'yi sonlandırır, shell SIGHUP sinyali alır ve sırasıyla kendi alt süreçlerini de kapatır. Uzun süre çalışan ön plan süreçleri bu nedenle sonlanır.

tmux sahiplik ilişkisini tersine çevirir. Yazdığınız tmux komutu, uçbiriminizden bağımsız çalışan bir tmux server ile unix soketi üzerinden haberleşen ince bir istemcidir. Bir oturum içindeki shell'ler sshd'ün değil, bu sunucunun alt süreçleridir. SSH bağlantısını kestiğinizde istemci kapanır ancak sunucu, oturum ve işlem ortasında kalan aracı çalışmaya devam eder. Yeniden bağlandığınızda, tmux attach komutu ile aynı shell'e ve aynı kaydırma geçmişine geri dönersiniz. nohup de bağlantı kopmalarından etkilenmez ancak size geri dönüş yolu sunmaz; arka plana atılmış bir TUI'ye yeniden bağlanamazsınız. Claude Code etkileşimlidir; tmux (veya screen) bu iş için doğru araçtır.

Sunucu boyutlandırma

CLI'ın kendisi tek bir yerel binary dosyasıdır; makineyi dolduran şey bu değildir. Makineyi dolduran, sizin adınıza çalıştırılan aracılardır: bir derleme, kapsamlı bir test paketi, tsc, bir dil sunucusu veya Docker üzerinde çalışan bir veritabanı. Boyutlandırmayı CLI'a göre değil, araç zincirine göre yapın. Hiç kullanmayacak olsanız bile swap alanı ekleyin; bu, ani bir OOM kill durumunu yavaş bir derleme sürecine dönüştürür:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Disk kullanımını da izleyin: depolar, node_modules ve Docker imajları hızla birikir. Eğer araç zinciri container'ların ötesine geçip tam sanal makinelere, bir KVM konuğuna veya yerel bir Kubernetes düğümüne ulaşıyorsa, taahhütte bulunmadan önce planın CPU sanallaştırma uzantılarını sunduğundan emin olun. Çünkü VPS üzerinde iç içe sanallaştırma çalıştırmak, konuk sistemin içinden açabileceğiniz bir özellik değil, sağlayıcının sizin için etkinleştirmesi gereken bir durumdur.

İlk adım olarak root olmayan bir kullanıcı oluşturma

Kendi ev dizinine sahip özel bir kullanıcı oluşturun ve genel anahtarınızı (public key) yerleştirin:

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/.ssh
sudo cp ~/.ssh/authorized_keys /home/agent/.ssh/authorized_keys
sudo chown agent:agent /home/agent/.ssh/authorized_keys
sudo chmod 600 /home/agent/.ssh/authorized_keys

İşleme devam etmeden önce ikinci bir terminalden giriş yapmayı deneyin; parola ile kimlik doğrulama henüz bir yedek olarak mevcutken bunu test edin. Eğer Permission denied (publickey) hatası alırsanız, sorun genellikle anahtarın kendisinden ziyade .ssh dizininin sahiplik veya izin ayarlarından kaynaklanır.

agent kullanıcısı, bilinçli olarak sudo grubuna dahil edilmemiştir. Bir sistem paketi gerektiğinde kurulumu siz yaparsınız. Bu karar, hatalı bir kabuk komutunun ana makineye zarar verebileceği durumların çoğunu ortadan kaldırır.

İnternete açık sunucular için SSH hijyeni

Tüm gün internete açık olan, bir SSH agent ve kaynak kodlarınızı barındıran bir makinede parola tabanlı kimlik doğrulaması kullanmak, alınmaması gereken bir risktir. Bu özelliği kapatın. Ubuntu 24.04 ve Debian 13 üzerinde /etc/ssh/sshd_config, /etc/ssh/sshd_config.d/*.conf dizinini içerir; bu nedenle ana yapılandırma dosyasını düzenlemek yerine bu dizine yeni bir dosya ekleyin:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Özel bir nedeniniz yoksa anahtar değişimi (key exchange) ayarlarını bu dosyaya eklemeyin: Eski bir güvenlik rehberinden kopyalanan bir KexAlgorithms satırı, genellikle yalnızca klasik algoritmaları sabitler. Bu durum, güncel bir SSH istemcisinin bağlantının post-quantum anahtar değişimi kullanmadığına dair uyarı vermesine neden olur.

Yapılandırmayı doğrulayın ve yeniden yükleyin. Test işlemini ikinci bir terminalden yaparken mevcut oturumunuzu açık tutun:

sudo sshd -t && sudo systemctl restart ssh

Ubuntu 24.04 için önemli bir detay: sshd, socket-activated olarak çalışır. Kimlik doğrulama ayarları systemctl restart ssh üzerinde geçerli olur, ancak dinleme Port ayarlarındaki bir değişiklik için systemctl daemon-reload ve ssh.socket servisinin yeniden başlatılması gerekir.

Ardından güvenlik duvarı ayarlarını yapın. SSH erişimine izin vermeden önce güvenlik duvarını etkinleştirirseniz kendinizi sunucudan dışarıda bırakırsınız:

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

fail2ban kurulumunu yaparken ne işe yaradığını göz önünde bulundurun: Parola tabanlı kimlik doğrulaması kapalıyken kaba kuvvet saldırıları zaten başarılı olamaz; bu araç yalnızca başarısız denemeleri günlük kayıtlarınızdan uzak tutar.

# /etc/fail2ban/jail.local
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h

Son olarak, sudo apt install unattended-upgrades ve sudo dpkg-reconfigure -plow unattended-upgrades kullanarak otomatik güncellemeleri yapılandırın. tmux ile olan etkileşime dikkat edin: Unattended-Upgrade::Automatic-Reboot özelliğini açarsanız, bir çekirdek güncellemesi sunucuyu yeniden başlatır ve tüm oturumlarınızı kapatır. Bu özelliği kapalı tutun ve yeniden başlatma işlemlerini, hiçbir işlem çalışmıyorken kendi planınıza göre yapın. Aynı dikkat, sürüm yükseltme işlemleri için de geçerlidir: sunucuyu Ubuntu 24.04 sürümünden 26.04 sürümüne taşımak, sshd ve çekirdeği yeniden başlatır; bu nedenle bu işlem, tmux oturumlarınızda önemli bir çalışma bulunmadığı bir zaman diliminde yapılmalıdır.

Ubuntu üzerinde Node.js ve Claude Code kurulumu

npm yolu, Node.js 22 veya daha yeni bir sürümü gerektirir. (Paket artık Node üzerinde çalışmayan yerel bir binary dosyası çekmektedir, ancak npm yine de motor sürümünü kontrol eder ve aracın kendi araç zinciri genellikle güncel bir Node sürümü ister.) Dağıtım paketleri genellikle geriden gelir; Ubuntu ve Debian üzerinde standart yol NodeSource kullanmaktır. NodeSource, imzalı bir depo sunar (Ubuntu 24.04 üzerinde kullanımdan kaldırılan ve Debian 13'te tamamen kaldırılmış olan apt-key kullanılmaz):

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
node --version

Şimdi insanların hatalı yaptığı kısım: CLI aracını agent kullanıcınız olarak kurun, asla sudo npm -g ile kurmayın. root sahipliğinde bir global önek (prefix), daha sonra izin hatalarına yol açar ve npm önbelleğinde root sahipliğinde dosyalar bırakır. Öncelikle npm önekini kullanıcının ev dizinine yönlendirin:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @anthropic-ai/claude-code
claude --version

Dışa aktarma (export) işlemi ~/.bashrc dosyasına eklenmelidir ve dosyanın üst kısmındaki "Etkileşimli değilse hiçbir şey yapma" korumasının üzerinde yer almalıdır. Varsayılan bir tmux bölmesi bir login shell çalıştırır: tmux, default-command değişkenini boş bırakır; bu da ona default-shell dosyasını bir login shell olarak başlatmasını söyler ve bir login bash, ~/.profile dosyasını okur; bu dosya da Ubuntu üzerinde ~/.bashrc dosyasını kaynak olarak kullanır. Örneğin default-command değişkenini kendiniz ayarlarsanız, login olmayan shell'ler doğrudan ~/.bashrc dosyasını okur. Bu nedenle ~/.bashrc her iki durumu da kapsarken, yalnızca ~/.profile kullanımı ikinci durumu atlayacaktır. Bir püf noktası: ~/.bash_profile veya ~/.bash_login mevcutsa bash ~/.profile dosyasını atlar; bu nedenle bunlardan birini oluşturduysanız, ~/.bashrc dosyasını da kaynak olarak eklediğinden emin olun. nvm gibi bir sürüm yöneticisi aracılığıyla kullanıcı bazlı bir Node kurulumu da aynı sonucu verir; her iki durumda da amaç, npm install -g komutunun asla sudo gerektirmemesidir. npm normal şekilde çalışmaya devam eder, ancak Anthropic belgeleri yerel kurulum betiğini önerilen yol olarak işaretler; imzalı apt, dnf ve apk depoları da diğer bir seçenektir. Yapıştırma yapmadan önce Anthropic'in kurulum belgelerini kontrol edin, kurulum yöntemleri değişebilir.

Başlatmak için bir depo içerisinde claude komutunu çalıştırın. İlk çalıştırma sizi kimlik doğrulama sürecine yönlendirir; başsız (headless) bir sunucuda tarayıcı bulunmadığından, süreç size kendi makinenizde açmanız için bir URL ve terminale girmeniz için bir kod verir. (Ortam değişkenindeki bir API anahtarı diğer yoldur.) Her iki durumda da, bu kimlik bilgisi artık sunucuda barınır ve bu da bizi insanların atladığı kısma getirir.

Etki alanı (blast radius) üzerine

Shell erişimine sahip bir ajan, bir shell'dir. Çalıştığı kullanıcının okuyabildiği her şeyi okuyabilir ve yazabildiği her yere veri gönderebilir. Bu, araca yönelik bir eleştiri değil, tanımının bir gereğidir; bu nedenle ajanın hangi kullanıcı hesabı altında çalıştığı, bireysel ayarlardan çok daha önemlidir.

• Özel, yetkisiz kullanıcı. sudo grubu olmamalı, kendi hesabınızla paylaşılan bir ev dizini bulunmamalıdır.
• Sunucuda üretim (production) kimlik bilgileri bulundurmayın. ~/.aws/credentials içinde üretim anahtarları, .env üzerinde üretimden kopyalanmış veriler veya önemli herhangi bir yere yazma erişimi olan veritabanı parolaları olmamalıdır. Ajana yalnızca staging veya salt okunur kimlik bilgileri tanımlayın.
• Kapsamı belirlenmiş token'lar. Tek bir depoyla sınırlı, ayrıntılı yapılandırılmış bir GitHub token'ı; salt okunur erişimin yeterli olduğu durumlarda ise bir deploy key kullanın.

Claude Code, izin istemlerinin neredeyse tamamını atlayan --dangerously-skip-permissions bayrağı ile gelir. Kendi dizüstü bilgisayarınızda veya geçici bir projede bu sizin tercihinizdir. Token'ların bulunduğu bir sunucuda ise bu bayrak, yanlış anlaşılan bir komut ile git push --force arasındaki son engeli kaldırır. Atlayacağınız istemler "ya hep ya hiç" mantığında değildir; ayrıca otomatik modun artık varsayılan başlangıç modu olması (Claude Code v2.1.283'ten itibaren) nedeniyle, başında durmadığınız bir sunucunun hangi izin moduna sabitlenmesi gerektiğini bilmek önemlidir. Bu bayrağın gerçekte neleri değiştirdiği ve bu bayrakla çalışan bir ajanın, yerleşik sandbox'tan geçici bir VPS'e kadar nasıl sınırlandırılacağı Claude Code'u sunucuda güvenli çalıştırma bölümünde ele alınmıştır.

Deploy key ile SSH agent forwarding karşılaştırması

Git'in dizüstü bilgisayarınızdaki anahtarı kullanabilmesi için ssh -A kullanmak cazip gelebilir. Bunun ne anlama geldiğini anlayın: agent forwarding, yerel SSH agent soketinizi sunucuda o kullanıcıyla çalışan süreçlere açar. agent olarak çalışan her şey (ajan dahil), siz bağlantıda kaldığınız sürece anahtarınızdan erişebildiği herhangi bir ana bilgisayar için imza isteyebilir. Bu, "git bu depoyu çeksin" demekten çok daha fazlasıdır.

Bunun yerine sunucu üzerinde bir anahtar oluşturun, bunu depo bazlı bir deploy key olarak kaydedin (ajanın push yapması gerekiyorsa yalnızca yazma erişimi verin) ve sunucudan yapılan commit'lerin tanınabilmesi için bir git kimliği ayarlayın:

ssh-keygen -t ed25519 -C "agent deploy key" -f ~/.ssh/id_ed25519_repo
cat ~/.ssh/id_ed25519_repo.pub   # paste into the repo's Deploy Keys
git config --global user.name "Agent (build box)"
git config --global user.email "agent@example.com"

tmux iş akışı

Kurulumu yapın (sudo apt install tmux), ardından minimal bir ~/.tmux.conf oluşturun:

set -g mouse on
set -g history-limit 50000
set -g default-terminal "tmux-256color"

Dört komut günlük kullanımı karşılar:

tmux new -A -s claude     # attach to session "claude", creating it if absent
# ...run `claude` inside it, work normally...
# Ctrl-b then d           -> detach; everything keeps running
tmux ls                   # list sessions
tmux attach -t claude     # reattach, from this machine or any other
tmux kill-session -t claude

tmux new -A -s claude ezberlenmesi gereken komuttur; oturum mevcutsa bağlar, değilse oluşturur. Böylece tek bir komut hem güne başlarken hem de bağlantı koptuktan sonra geri dönerken kullanılır. Bu komuta bir alias atayın. Oturum içindeyken Ctrl-b c yeni bir pencere açar, Ctrl-b n ve Ctrl-b p pencereler arasında geçiş yapar, Ctrl-b [ ise geriye dönük kaydırma yapmak için kopyalama modunu başlatır (q bu moddan çıkar).

Asla sonlandırmadığınız oturumlar hakkında bilinmesi gereken bir husus şudur: agent, her adımda tüm konuşmayı yeniden gönderir. Bu nedenle, bir oturumu bir hafta boyunca açık bırakmadan önce uzun süreli bir Claude Code oturumunun token'larını neye harcadığına göz atın.

Hata modları

"Oturumum kayboldu." tmux ls, no server running on /tmp/tmux-1000/default çıktısını verir. Bu durum neredeyse her zaman sürecin hiçbir zaman tmux içinde çalışmadığı anlamına gelir; SSH ile giriş yaptınız, claude komutunu doğrudan çalıştırdınız ve bağlantının kesilmesi süreci sonlandırdı. Kurtarılacak bir şey yoktur. Bunu önleyen alışkanlık şudur: Her girişten sonra çalıştırılan ilk komut tmux new -A -s <project> olmalıdır.

Bölme (pane) küçücük bir kutuya dönüşüyor. window-size seçeneği, hangi bağlı istemcinin boyut belirleyeceğine karar verir. tmux 3.1 sürümünden bu yana (Ubuntu 24.04, 3.4 sürümüyle gelir) varsayılan değer latest'dir; yani en son etkinlik gösteren istemci baz alınır. Ancak window-size smallest ayarını içeren bir yapılandırma, boyutu en küçük bağlı istemciye göre ayarlar; bu nedenle başka bir makineden bağlı kalan eski bir istemci ekranı daraltır. Bağlanırken diğerlerini zorla ayırmak için şunu kullanın: tmux attach -d -t claude.

Bir derleme işlemi Killed çıktısı veriyor. Tek kelime, yığın izi (stack trace) yok. sudo dmesg -T | grep -i -E 'out of memory|killed process' ile doğrulayın; çekirdeğin OOM (Out of Memory) katili en büyük süreci seçmiştir. Node tarafında bunun yerine FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory görebilirsiniz. Çözümler sırasıyla şunlardır: swap alanı ekleyin (yukarıda), test ve derleyici paralelliğini sınırlayın, Node yığın boyutunu NODE_OPTIONS=--max-old-space-size=... ile artırın veya VPS boyutunu yükseltin. OOM katili derleme süreci yerine tmux sunucusunu da seçebilir ve oturumunuzu sonlandırabilir; eğer systemd-oomd çalışıyorsa, tüm kullanıcı dilimini (slice) sonlandırarak aynı etkiyi yaratabilir.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root sahipliğindeki bir önek (prefix) içine yapılan global kurulum. Yukarıdaki ~/.npm-global önekini kullanın. Eğer daha önce sudo npm komutunu çalıştırdıysanız Your cache folder contains root-owned files hatasını da görebilirsiniz; sudo chown -R $(id -u):$(id -g) ~/.npm ile onarın.

claude: command not found, ama sadece bazen. PATH dışa aktarma (export) işleminiz ~/.bashrc dosyasında "Etkileşimli değilse hiçbir şey yapma" korumasının altında kalıyor, bu yüzden etkileşimli olmayan kabuklar bunu atlıyor. Dışa aktarma komutunu bu korumanın üzerine taşıyın ve ~/.bashrc içinde tutun: varsayılan bir tmux bölmesi, Ubuntu'nun ~/.profile dosyası aracılığıyla ~/.bashrc dosyasına ulaşan bir giriş kabuğudur (login shell); giriş kabuğu olmayan herhangi bir kabuk ise ~/.bashrc dosyasını doğrudan okur, bu nedenle tek bir dosya her ikisini de kapsar.

Bağlandıktan sonra bozuk renkler. Bir TERM uyuşmazlığı; yukarıdaki default-terminal satırı bu sorunu çözer.

Yeniden başlatma sonrası oturumlar kayboluyor. Bu bir hata değildir: tmux sunucusu bir süreçtir ve yeniden başlatma işlemi onu sonlandırır. uptime dosyasını kontrol edin.

Büyüme sürecinde neler aksar

Daha fazla proje. Her depo için depo adıyla isimlendirilmiş bir tmux oturumu kullanın; tmux ls bu durumda kontrol paneliniz olur. İsimlendirme disiplinini atlarsanız 0, 1, 2 gibi oturumlarla karşılaşırsınız. Birkaç oturum aynı anda çalıştığında bunların izole olmaları gerekmez; aynı sunucudaki bir oturum diğerine mesaj gönderebilir. Bu, uzun süren bir refactoring işlemini yürüten ajanın, testleri çalıştırması için ikinci bir ajana ihtiyaç duyduğu durumlarda kullanışlıdır. Portlar da aynı şekilde kontrolsüzce artar; altı deponun da :3000 portunu istemesi, manuel atamayı bırakıp Docker Compose üzerinde bir Traefik reverse proxy'nin ana makine adına göre yönlendirme yapmasını sağlamanız gereken noktadır.

Daha fazla kişi. tmux soketleri kullanıcı bazlıdır; dolayısıyla aynı sunucudaki iki geliştirici kendi tmux sunucularına sahip olur ve birbirlerinin oturumlarını göremezler. Tek bir oturumu paylaşılan bir soket üzerinden kullanmak, herkesin aynı Unix kullanıcısı olarak aynı kabuğa yazması anlamına gelir; bu da denetim ve izinler açısından ciddi sonuçlar doğurur. Ayrı kullanıcılar kullanmak, sıkıcı ama doğru olan yöntemdir.

Gözetimsiz işler. tmux, bağlandığınız interaktif oturumlar içindir. Kimsenin izlemediği ve bir zamanlamaya göre çalışan işler, systemd unit ve timer yapısına aittir. Bu yapıda loglama, yeniden başlatma politikası ve sistem açılışında otomatik çalışma gibi özellikler kendiliğinden gelir. Bir cron işini çalıştırmak için tmux kullanmak, o işin artık bir servis haline gelmesi gerektiğinin işaretidir.

Son bir not: ajanın başlattığı geliştirme sunucularını 0.0.0.0 yerine 127.0.0.1 adresine bağlayın ve ufw üzerinde port açmak yerine SSH tüneli (ssh -L 3000:127.0.0.1:3000 agent@your-server) üzerinden erişin. Yarım düzine portu yönlendirmeye başladığınızda veya bir telefon ile bir dizüstü bilgisayar aynı önizlemeye erişmek istediğinde, bunun yerine VPS üzerinde kendi kendine barındırılan bir WireGuard VPN kurun: geliştirme sunucuları özel bir arayüze bağlanır ve ufw, genel arayüzden gelen her şeyi reddetmeye devam eder. Güvenlik duvarı, ancak üzerinde delikler açmayı bıraktığınızda işe yarar.

Claude Code tek seçenek değildir: VPS üzerinde bir kodlama yapay zeka ajanı çalıştırmak için Aider ve Goose seçenekleri de değerlendirilmelidir.

FAQ

SSH bağlantım koptuğunda Claude Code çalışmaya devam eder mi?

Yalnızca tmux içinde başlattıysanız devam eder. Doğrudan SSH kabuğu üzerinden başlatılan bir süreç, o kabuğun alt sürecidir ve bağlantı koptuğunda pty ile birlikte sonlanır. tmux içinde ise kabuk, bağlantısı kesilmiş (detached) tmux sunucusuna aittir; bu sayede aracı görevine devam eder ve tmux attach sizi aynı kaydırma geçmişine geri döndürür. Her oturum açma işleminden sonra tmux new -A -s <project> komutunu ilk sırada çalıştırırsanız bu sorun ortadan kalkar.

CLI aracını sudo npm install -g ile mi kurmalıyım?

Hayır. root sahipliğindeki bir global önek, sonraki kurulumlarda EACCES hatalarına ve npm önbelleğinde root sahipliğinde dosyalara yol açar. npm önekini ~/.npm-global olarak ayarlayın (veya nvm gibi bir sürüm yöneticisi kullanın), kurulumu yetkisiz agent kullanıcısı olarak yapın ve ~/.npm-global/bin değişkenini ~/.bashrc dosyasında, etkileşimli koruma bloğunun üzerinde PATH yoluna ekleyin. Eğer sudo npm komutunu bir kez çalıştırdıysanız, önbelleği sudo chown -R $(id -u):$(id -g) ~/.npm ile onarın.

Bir aracı çalıştıran sunucuda ssh -A aracı yönlendirmesi (agent forwarding) güvenli midir?

Bu yöntem, işin gerektirdiğinden çok daha fazla yetki verir. Yönlendirme, yerel SSH aracınızın soketini o kullanıcıyla çalışan her sürece açar; bu da sunucudaki herhangi bir şeyin, siz bağlı kaldığınız sürece anahtarınızdan erişebildiği her ana bilgisayar için imza istemesine olanak tanır. Sunucuda bir ed25519 anahtarı oluşturun ve bunu depo bazlı bir dağıtım anahtarı (deploy key) olarak kaydedin; eğer aracın gerçekten push yapması gerekiyorsa yalnızca yazma erişimi verin.

Derleme işlemim neden sadece Killed çıktısı veriyor?

Yığın izi (stack trace) olmayan tek kelimelik bu çıktı, çekirdeğin OOM (Out of Memory) sonlandırıcısıdır. Bunu sudo dmesg -T | grep -i -E 'out of memory|killed process' ile doğrulayın; Node üzerinden çalışıyorsanız JavaScript heap out of memory mesajını da görebilirsiniz. Çözümleri sırasıyla uygulayın: bir swap dosyası ekleyin, test ve derleyici paralelliğini sınırlayın, NODE_OPTIONS=--max-old-space-size=... değerini yükseltin ve ardından VPS boyutunu artırın. OOM sonlandırıcısının derleme süreci yerine tmux sunucusunu seçebileceğini ve tüm oturumunuzu sonlandırabileceğini unutmayın.

tmux mı yoksa systemd servisi mi?

tmux, bağlanıp izlediğiniz ve içine komut yazdığınız etkileşimli oturumlar için uygundur; bir aracı oturumu tam olarak budur. Kimsenin izlemediği ve belirli bir zamanlamaya göre çalışan işler, günlüğe kaydetme, yeniden başlatma politikası ve sistem açılışında otomatik çalışma gibi özelliklerin hazır geldiği bir systemd birimine ve zamanlayıcısına (timer) aittir. Eğer cron benzeri bir işi çalıştırmak için tmux kullanıyorsanız, o iş bir servis olmalıdır.