FAQ

Sık sorulan sorular

Hizmet kurulumu, erişim ve ortak müşteri işlemleri için pratik kısa kılavuzlar.

> Terminalde genel SSH anahtarı oluşturma

Erişim için genel SSH anahtarı oluştur ve yalnızca genel kısmı paylaş.
faq/generate-public-ssh-key-tr

Yalnızca genel anahtarı kullan

SSH bir anahtar çifti kullanır. Hizmet ayarlarına yalnızca genel anahtarı, genellikle .pub dosyasını, yapıştır. Özel anahtar cihazında kalır.

Terminal adımları

  1. Terminal, Windows Terminal veya PowerShell aç.
  2. Çalıştır: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Varsayılan konumu kabul et veya güvenli bir yol seç.
  4. Genel anahtarı göster: cat ~/.ssh/id_ed25519.pub.
  5. Windows PowerShell de kullan: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Tüm ssh-ed25519 satırını SSH public key alanına kopyala.

Yapıştırmadan önce kontrol et

Özel anahtarı kopyalama. Passphrase ayarlarsan güvenli şekilde sakla.

> Windows arayüzünde SSH anahtarı oluşturma

Windows ta PuTTYgen kullan ve yalnızca genel anahtarı kopyala.
faq/create-ssh-key-windows-gui-tr

Genel bölüm yeterlidir

PuTTYgen genel ve özel anahtar oluşturur. Cli>_ içine yalnızca genel anahtarı ekle, özel anahtarı yerel olarak sakla.

Windows adımları

  1. PuTTYgen i aç.
  2. Varsa EdDSA / Ed25519 seç.
  3. RSA 4096 yalnızca yedek seçenek olsun.
  4. Generate düğmesine tıkla ve anahtar oluşana kadar fareyi hareket ettir.
  5. Özel anahtarı bilgisayarına kaydet.
  6. Genel anahtar metnini SSH public key alanına kopyala.

Gizli verileri paylaşma

.ppk dosyaları, özel anahtarlar, passphrase, parolalar veya tokenları destek ekibine ya da formlara gönderme.

> Kendi alan adini bagla

Alan adı geçişinden önce registrar, authoritative nameservers, exact hostname, apex domain veya subdomain, kayıt tipi ve çakışmaları kontrol et.
faq/kendi-alan-adini-bagla

Kesin hostname belirleyicidir

Önce example.com gibi apex domain mi yoksa app.example.com gibi subdomain mi bağladığını belirle. Buna göre CNAME, A/AAAA, ALIAS veya ANAME kayıtlarının desteklenip desteklenmediği değişir.

DNS değişikliğinden önce

  1. DNS düzenlediğin yerin authoritative nameservers veya registrar olduğunu doğrula.
  2. Aynı hostname için çakışan A/AAAA, CNAME, ALIAS, ANAME veya redirect kayıtlarını kaldır.
  3. Hostname türüne ve DNS sağlayıcısının desteğine uygun kayıt tipini kullan.
  4. Üretim trafiğini çevirmeden önce DNS propagation ve sertifika kontrolünü bekle.

Güvenli geri dönüş

Yeni hostname doğru yanıt verene kadar eski hostingi kapatma. Yardım için alan adını, beklenen hedefi ve herkese açık DNS sonucunu gönder; registrar erişimi veya API tokenı paylaşma.

> DNS bolgesini devret

A/AAAA adreslere, CNAME aliasa, MX postaya, TXT doğrulama, SPF, DKIM ve DMARC değerlerine gider; CAA sertifikaları etkileyebilir.
faq/dns-bolgesini-devret

Her kaydın görevi farklıdır

A ve AAAA IP adreslerine işaret eder, CNAME izin verilen subdomain için alias oluşturur, MX postayı yönlendirir, TXT doğrulama ve mail politikalarını taşır, CAA ise sertifika otoritelerini sınırlar.

DNS değerlerini kopyalarken

  1. Ad, tip ve değeri hizmetin istediği şekilde birebir kopyala.
  2. DNS kuralları yasaklıyorsa başka kayıtları olan hostname üzerine CNAME koyma.
  3. DKIM değerini sağlayıcı selectorı altında, DMARC kaydını genelde _dmarc altında oluştur.
  4. CAA değerini dikkatli değiştir; yanlış değer sertifika verilmesini engelleyebilir.

DNS sorununu tanılama

Desteğe hostname, kayıt tipi, beklenen değer ve herkese açık görünen sonucu gönder. DNS panel girişi, API tokenı veya sır içeren ekran görüntüsü paylaşma.

> Hesap kaydı ve ilk giriş

Siparişler, faturalama ve hizmet yönetimi için ekibin uzun süre erişebileceği tek bir iş hesabı kullan.
faq/account-registration-and-login

Ekibin elinde kalan hesap

Müşteri hesabı siparişleri, fatura bilgilerini, alan adlarını ve aktif hizmetleri bir arada tutar. Kişisel bir posta kutusu yerine ekibin uzun vadede erişebileceği bir iş e-postası kullanmak daha güvenlidir.

İlk siparişten önce

  1. İş e-posta adresinle kayıt ol.
  2. Sistem isterse e-posta doğrulamasını tamamla.
  3. Ücretli siparişten önce fatura bilgilerini doldur.
  4. Hesabın için kullanılabilir olduğunda iki faktörlü korumayı aç.

Sır paylaşmadan ekip erişimi

Parolayı sohbet, bilet veya e-posta ile gönderme. Birden fazla kişi hesaba erişecekse dahili parola yöneticisi veya ekip prosedürü kullanın; destek ekibinin parolana ya da özel tokenına ihtiyacı yoktur.

> Ön ödemeli kredi nasıl çalışır

Ön ödemeli kredi bakiyeyi, tahmini çalışma süresini, aktif hizmetlerin günlük maliyetini ve askıya alma ya da görünür silme tarihi riskini gösterir.
faq/prepaid-credit-how-it-works

Kredi hizmet çalışırken azalır

Uygun hizmetlerde kredi, aktif çalışma süresi ve seçilen kaynaklara göre azalır. Görünür bakiye, kalan gün tahmini ve günlük fiyat, yüklemeyi askıya almadan önce planlamanı sağlar.

Kesintiyi önleme

  1. Müşteri alanından krediyi yeterli payla yükle.
  2. Sipariş veya değişiklik onaylamadan önce yeni günlük fiyatı kontrol et.
  3. Düşük bakiye, askıya alma ve görünür silme tarihi uyarılarını izle.
  4. Askıya alınmış hizmette veriler silinmeden önce görünen tarihe dikkat et.

Bakiye beklediğin gibi değilse

Kontrol için sipariş numarası, hizmet adı ve incelenecek dönemi gönder. Kart bilgisi, parola, özel anahtar veya hassas bilgiler içeren tam ekstre paylaşma.

> Aylık tahmin, yıllık tahmin ve günlük kredi tüketimi

Aylık ve yıllık tutarlar karşılaştırma içindir; ön ödemeli hizmetler onay, gerekiyorsa ödeme ve uygulama sonrasında günlük kredi tüketir.
faq/billing-periods-and-credit-burn

Tahmin fatura takvimi değildir

Aylık tahmin 31 günü, yıllık tahmin 372 günü temel alır ve planları karşılaştırmaya yarar. Ön ödemeli hizmetlerde gerçek tüketim aktif süreye, CPU, RAM, disk ve ücretli seçeneklere bağlıdır.

Yeni fiyatı kabul etmeden önce

  1. Değişiklik öncesi ve sonrası günlük tüketimi karşılaştır.
  2. Daha fazla CPU, RAM, disk veya ek seçeneğin fiyatı değiştireceğini hesaba kat.
  3. Değişikliği yalnızca onaylandı, gerekiyorsa ödendi ve uygulandıktan sonra geçerli say.
  4. Muhasebe için sipariş onaylarını ve görünen kredi geçmişini sakla.

Tüketim kontrolü

Desteğe sipariş numarası, hizmet adı ve kontrol edilecek tarihleri gönder. Tam banka ekstresi, kart bilgisi veya gereksiz kişisel veri içeren ekran görüntüleri paylaşma.

> Ödemeden sonra sipariş durumu

Sipariş, ödeme sağlayıcısı onayını kısa süre bekleyebilir; ilk sipariş açıkça süresi dolmuş ya da iptal edilmiş değilse tekrar sipariş verme.
faq/order-status-and-payment-confirmation

Pending hemen başarısızlık değildir

Ödeme sonrasında sipariş, ödeme sağlayıcısından onay gelene kadar beklemede kalabilir. İlk sipariş açıkça başarısız veya süresi dolmuş değilken ikinci sipariş oluşturmak ödeme eşleştirmesini zorlaştırabilir.

Ödeme sonrası adımlar

  1. Ödeme sağlayıcısı sayfasından Cli>_ içine geri dön.
  2. Hesabında görünen sipariş durumunu kontrol et.
  3. Durum pending ise sağlayıcı onayını bekle.
  4. Durum değişmiyorsa sipariş numarasını ve varsa ödeme referansını gönder.

Gönderilmemesi gerekenler

Destek ekibinin kart numarasına, hesap parolasına veya tam banka dekontuna ihtiyacı yoktur. Sipariş numarası, ödeme zamanı, görünen durum ve gerekirse maskelenmiş hata ekranı yeterlidir.

> Hizmet kurulumunu hızlandıran bilgiler

Hizmet adı, alan adı, DNS planı, kaynaklar, yönetici e-postası ve açık SSH anahtarı hazır olsun; sırlar formlara girilmez.
faq/service-setup-information-needed

Doğru bilgiler gecikmeyi azaltır

Sipariş formları hizmet adı, alan adı, DNS hedefi, depolama, CPU, RAM, erişim e-postası veya açık SSH anahtarı gibi müşteri seçimlerini ister. Parolalar, özel anahtarlar ve tokenlar bu alanlara ait değildir.

Siparişten önce hazırlık

  1. Ekibin tanıyacağı bir hizmet adı seç.
  2. Kesin alan adını hazırla veya geçici hostname kullanmaya karar ver.
  3. Ürün istiyorsa açık SSH anahtarı hazırla.
  4. Uygulamana göre kaynakları ve disk boyutunu kontrol et.

Neyin sır olduğundan emin değilsen

Değerin kendisini göndermeden sor. Özel anahtarlar, parolalar, API tokenları, veritabanı dökümleri ve tam yapılandırmalar sipariş ya da destek biletine konmamalıdır.

> Siparişten sonra CPU, RAM, disk veya saklama süresi değiştirme

Mevcut hizmeti kendi detayından değiştir; yeni fiyatı, günlük kredi tüketimini, ödeme durumunu, yeniden başlatma, kesinti ve export ihtiyacını kontrol et.
faq/change-service-resources-after-order

Yeni hizmet değil, mevcut hizmet değişir

Hizmet zaten çalışıyorsa kaynak değişikliğini onun detayından başlat. Yeni sipariş çoğu zaman yeni hizmet oluşturur; mevcut hizmet değişikliği ise onay, gerekiyorsa ödeme ve uygulama sonrasında günlük tüketimi değiştirir.

Onaydan önce kontrol

  1. Mevcut CPU, RAM, disk, backup retention ve Offsite Archive retention değerlerine bak.
  2. Yeni fiyatı ve günlük kredi tüketimine etkisini kontrol et.
  3. Restart, bakım veya kesinti uyarısını oku.
  4. Riskli değişiklikten önce önemli verilerin kendi exportunu al.

Değişiklik beklediğin gibi olmazsa

Hizmet adı, değişiklik zamanı, görünen durum ve hata metnini gönder. Parola, private key, token veya sır içeren yapılandırma paylaşma.

> Hizmet iptali ve veri silme tarihi

Provisioned hizmet önce askıya alınır, yapılandırılabilir görünür silme tarihi gösterir ve lifecycle süresi sonunda kalıcı temizleme gelebilir.
faq/cancel-service-and-data-retention

İptal her zaman anında silme değildir

Zaten provisioned edilmiş bir hizmette iptal önce askıya alma ve yapılandırılabilir görünür silme tarihi gösterir. Hiç çalıştırılmamış ödenmemiş siparişlerde veri yaşam döngüsü farklı olabilir.

İptalden önce

  1. Saklamak istediğin verilerin kendi exportunu al.
  2. Hizmette görünen olası silme tarihini ve saatini oku.
  3. Backup retention ve Offsite Archive retention değerlerini hizmet silme döngüsüyle karıştırma.
  4. Ne silineceğinden emin değilsen tarih gelmeden destekle iletişime geç.

Tarihten sonra kurtarma garanti değildir

Görünür tarih geçtikten sonra verilerin hâlâ erişilebilir olacağı varsayılmamalıdır. Bilette sipariş numarası ve hizmet adını yaz; veritabanı exportu veya gizli erişim bilgisi gönderme.

> Yedekler ve restore talepleri

Yedekler operasyonel kurtarma içindir, kendi exportunun yerine geçmez; restore daha yeni verilerin üstüne yazabilir.
faq/backups-and-restore-requests

Backup her ihtiyaç için arşiv değildir

Retention ürün ve seçilen seçeneklere bağlıdır. Backup operasyonel hatalarda yardımcı olur, ancak iş exportu, uzun vadeli arşiv veya Offsite Archive yerine geçmez; restore daha eski durumu yeni değişikliklerin üzerine yazabilir.

İyi bir restore talebi

  1. Hizmet adını ve sipariş numarasını yaz.
  2. Dönmek istediğin yaklaşık zamanı belirt.
  3. Destekleniyorsa tüm hizmet mi yoksa belirli bölüm mü gerektiğini açıkla.
  4. Parola, token ve private key olmadan görünen hata veya bağlam ekle.

Geri yüklemenin etkisini planla

Kullanıcılar istenen zamandan sonra çalışmaya devam ettiyse daha yeni veriler kaybolabilir. Restore onayından önce ekibi bilgilendir ve üzerine yazılmasını istemediğin verileri sakla.

> Offsite Archive ne içindir

Offsite Archive uzak arşiv kopyalarını kısa operasyonel yedeklerden ve hizmet yaşam döngüsünden ayrı tutar.
faq/offsite-archive-purpose

Günlük çalışmanın dışında arşiv

Offsite Archive uzak kopyalar ve daha uzun veri saklama için kullanılır. Uygulamanın canlı diski değildir, yerel exportun yerine geçmez ve kısa operasyonel backup ile aynı şey değildir.

Ne zaman kullanılır

  1. Hizmetin normal yaşam döngüsü dışında saklamak istediğin veriler için aç.
  2. Retention gün sayısını uyumluluk veya kurtarma hedefine göre seç.
  3. Maliyetin veri miktarı ve saklama süresiyle arttığını hesaba kat.
  4. Büyük veriler için kendi export sürecini de planla.

Fiyat nasıl okunur

Temel ölçü MB-days değeridir: kaç MB saklandığı ve kaç gün tutulduğu. Fiyat EUR/GB/ay olarak gösterilir ve hesaplama tam centlere yuvarlanır.

> VPS için CPU, RAM ve disk seçimi

VPS boyutunu uygulama, veritabanı, cache, loglar ve büyümeye göre seç; OOM, out of memory ve process killed RAM eksikliğine işaret eder.
faq/vps-cpu-ram-and-disk-sizing

Gerçek iş yükünden başla

Statik site, veritabanı, Java uygulaması, arama ya da build süreci farklı kaynak ister. Planlarken uygulama belleği, cache, veritabanı, loglar, upload dosyaları ve büyüme payını dahil et.

Kaynak artırma sinyalleri

  1. OOM, out of memory, process killed veya sürekli swap görürsen RAM artır.
  2. Uzun süren compute, sıkıştırma, build ya da yoğun worker yükünde CPU artır.
  3. Filesystem, loglar veya veritabanı limite yaklaşmadan diski büyüt.
  4. Değişiklikten sonra asıl sorunun kaybolup kaybolmadığını izle.

Sizing sorusu için bağlam

Hizmet adı, uygulama türü, görünen hata, yaklaşık sorun zamanı ve mevcut CPU, RAM, disk değerleri faydalıdır. Parola, private key veya tam iç yapılandırma gönderme.

> VPS için ne zaman genel IP gerekir

Ayrılmış genel IP, izin listesi, içeri gelen erişim, sabit dış kaynak adresi ve adrese bağlı hizmetlerde işe yarar.
faq/vps-public-ip-options

Önce trafiğin yönünü belirle

Genel IP her uygulama için gerekli değildir. Genellikle dış partnerler, sağlayıcılar veya firewall kuralları içeri gelen erişim, dış kaynak adresi ya da iki yön için sabit adres istediğinde gerekir.

IP siparişinden önce sorular

  1. Partnerine izin listesinin içeri gelen, dışarı giden ya da iki yön için mi olduğunu sor.
  2. Mümkün olduğunda sayısal adres yerine DNS adları kullan.
  3. Sadece uygulamanın gerçekten kullandığı portları aç.
  4. Üretim erişimini değiştirmeden önce izin listesi ihtiyacını destekle paylaş.

Genel adres açık sunucu değildir

Ayrılmış IP tüm portların açılması anlamına gelmez. Erişimi gerekli minimum servislere indir ve özel anahtar, parola ya da hassas değer içeren firewall ekran görüntüleri paylaşma.

> VPS için paylaşımlı SSH erişimi

Ayrılmış genel IP yoksa VPS yüksek portlu paylaşımlı SSH erişimi kullanır; genel IP doğrudan SSH sağlar ancak bunun ayrıca ayarlanmış olması gerekir.
faq/shared-ssh-access-for-vps

Yüksek port neden var

Birden fazla VPS aynı genel SSH hostunu paylaşabilir, bu yüzden her hizmete kendi yüksek portu atanır. Bu port bağlantıyı doğru VPS hizmetine yönlendirir; port olmadan paylaşımlı host bağlantıyı hangi makineye ileteceğini bilemez.

Bağlanma biçimi

  1. Paylaşımlı SSH için hizmet sayfasındaki SSH kullanıcı adını, genel hostu ve yüksek portu kopyala.
  2. ssh -p <port> <username>@<public-host> komutunu kullan.
  3. Hizmette ayrılmış genel IP varsa, o IP adresine doğrudan SSH yalnızca SSH servisi ve firewall kuralı buna göre ayarlıysa çalışır.
  4. Özel anahtar yalnızca yerel SSH istemcinde veya agent içinde kullanılmalıdır.

İki olası SSH yolu

Ayrılmış genel IP paylaşımlı erişimi otomatik olarak kaldırmaz ve port 22 açık demek değildir. İzin listesi, monitoring veya entegrasyonlar için doğrudan erişim ekleyebilir. Desteğe yalnızca genel host, port, kullanıcı adı ve görünen hatayı gönder; özel anahtar gönderme.

> Özel alan adı bağlamadan önce kontrol

Alan adı geçişinden önce registrar, authoritative nameservers, exact hostname, apex domain veya subdomain, kayıt tipi ve çakışmaları kontrol et.
faq/custom-domain-readiness-checklist

Kesin hostname belirleyicidir

Önce example.com gibi apex domain mi yoksa app.example.com gibi subdomain mi bağladığını belirle. Buna göre CNAME, A/AAAA, ALIAS veya ANAME kayıtlarının desteklenip desteklenmediği değişir.

DNS değişikliğinden önce

  1. DNS düzenlediğin yerin authoritative nameservers veya registrar olduğunu doğrula.
  2. Aynı hostname için çakışan A/AAAA, CNAME, ALIAS, ANAME veya redirect kayıtlarını kaldır.
  3. Hostname türüne ve DNS sağlayıcısının desteğine uygun kayıt tipini kullan.
  4. Üretim trafiğini çevirmeden önce DNS propagation ve sertifika kontrolünü bekle.

Güvenli geri dönüş

Yeni hostname doğru yanıt verene kadar eski hostingi kapatma. Yardım için alan adını, beklenen hedefi ve herkese açık DNS sonucunu gönder; registrar erişimi veya API tokenı paylaşma.

> Hizmetler için DNS kayıt tipleri

A/AAAA adreslere, CNAME aliasa, MX postaya, TXT doğrulama, SPF, DKIM ve DMARC değerlerine gider; CAA sertifikaları etkileyebilir.
faq/dns-record-types-for-services

Her kaydın görevi farklıdır

A ve AAAA IP adreslerine işaret eder, CNAME izin verilen subdomain için alias oluşturur, MX postayı yönlendirir, TXT doğrulama ve mail politikalarını taşır, CAA ise sertifika otoritelerini sınırlar.

DNS değerlerini kopyalarken

  1. Ad, tip ve değeri hizmetin istediği şekilde birebir kopyala.
  2. DNS kuralları yasaklıyorsa başka kayıtları olan hostname üzerine CNAME koyma.
  3. DKIM değerini sağlayıcı selectorı altında, DMARC kaydını genelde _dmarc altında oluştur.
  4. CAA değerini dikkatli değiştir; yanlış değer sertifika verilmesini engelleyebilir.

DNS sorununu tanılama

Desteğe hostname, kayıt tipi, beklenen değer ve herkese açık görünen sonucu gönder. DNS panel girişi, API tokenı veya sır içeren ekran görüntüsü paylaşma.

> DNS propagation ve TTL için dakika garantisi yoktur

TTL ve resolver cache davranışı, DNS değişikliği sonrası eski ve yeni cevapların ne kadar birlikte görülebileceğini belirler.
faq/dns-propagation-and-ttl

Propagation aslında cache davranışıdır

DNS propagation için kesin dakika sözü yoktur. Authoritative kayıt değiştikten sonra farklı resolverlar TTL süresi dolana kadar eski ve yeni cevapları birlikte döndürebilir.

Planlı DNS değişikliği

  1. Sağlayıcı izin veriyorsa geçişten önce TTL değerini düşür.
  2. Değişikliği bir kez yap ve cache dolarken rastgele tekrar düzenleme.
  3. Sonuçlar farklıysa birden fazla resolver veya ağdan test et.
  4. Değişiklik zamanı, eski değer, yeni değer ve TTL bilgisini not al.

Desteğe ne gönderilir

Hostname, beklenen hedef, görünen eski cevap, görünen yeni cevap, TTL ve değişiklik zamanını gönder. DNS hesabı erişimi veya sağlayıcının dahili notlarını paylaşma.

> Nextcloud storage planlama

Kapasiteye kullanıcı dosyaları, paylaşımlar, sürümler, çöp kutusu, previews, thumbnails, sync overhead ve ekip büyümesini dahil et.
faq/nextcloud-storage-planning

Görünmeyen katmanlar da yer kaplar

Kullanıcı dosyalarının yanında paylaşımlar, silinen dosyalar, sürüm geçmişi, previews, thumbnails, sync istemcileri ve içe aktarmalar kapasite kullanır. Limite yaklaşmak upload ve sync hatalarına yol açabilir.

Kapasite siparişinden önce

  1. Mevcut kullanıcı dosyalarını ve ortak klasörleri ölç.
  2. Sürümler, çöp kutusu, previews ve thumbnails için pay ekle.
  3. Büyük içe aktarmaları, yeni ekipleri ve beklenen büyümeyi hesaba kat.
  4. Kullanıcılar limite takılmadan storage artır.

Sync hata vermeye başlarsa

Hizmet boyutunu, yaklaşık doluluğu, sorun zamanını ve istemcide görünen hatayı gönder. Özel dosya, parola veya kullanıcı verisi exportu ancak güvenli kanal kararlaştırılırsa paylaşılmalıdır.

> Repositoryleri Gitea üzerine taşıma

Git repository migration planını LFS, submodules, yetkiler, protected branches, deploy keys, webhooks ve CI/CD ile birlikte yap.
faq/gitea-repository-migration

Migration sadece git clone değildir

Kod geçmişinin yanında sahipler, ekipler, protected branches, protected tags, Git LFS, submodules, deploy keys, tokenlar, webhooks ve CI/CD akışları kontrol edilmelidir. Token değerleri paylaşılmamalıdır.

Cutover öncesi kontrol

  1. Repositoryleri, sahipleri, erişim gruplarını ve automation hesaplarını listele.
  2. Git LFS objelerini, submodules, protected branches ve protected tags durumunu kontrol et.
  3. Taşıma sonrası clone, push, Git LFS, submodules ve CI testleri yap.
  4. Eski tokenları migration sonrası değerlerini paylaşmadan iptal et veya döndür.

Yardım için güvenli bilgiler

Bilete token, private key, deploy key özel kısmı veya CI secrets koyma. Repository adları, entegrasyon türü, görünen hata ve daha önce çalışan davranış yeterlidir.

> Listmonk için sender domain

Kampanyalar için sender domain veya subdomain, From kimliği, SPF, DKIM, DMARC, bounce ve unsubscribe hazırlığı yap.
faq/listmonk-sender-domain-basics

Teslim edilebilirlik alan adıyla başlar

Listmonk kampanyaları, sender domain doğru DNS kayıtlarına ve net From kimliğine sahip olduğunda daha iyi sonuç verir. SPF, DKIM ve DMARC gönderim yaptığın domain veya subdomain ile hizalı olmalıdır.

İlk kampanyadan önce

  1. Sender domain veya subdomain ve From adını seç.
  2. Doğrulama DNS kayıtlarını, SPF, DKIM selector ve _dmarc altında DMARC kaydını ekle.
  3. Gerçek kampanyadan önce test mesajlarını, bounce veya Return-Path ve linkleri kontrol et.
  4. Büyük listeye göndermeden önce unsubscribe ve List-Unsubscribe ayrıntılarını doğrula.

Mail sırları bilete girmez

Tanılama için domain, kayıt tipi, herkese açık DNS değeri ve hatayı gönder. SMTP parolası, API tokenı, private DKIM key veya alıcı listesi exportu paylaşma.

> Classic Hosting Runtime ayarları

Classic Hosting auto veya manual Runtime kullanabilir; CPU, RAM, storage, backup, Offsite Archive, uploads, cache ve logs fiyatı ve kararlılığı etkiler.
faq/classic-hosting-runtime-settings

Auto mod tek doğru seçenek değildir

Auto Runtime tanınan projelerde yardımcı olur, ancak Nginx, Apache, FrankenPHP veya belirli bir dil runtimeı seçmek istediğinde manual mod daha uygundur. PHP selector yalnızca seçilen runtime destekliyorsa kullanılmalıdır.

Deploy öncesi ayarlar

  1. Framework ve build sürecine göre auto veya manual Runtime seç.
  2. PHP 8.2, 8.3 veya 8.4 değerini yalnızca desteklenen PHP senaryolarında seç.
  3. Veri ve trafiğe göre CPU, RAM, disk, backup retention ve Offsite Archive ayarla.
  4. Deploy sonrası uploads, cache, logs ve görünen uygulama hatalarını test et.

Uygulama başlamazsa

Runtime modu, dil veya PHP sürümü, görünen hata, neyin değiştiği ve deploy zamanını gönder. .env dosyası, parola, token veya hassas değer içeren tam log paylaşma.

> Destekle güvenle paylaşılabilecek bilgiler

Sipariş numaraları, hizmet adları, alan adları, zamanlar, genel hostlar, portlar, yedek saklama süresi, Offsite Archive, yüklemeler, cache, loglar ve görünen hatalar sır içermeden en çok yardımcı olur.
faq/support-safe-information-to-share

İyi bilet bağlam içerir, sır içermez

Destek, sipariş numarası, hizmet adı, alan adı, genel host veya port, sorun zamanı, neyin değiştiği ve tam görünen hata metni geldiğinde daha hızlı yanıt verir.

Güvenli mesaj içeriği

  1. Sipariş, hizmet, alan adı, zaman ve sorunun oluştuğu adımı yaz.
  2. Hosting için runtime, PHP veya dil, CPU, RAM, disk, yedek saklama süresi, Offsite Archive saklama süresi, yüklemeler, cache ve log bilgilerini sır olmadan ekle.
  3. Ekran görüntülerini göndermeden önce kişisel veya gizli alanları maskele.
  4. Bir bilginin bilete girip girmeyeceğinden emin değilsen değeri göndermeden sor.

Asla gönderilmemesi gerekenler

Parolalar, özel anahtarlar, recovery seedler, API tokenları, session cookies, veritabanı exportları, tam .env dosyaları, sır içeren tam loglar veya gizli teknik ayrıntılar paylaşılmamalıdır.