VPS üzerinde self-hosted GitHub Actions runner kurulumu

Self-hosted GitHub Actions runner nedir

Self-hosted GitHub Actions runner, kendi VPS'nize kurduğunuz ve GitHub'dan iş talep edip bunları kendi donanımınız üzerinde çalıştıran bir programdır. Runner'ı belirli bir depoya kaydeder, bir systemd servisi olarak kurarsınız; böylece her yeniden başlatma sonrasında otomatik olarak çalışmaya devam eder. GitHub işi zamanlar, sunucunuz ise işi gerçekleştirir.

Kendi sunucunuz üzerinde CI (sürekli entegrasyon) çalıştırmanın iki temel avantajı vardır. Derleme süreleri için kota uygulanmaz ve işler, yalnızca makinenizin erişebildiği sıcak derleme önbelleği veya özel ağ gibi kaynaklara ulaşabilir. Bunun bedeli ise güvenliktir. Runner, kendisine tanımladığınız kullanıcı yetkileriyle, iş akışı dosyasında (workflow file) belirtilen her komutu çalıştırır; bu nedenle iş akışı dosyaları, doğası gereği uzaktan kod yürütme (remote code execution) anlamına gelir. Özel bir depoda bu durum kabul edilebilirdir, çünkü yalnızca güvendiğiniz kişiler dosya ekleyebilir. Halka açık bir depoda ise bu ciddi bir risktir; fork üzerinden gelen pull request'ler hakkındaki bölüm bu mekanizmayı açıklamaktadır.

Aşağıdaki tüm işlemler, 12 Ekim 2026 itibarıyla güncel sürüm olan 2.338.0 numaralı runner sürümü ve Ubuntu 24.04 işletim sistemi temel alınarak hazırlanmıştır.

Başlamadan önce gerekenler

Yeni bir VPS üzerinde ilk on dakika rehberinde ulaştığınız, sudo yetkilerine sahip standart bir yönetici hesabıyla yapılandırılmış bir VPS ile başlayın. Gelen bağlantılar için herhangi bir port açmanız gerekmez. Runner, GitHub'a giden bir HTTPS (hypertext transfer protocol secure) bağlantısı başlatır ve iş beklerken bu bağlantıyı açık tutar; bu nedenle GitHub sunucunuza doğrudan bağlanmaz. Güvenlik duvarınız dış dünyaya kapalı kalsa dahi işler sunucunuza ulaşmaya devam eder.

Ayrıca, kayıt belirteci (registration token) depo ayarlarında görüntülendiği için depo üzerinde yönetici haklarına sahip olmanız gerekir.

Runner için özel bir kullanıcı oluşturun

Runner'ı asla root veya kendi yönetici kullanıcınızla çalıştırmayın. Her iş, runner kullanıcısının haklarını devralır; bu nedenle sudo komutunu çağıran bir iş akışı, runner kullanıcısı sudo kullanabiliyorsa başarılı olur. Yalnızca kendi ev dizini dışında hiçbir şeyin sahibi olmayan, ayrıcalıksız bir kullanıcı oluşturun. VPS üzerinde en az ayrıcalıklı kullanıcı hesapları genel modeli kapsar. Burada ise özel durum ele alınmıştır.

sudo useradd -m -s /bin/bash gharunner
sudo passwd -l gharunner
sudo chmod 750 /home/gharunner
sudo install -d -m 700 -o gharunner -g gharunner /home/gharunner/actions-runner

passwd -l parolayı kilitler, böylece hiç kimse parola ile gharunner kullanıcısı olarak giriş yapamaz. Runner dizinindeki 700 modu önemlidir çünkü runner kimlik bilgilerini orada düz metin olarak saklar ve bir checkout işlemi özel kaynak kodları içerebilir.

Devam etmeden önce her iki özelliği de kontrol edin:

sudo passwd -S gharunner
sudo -l -U gharunner

passwd -S, gharunner L ile başlayan bir satır yazdırır; burada L parolanın kilitli olduğu anlamına gelir. sudo -l -U gharunner, is not allowed to run sudo ile yanıt vermelidir. Eğer bunun yerine izin verilen komutların bir listesini yazdırırsa, hesap bir sudo grubundadır ve oluşturduğunuz izolasyon geçersiz kalmış demektir.

Runner'ı indirin ve tarball dosyasını kontrol edin

Bu noktadan itibaren runner kullanıcısı olarak çalışın.

sudo -iu gharunner
cd ~/actions-runner
RUNNER_VERSION=2.338.0
curl -fL -o actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz \
  "https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"

Mimarinizden emin değilseniz önce uname -m komutunu çalıştırın. x86_64 komutu yukarıdaki linux-x64 dosyasını kullanır. aarch64 komutu ise actions-runner-linux-arm64-${RUNNER_VERSION}.tar.gz dosyasını kullanır.

Şimdi indirdiğiniz dosyayı doğrulayın. Aşağıdaki SHA256 (secure hash algorithm, 256 bit) değeri, 2.338.0 x64 tarball dosyası içindir. GitHub, güncel sürüme ait değeri sürüm sayfasında ve "New self-hosted runner" ekranında yayınlar. Bu değer her sürümde değiştiği için, farklı bir sürüm kurarken değeri ilgili sayfadan kopyalayın.

echo "af4b794c1bc41d73d40535e3fe092a39f9679cd8d965954c2aca25a05ca41d32  actions-runner-linux-x64-2.338.0.tar.gz" | sha256sum -c

Başarılı bir indirme işlemi tek satırlık bir çıktı üretir:

actions-runner-linux-x64-2.338.0.tar.gz: OK

Eksik veya değiştirilmiş bir dosya, hata mesajı ve uyarı verir:

actions-runner-linux-x64-2.338.0.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Kontrolü atlamayın ve sorunu tar komutunun bulmasına izin vermeyin. Yarım kalmış bir arşiv dosyası gzip: stdin: unexpected end of file ve tar: Unexpected EOF in archive hatalarıyla başarısız olur; bu hata size dosyanın bozuk olduğunu söyler ancak dosyanın eksik mi indiğini yoksa değiştirildiğini mi belirtmez.

tar xzf ./actions-runner-linux-x64-2.338.0.tar.gz
ls

Tarball içeriği ve kapsamı

Çıkarma işleminden sonra dizin config.sh, run.sh, env.sh, safe_sleep.sh, bin/ ve externals/ dosyalarını içerir. bin/, çalıştırıcı ikili dosyalarını ve bin/installdependencies.sh öğesini barındırır. externals/, JavaScript eylemlerinin üzerinde yürütüldüğü paketlenmiş Node çalışma zamanını tutar.

Henüz svc.sh mevcut değildir. GitHub belgeleri bunu, "çalıştırıcı başarıyla eklendikten sonra oluşturulan" betik olarak tanımlar; çünkü bu betik, depo ve çalıştırıcı adınızın servis adına işlendiği bir şablondan yazılır. Bu nedenle ./config.sh öncesinde sudo ./svc.sh install çalıştırmak sudo: ./svc.sh: command not found hatasıyla sonuçlanır. Önce kaydı tamamlayın, ardından servisi kurun.

Runner bağımlılıklarını yükleme

Runner bir .NET uygulamasıdır, bu nedenle bazı paylaşımlı kütüphanelere ihtiyaç duyar. Runner kullanıcısının kabuğundan çıkın ve bunları sudo ile yükleyin; çünkü betik, sistem paket veritabanına yazma işlemi gerçekleştirir.

exit
cd /home/gharunner/actions-runner
sudo ./bin/installdependencies.sh

Ubuntu 24.04 üzerinde bu işlem libkrb5-3, zlib1g, liblttng-ust1t64, libssl3t64 ve libicu74 paketlerini çeker. Betik, her kütüphane için çeşitli sürüm isimlerini dener ve dağıtımınızın sunduğu sürümü tutar; aynı betiğin hem eski Ubuntu sürümlerinde hem de Debian üzerinde çalışmasının nedeni budur.

Bu adımı atlarsanız ve bu kütüphanelerden biri eksikse, ./config.sh herhangi bir işlem yapmadan durur:

Dependencies is missing for Dotnet Core 6.0
Execute sudo ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies.

Eksik bir libicu, farklı bir ilk satır olan Libicu's dependencies is missing for Dotnet Core 6.0 altında aynı uyarıyı verir. Her ikisi de aynı kaynaktan gelir: config.sh, başlatılmadan önce paketlenmiş kütüphaneleri ldd ile, libicu ise ldconfig ile kontrol eder. Bu sayede çözülemeyen bir bağlantı, daha sonra kafa karıştırıcı bir çökmeye yol açmak yerine betiği durdurur.

Runner'ı deponuz ile kaydedin

Depodan bir token alın. Settings, ardından Actions, ardından Runners ve son olarak New self-hosted runner yolunu izleyin. Sayfa bir kayıt token'ı görüntüler. Bu token oluşturulduktan bir saat sonra geçerliliğini yitirir; bu nedenle yapıştırmaya hazır olduğunuzda oluşturun.

Runner kullanıcısı olarak kayıt işlemini gerçekleştirin. config.sh, sudo altında çalışmayı reddeder.

sudo -iu gharunner
cd ~/actions-runner
./config.sh --url https://github.com/YOUR-USER/YOUR-REPO \
  --token PASTE_REGISTRATION_TOKEN_HERE \
  --name vps-runner-1 \
  --labels vps \
  --work _work \
  --unattended \
  --replace

Bu bayrakların işlevleri şöyledir: --name, runner'ın depoda nasıl görüneceğini belirler; bu nedenle altı ay sonra da tanıyabileceğiniz bir isim seçin. --labels kendi etiketlerinizi ekler; runner zaten herhangi bir ekleme yapmadan self-hosted, Linux ve X64 etiketlerini taşır. --work, checkout işlemlerinin runner dizini içinde nereye yapılacağını belirler. --unattended, etkileşimli istemleri varsayılan değerleriyle yanıtlar; komut bir betik içinde çalıştırıldığında istenen davranış budur. --replace, aynı isimli mevcut bir kaydı hata vermek yerine devralır; sunucuyu yeniden oluşturduğunuzda ihtiyaç duyacağınız yöntem budur.

Başarılı bir çalıştırma şu satırlarla sona erer:

√ Runner successfully added
√ Runner connection is good
√ Settings Saved.

Kayıt bilgileri artık runner dizininde .runner, .credentials ve .credentials_rsaparams dosyaları olarak saklanır. Son iki dosya, bu runner'ı GitHub'a tanıtır; bu nedenle bu dosyaları okuyabilen herkes runner'ı taklit edebilir. Dizinin 700 modunda olmasının ve kullanıcının sudo yetkisinin bulunmamasının nedeni budur.

Runner'ı systemd servisi olarak kurma

./run.sh komutunu terminalde çalıştırmak tek seferlik testler için uygundur ancak SSH oturumunuz kapandığında süreç sonlanır. Runner'ın sistem açılışında otomatik başlaması için servisi kurun. VPS üzerinde systemd servisleri ve zamanlayıcılar dokümanı, unit dosyalarının yapısını açıklar. Burada svc.sh sizin yerinize bir tane oluşturur.

exit
cd /home/gharunner/actions-runner
sudo ./svc.sh install gharunner
sudo ./svc.sh start
sudo ./svc.sh status

svc.sh, /etc/systemd/system dizinine bir unit dosyası yazıp bunu etkinleştirdiği için root yetkisi gerektirir. install bayrağından sonra gelen argüman, servisin hangi kullanıcı yetkisiyle çalışacağını belirler. gharunner değerini açıkça belirtin. Herhangi bir argüman girilmezse betik, yönetici hesabınız olan $SUDO_USER değerine döner; bu durumda tüm işler sudo yetkisine sahip bir kullanıcı olarak çalıştırılır.

Unit dosyası, depo ve runner ismine göre actions.runner.YOUR-USER-YOUR-REPO.vps-runner-1.service formatında adlandırılır. Bunu manuel yazmanıza gerek yoktur:

systemctl list-units 'actions.runner.*'
sudo journalctl -u 'actions.runner.*' -n 20 --no-pager

Sorunsuz çalışan bir runner, √ Connected to GitHub logunu ve ardından Listening for Jobs ile biten bir satırı çıktı olarak verir; deponun Runners sayfasında ise durumu Idle olarak görünür. Offline görünen bir runner ya çalışmıyordur ya da 443 numaralı port üzerinden GitHub'a erişemiyordur.

Runner'a iş gönderme

runs-on, bir runner'ı etiketine göre seçer. self-hosted değerini ve kendi etiketinizi belirtin; böylece bir iş, hedeflemediğiniz bir runner üzerinde çalışmaz.

name: build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: [self-hosted, linux, vps]
    steps:
      - uses: actions/checkout@v5
      - run: uname -a

Eğer iş Waiting for a runner to pick up this job aşamasında bekliyorsa, etiketler eşleşmiyor demektir. runs-on içindeki her etiketin runner üzerinde tanımlı olması gerekir; fazladan bir kelime bile işin herhangi bir hata vermeden kuyrukta kalmasına neden olur. Listeyi, depo ayarlarında runner'ın yanında gösterilen etiketlerle karşılaştırın.

Self-hosted runner'lar ile herkese açık depolar neden bir arada kullanılmamalıdır

İnsanların göz ardı ettiği kısım burasıdır. GitHub'ın rehberliği oldukça nettir: self-hosted runner'lar "herkese açık depolar için neredeyse hiçbir zaman kullanılmamalıdır" ve bu runner'lar "geçici, temiz sanal makinelerde çalışma garantisine sahip değildir; iş akışındaki güvenilmeyen kodlar tarafından kalıcı olarak ele geçirilebilirler".

Mekanizma basittir. Bir fork üzerinden gelen pull request, kendi iş akışı dosyası kopyasını beraberinde getirir. Eğer herkese açık deponuz, pull request iş akışlarını kendi runner'ınız üzerinde çalıştırıyorsa, depoyu fork edebilen herkes kendi komutlarını VPS'niz üzerinde çalıştıracak bir iş akışı önerebilir. Yazma erişimine ihtiyaçları yoktur, çünkü önerdikleri şey zaten çalışacak olan şeydir.

Onay ayarları bu durumu düzeltmeden hafifletir. Herkese açık bir depo için varsayılan politika, bir bakım sorumlusunun ilk kez katkıda bulunan birinin fork iş akışını onaylamasını ister. GitHub, birini yalnızca herhangi bir commit'i veya pull request'i depoya merge edilene kadar "ilk kez katkıda bulunan" olarak sayar. Bundan sonra, sonraki pull request'leri herhangi bir uyarı olmadan çalışır ve GitHub'ın kendisi, önemsiz bir merge edilmiş düzeltmenin bile buna ulaşmak için yeterli olduğu konusunda uyarır. Dolayısıyla engel, bir diff'i okuyan insandır ve bir build betiğinin üç seviye altına gizlenmiş bir payload'u gözden kaçırmak kolaydır.

Bir fork pull request'i sırlarınızı almaz ve GITHUB_TOKEN salt okunurdur. Bu durum GitHub içindeki hasarı sınırlar. Ancak sunucunuz için hiçbir şey yapmaz. Saldırgan gharunner olarak bir shell'e sahiptir; bu sayede o kullanıcının okuyabildiği her dosyayı okuyabilir, VPS'nin özel ağında erişebildiği her yere ulaşabilir ve ~/.bashrc dizininde veya bir sonraki iş sırasında çalışan bir kullanıcı systemd biriminde kalıcı bir iz bırakabilir.

--ephemeral ile kayıt yapmak, runner'ın bir işi kabul edip ardından kaydını silmesini sağlar; böylece bir iş, bir sonraki işin çalışma alanını okuyamaz. Bu yöntem yalnızca makineyi veya container'ı her iş için yeniden oluşturan bir sistem varsa işe yarar; çünkü runner kullanıcısının ev dizinine yazılan bir arka kapı, yeni bir kayıttan sonra da varlığını sürdürür.

Aşağıdaki kurallar kısadır. Self-hosted runner'ları yalnızca özel depolar için kullanın. Eğer herkese açık bir depoya bağlamanız gerekiyorsa, üzerinde fork pull request'leri çalıştırmayın, o sunucuda başka hiçbir şey barındırmayın ve makineyi atılabilir olarak değerlendirin.

Docker işleri ve aslında root olan grup

Container işleri, servis container'ları ve docker build komutunu çağıran her türlü iş akışı adımı, runner sunucusu üzerinde bir Docker daemon'ına ihtiyaç duyar. Docker'ı, VPS üzerinde Docker ve Docker Compose rehberinde anlatıldığı şekilde kurun ve ardından runner kullanıcısını docker grubuna ekleyin.

Bu işlemi yapmadan önce getireceği riskleri anlayın. docker grubuna üyelik, root yetkisine eşdeğerdir; çünkü bir container, / dizinini bind mount edebilir ve içerisinde root olarak çalışabilir. Dolayısıyla, Docker socket ile iletişim kurabilen bir iş akışı, /etc/shadow dahil olmak üzere VPS üzerindeki her dosyayı okuyabilir ve değiştirebilir. Güvenilir katkıcıların bulunduğu özel bir depoda bu kabul edilebilir bir bedel olabilir. Bunun dışındaki durumlarda ise, ayrıcalıksız kullanıcı kullanmanın bir anlamı kalmaz. Rootless Docker, container derlemelerini runner kullanıcısının kendi yetkileri dahilinde tutar; ancak bunun bedeli, daha yavaş bir depolama sürücüsü ve ayrıcalıklı container'ların kullanılamamasıdır.

Güncellemeler ve runner'ın temiz bir şekilde kaldırılması

Self-hosted runner varsayılan olarak kendini günceller. Yeni bir sürüm yayınlandığında bunu algılar, kendi dosyalarını değiştirir ve servisi yeniden başlatır; bu nedenle normal şartlarda herhangi bir işlem yapmanız gerekmez. Otomatik güncellemeyi kapatmak için runner'ı kaydederken --disableupdate bayrağını ./config.sh komutuna ekleyin; halihazırda kayıtlı bir runner için bu, bayrağı kullanarak yeniden kaydetmek anlamına gelir. Bu işlem, süresiz olarak tek bir sürümde kalmanıza izin vermez. GitHub dokümantasyonu, --disableupdate ile yapılandırılmış bir runner'ın bile yeni bir sürüm yayınlandıktan sonra 30 gün içinde manuel olarak güncellenmesi gerektiğini, aksi takdirde GitHub'ın bu runner'a iş kuyruğuna almayı durduracağını açıkça belirtir.

Manuel güncelleme, kayıt bilgilerini korur çünkü .runner ve .credentials dosyaları tarball içerisinde yer almaz. Servisi durdurun, yeni tarball dosyasını indirin ve gharunner ile sağlama toplamını doğrulayın, ardından tar xzf ile aynı dizine çıkartın ve servisi tekrar başlatın:

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh start

Runner'ı kaldırmak için önce servisi kaldırın, ardından kaydını silin. Kaldırma belirteci (token), aynı Runners sayfasında, runner'ın kendi Remove düğmesi altında bulunur.

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh uninstall
sudo -iu gharunner
cd ~/actions-runner
./config.sh remove --token PASTE_REMOVAL_TOKEN_HERE

Kaydı silmeden dizini silmek, runner'ın depoda Offline olarak listelenmeye devam etmesine neden olur. Runner, bir yönetici Force remove this runner düğmesine tıklayana veya GitHub bağlantı kesildikten 14 gün sonra otomatik olarak kaldırana kadar orada kalır.

Hata modları ve karşılaşacağınız dizgeler

Must not run with sudo. config.sh, root kullanıcısı olarak çalıştırıldığında bu mesajı yazdırır ve sonlanır. Bu denetim kasıtlıdır; çünkü _work dizinindeki root sahipli dosyalar, servis kullanıcısı olarak çalışan sonraki tüm işleri bozar. ./config.sh komutunu gharunner olarak çalıştırın. RUNNER_ALLOW_RUNASROOT değişkeni bu denetimi devre dışı bırakır ancak kullanımı, sorunun sadece daha sonra ortaya çıkmasına neden olur.

sudo: ./svc.sh: command not found. Doğru dizindesiniz. svc.sh henüz mevcut değil, çünkü config.sh bir kayıt işlemini tamamlamadı. Runner'ı kaydedin, ardından servisi kurun.

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration'. Genellikle token geçerli bir kayıt token'ı değildir. Bir saatlik ömürleri olduğu için süresi dolmuş olabilir veya Runners sayfasından alınan kayıt token'ı yerine yanlışlıkla kişisel erişim token'ı yapıştırılmış olabilir. Yeni bir token oluşturup tekrar yapıştırın ve --url değerinin tam depo URL'si olduğunu doğrulayın.

Dependencies is missing for Dotnet Core 6.0. sudo ./bin/installdependencies.sh komutunu runner dizininden root yetkileriyle çalıştırın, ardından tekrar kaydetmeyi deneyin.

Yeniden başlatma sonrası Runner Çevrimdışı (Offline). systemctl is-enabled 'actions.runner.*' komutunu çalıştırın. Listede hiçbir şey görünmüyorsa ./svc.sh install hiç çalıştırılmamış demektir; bu durumda runner yalnızca terminal oturumunuzun içinde var olmuştur. Eğer unit etkinleştirilmişse ve runner hala Çevrimdışı görünüyorsa, journalctl -u 'actions.runner.*' içeriğini okuyun ve giden HTTPS trafiğini kontrol edin.

Disk doluyor. Checkout işlemleri, derleme önbellekleri ve Docker imajları _work altında ve runner kullanıcısının ev dizininde birikir; sistem bunları sizin yerinize otomatik olarak temizlemez. du -sh /home/gharunner/actions-runner/_work dizinini izleyin ve disk dolmadan önce zamanlanmış bir temizleme görevi ekleyin.

FAQ

Neden sudo ./svc.sh install komutu bulunamadı hatası veriyor?

Çünkü svc.sh, runner tarball dosyası içerisinde yer almaz. Bu dosya, ./config.sh kayıt işlemi tamamlandığında, depo ve runner adınızı kullanarak servis ismini oluşturmak üzere runner dizininde üretilir. ./config.sh komutunu öncelikle runner kullanıcısı ile çalıştırın. Bu işlemden sonra sudo ./svc.sh install gharunner betiği bulur ve actions.runner.OWNER-REPO.RUNNER-NAME.service isimli bir unit dosyasını /etc/systemd/system dizinine yazar.

Self-hosted runner için güvenlik duvarında port açmam gerekiyor mu?

Hayır. Runner, GitHub'a giden bir HTTPS bağlantısı başlatır ve iş beklerken bu bağlantıyı açık tutar; dolayısıyla GitHub, VPS sunucunuza hiçbir zaman doğrudan bağlantı başlatmaz. Yalnızca giden 443 trafiğine izin verin ve gelen kurallarınızı kapalı tutun. Servis çalışır durumdayken runner Offline görünüyorsa, gelen kurallar yerine giden trafik filtrelemesine ve DNS ayarlarına bakın.

Herkese açık bir depoda self-hosted runner kullanabilir miyim?

Kullanabilirsiniz ancak GitHub bunu önermemektedir. Bir fork üzerinden gelen pull request kendi workflow dosyasını içerir; bu nedenle deponuzu fork edebilen herkes, makinenizde çalışacak komutlar önerebilir. Varsayılan onay istemi, yalnızca daha önce depoya commit veya pull request'i merge edilmemiş katkıda bulunanları kapsar. Eğer bir runner'ı herkese açık bir depoya bağlarsanız, bu depoda fork pull request workflow'larını devre dışı bırakın, sunucuda başka hiçbir şey barındırmayın ve makineyi düzenli aralıklarla yeniden kurun.

Kayıt işlemi neden Http response code: NotFound hatası ile başarısız oluyor?

Kayıt çağrısı, yalnızca URL yanlış olduğunda değil, kimlik bilgileri hatalı olduğunda da NotFound yanıtı döndürür; bu durum hata mesajını yanıltıcı kılar. Kayıt token'ları gösterildikten bir saat sonra geçerliliğini yitirir ve bu çağrı için kişisel erişim token'ı (personal access token) kabul edilmez. Settings, Actions, Runners, New self-hosted runner adımlarını izleyerek yeni bir token alın ve --url değerinin yönetici haklarına sahip olduğunuz bir depoyu işaret ettiğinden emin olun.