.NET Web Hosting ve Profesyonel Web Hosting Rehberi 2026

.NET ekosistemi son yıllarda sessiz bir devrim yaşadı: ASP.NET Core 8/9 ile Linux üzerinde çalışabilen, tek dosya halinde deploy edilebilen, Node.js'le yarışan TTFB rakamları sunan bir web platformuna dönüştü. Buna rağmen Türkiye'de pek çok kullanıcı hâlâ ".NET = pahalı Windows hosting" denkleminde takılı. Bu rehber hem klasik Windows + IIS + MSSQL stack'ini hem de modern Linux + Kestrel + Nginx dağıtımını derinlemesine anlatıyor; profesyonel bir web hosting kararını fiyatla değil, mimariyle vermenizi sağlıyor.

Profesyonel web hosting kavramı da yıllar içinde değişti. Eskiden "sınırsız disk" pazarlaması ön plandaydı; bugün ölçü NVMe IOPS, CPU steal time, RAM ayrımı, HTTP/3 desteği, otomatik backup retention, uptime SLA ve destek ekibinin teknik derinliği. Bu yazıda her iki konuyu —.NET'e özel hosting ve genel anlamda profesyonel hosting kriterleri — paralel ele alıp ASCII çizimler, gerçek komutlar ve karşılaştırma tabloları ile pekiştireceğiz.

İlgili rehberler: Hosting nedir ve türleri · VPS ile VDS farkı · Plesk panel yönetimi · Nginx yapılandırma · Let's Encrypt SSL kurulumu · cPanel rehberi

.NET Web Hosting Nedir, Klasik Hosting'den Farkı Ne?

.NET web hosting, Microsoft'un.NET çatısı üzerinde geliştirilmiş web uygulamalarının (ASP.NET Web Forms, ASP.NET MVC, ASP.NET Core, Blazor Server, SignalR servisleri, Web API'leri) çalıştırılabildiği barındırma türüdür. Klasik PHP-MySQL hosting'ten ayrıldığı üç temel nokta vardır: çalışma zamanı (.NET Framework veya.NET 8/9), web sunucusu (IIS veya Kestrel arkasında reverse proxy) ve veritabanı (genelde MSSQL, ama PostgreSQL/MySQL de yaygın).

Tarihsel olarak.NET = Windows Server denklemi geçerliydi. Ancak Microsoft 2016'da.NET Core'u açık kaynak Linux çalıştırılabilir hale getirdi; 2020'de.NET 5 ile "Core" ismini bile bıraktılar. Bugün ASP.NET Core uygulamalarının çoğu Linux container üzerinde, Nginx veya Caddy reverse proxy arkasında çalışıyor. Bu, hosting maliyetini neredeyse yarı yarıya düşürdü çünkü Windows Server lisansının aylık 25-40 USD üzerinde olan ek yükü ortadan kalktı.

Pratik sonuç şu: ".NET hosting" terimi 2026'da iki tamamen farklı senaryoyu kapsıyor olabilir. Birincisi, eski ASP.NET WebForms ve klasik ASP projelerinin barındırıldığı Windows + IIS + MSSQL stack'i; ikincisi, modern ASP.NET Core 8/9 mikroservislerinin Linux container üzerinde Kestrel + Nginx ile yayıldığı stack. Sağlayıcıdan paket alırken hangi senaryoda olduğunuzu netleştirin — ikisi farklı destek deneyimi, farklı fiyat ve farklı performans karakteristiği sunar. Birinci senaryoda Plesk Obsidian + ASP.NET 4.8 hot-fix güncellemeleri, ikinci senaryoda ise Docker registry + GitHub Actions deploy yetkinliği daha kritiktir.

Hangi Sürümler Hâlâ Destekleniyor?

• .NET 8 (LTS) — 2026 Kasım'a kadar destekli, mevcut production projeleri için varsayılan tercih.
• .NET 9 (STS) — Mayıs 2026'ya kadar standart support; yeni feature deneyleri için.
• .NET 10 (LTS, 2025 Kasım) — uzun vadeli üretim için önerilen sürüm; üç yıl destekli.
• .NET Framework 4.8 / 4.8.1 — eski Web Forms ve WCF projeleri için Windows'a bağımlı; yeni proje açmayın.
• .NET Core 3.1 ve eski — desteği bitti, security update almıyor; göç planlayın.

Microsoft'un resmi .NET destek politikasını her yıl yenileyin; eski sürümde takılı bir "professional" hosting paketi aslında profesyonel değil, riskli.

Windows Hosting mi, Linux Hosting mi?

En çok sorulan soru bu. Cevap: uygulamanızın ihtiyaçlarına bağlı. Aşağıdaki tablo karar matrisinin temel halidir.

• ASP.NET Web Forms (.aspx) veya WCF kullanıyorsanız → Windows hosting + IIS şart.
• Klasik ASP / VBScript mirası kod varsa → Windows hosting zorunlu.
• MSSQL Server'a remote bağlanmıyor, aynı sunucuda istiyorsanız → Windows + Plesk genellikle daha kolay.
• ASP.NET Core 8/9 + PostgreSQL/MySQL → Linux hosting %30-50 daha ucuz, eşit performans.
• Container tabanlı CI/CD, Docker, Kubernetes → Linux ekosistemi olgun, Windows container'ları ağır.
• SignalR / WebSocket yoğun → Linux + Kestrel daha düşük overhead.
• Office Interop, COM bileşenleri kullanan kod → Windows kaçınılmaz.

IIS vs Kestrel + Reverse Proxy

IIS otuz yıllık olgun bir web sunucusudur; Windows Server üzerinde çalışır, ASP.NET Core uygulamalarını ANCM (ASP.NET Core Module) aracılığıyla in-process veya out-of-process modda host eder. In-process mod istek başına ek bir HTTP hop'u olmadığı için performans olarak Kestrel'den hızlıdır; out-of-process ise IIS'i sadece reverse proxy olarak kullanır.

Linux tarafında ise Kestrel doğrudan public internete bakmaz — önüne Nginx veya Caddy konumlandırılır. Bu yapı dünya çapında en çok kullanılan modern.NET deploy modelidir; Microsoft Learn da bu yöntemi resmi olarak önerir. Reverse proxy tuning konusunda Nginx yapılandırma rehberimiz başvuru kaynağıdır.

+--------------+ +----------+ +------------+
| Internet | -----> | Nginx | -----> | Kestrel |
| HTTPS | | :443 | | :5000 |
| HTTP/3 | <----- | TLS | <----- | ASP.NET |
+--------------+ +----------+ +------------+
 |
 v
 +----------------+
 | PostgreSQL |
 | / Redis / S3 |
 +----------------+

Profesyonel Web Hosting Kriterleri: 12 Madde Checklist

"Profesyonel" ekiyle pazarlanan paketler çoğunlukla normal paylaşımlı hostingden farkı olmayan, sadece daha yüksek bant genişliği vaat eden ürünlerdir. Gerçekten profesyonel bir hosting şu özellikleri sağlamalıdır:

• 1. NVMe SSD storage — SATA SSD'ye göre 5-7x IOPS, 10ms altı disk latency.
• 2. Garantili (burst değil) CPU/RAM — paylaşımlı paketlerde "3 core" yazıp aslında 50ms steal time veren sunucular var; istek-cevap diyagramı isteyin.
• 3. CPanel/Plesk gibi sağlam panel — açık kaynak DirectAdmin de iyi, ama profesyonel destek ekosistemi cPanel/Plesk'te.
• 4. Otomatik günlük yedek + 14-30 gün retention — sadece günlük yetmez, 1 hafta önceki bir snapshot'ı geri çağırabilmelisiniz.
• 5. Sınırsız sınırlı değil — "sınırsız trafik" pazarlaması fair use politikalarıyla sınırlandırılır; somut TB/ay değer isteyin.
• 6. HTTP/2 + HTTP/3 + Brotli — modern protokoller hâlâ default değil; yapılandırmayı kontrol edin.
• 7. Ücretsiz Let's Encrypt + auto-renewal — tek tıkla SSL ve 60 günde bir otomatik yenileme.
• 8. WAF + temel DDoS koruma — Cloudflare ücretsiz katmanı asgari, sağlayıcı tarafında volumetric DDoS scrubbing ideal.
• 9. SLA: %99.9 minimum, %99.95+ ideal — sözleşmede yazılı tazminat şartı olmalı.
• 10. 7/24 teknik destek (Tier-2) — bot mesajına "ticket aç" diyen değil, sysadmin seviyesinde yanıt veren ekip.
• 11. Datacenter sertifikaları — TIER III en az; TIA-942 ve ISO 27001 sertifikaları sorgulanmalı.
• 12. Kolay göç / iade hakkı — para iade garantisi (15-30 gün) ve ücretsiz site taşıma.

Hosting türleri rehberimizdeki tablodaki paylaşımlı/VPS/dedicated/bulut karşılaştırması, profesyonel paket seçerken hangi katmana ihtiyacınız olduğunu netleştirir.

Türkiye Pazarındaki Profesyonel.NET Hosting Sağlayıcıları

Sağlayıcıların adlarını vendor-neutral bir karşılaştırma için listeliyoruz; herhangi birini önermiyoruz. Türkiye merkezli yerel sağlayıcılar arasında Natro, Hosting.com.tr, Doruk.Net, Turhost, Güzel.Net.Tr ve İhs Telekom.NET odaklı paketler sunar. Global tarafta GoDaddy, Hostinger, IONOS, AccuWeb gibi şirketler ASP.NET'e özel Windows planları yayınlar.

2026 yaklaşık fiyat aralıkları (sağlayıcıya göre değişir, 2026 verisi): giriş seviyesi Windows hosting 50-90 TL/ay, profesyonel/business tier 150-350 TL/ay, MSSQL Database Server dahil tier 250-500 TL/ay. VPS kademelerine geçildiğinde 4 vCPU + 8GB RAM Windows VPS 700-1300 TL/ay bandında oturuyor. Yıllık ödeme tercihi yapılırsa indirimle bu rakamlar %20-40 düşebilir; promosyon dönemlerindeki ilk yıl ücretleri yenileme döneminde 2-3x'e fırlayabilir, sözleşmeyi yenileme fiyatı üzerinden değerlendirin.

Global pazardan örnekler de denkleminiz olsun: ABD'de profesyonel paylaşımlı hosting tier'ı 8-15 USD/ay (paylaşımlı pro) ile 25-40 USD/ay (managed VPS) arasında dolaşıyor. Türkiye'deki yerel sağlayıcılar TL/USD kuruyla bu rakamlardan yüksek görünebilir; ancak yerel datacenter (İstanbul, Ankara) latency avantajı, KVKK uyumu ve Türkçe destek bunu büyük oranda dengeleyebilir. Avrupa kullanıcılarınız varsa Almanya/Hollanda lokasyonu, ABD pazarına yöneliyorsanız Amerika tarafı tercih edilmelidir.

Hangi Sınıfta Ne Kadar Kaynak Almalı?

• Statik / küçük ASP.NET MVC sitesi (10K ay/visit): 1 vCPU, 1-2 GB RAM, 10 GB NVMe yeter. Paylaşımlı pro tier.
• Orta ölçek e-ticaret veya kurumsal SaaS (50-200K ay/visit): 2-4 vCPU, 4-8 GB RAM, 40-100 GB NVMe. VPS sınıfı.
• Yüksek trafik portal veya çoklu mikroservis (1M+ ay/visit): dedicated veya bulut sunucu kümesi, 8+ vCPU, 16+ GB RAM, ayrı veritabanı host'u, Redis cache.
• Reporting/BI ağırlıklı MSSQL kullanımı: SQL Server için ayrılmış 16+ GB RAM, NVMe RAID-10, dedicated CPU.

Plesk vs cPanel vs Direkt Linux Sunucu

Plesk,.NET hosting için en çok kullanılan kontrol panelidir çünkü Windows üzerinde ASP.NET, MSSQL, IIS modüllerini tek arayüzden yönetmenizi sağlar. cPanel ise Linux ekosisteminin standardı olup.NET Core uygulamalarını Phusion Passenger benzeri eklentilerle host edebilir, ancak ana hedefi PHP/MySQL tarafıdır.

Plesk yönetim rehberimiz.NET deploy adımlarını ve cPanel rehberimiz Linux paylaşımlı senaryosunu detaylı anlatır. Yönetilen panele alternatif olarak doğrudan SSH ile Linux sunucu yönetmek isteyenler Linux temelleri yazımıza bakmalı.

Plesk Panelinde ASP.NET Core Deploy

# 1) Plesk > Domains > example.com.tr > Hosting Settings
# Document Root: C:\inetpub\vhosts\example.com.tr\httpdocs
# ASP.NET sürümü: ASP.NET Core 8.x (Hosting Bundle yüklü olmalı)

# 2) Yerel makinede self-contained build
dotnet publish -c Release -r win-x64 --self-contained true `
 -p:PublishSingleFile=true `
 -p:IncludeNativeLibrariesForSelfExtract=true `
 -o.\publish

# 3) Plesk File Manager veya FTP ile httpdocs altına yükle
# 4) web.config içinde aspNetCore handler:
# <aspNetCore processPath=".\MyApp.exe" stdoutLogEnabled="true"
# stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />

# 5) Plesk > Application Pool >.NET CLR Version: "No Managed Code"
# (ASP.NET Core ANCM kendi runtime'ını kullanır)

# 6) MSSQL connection string Plesk > Databases üzerinden alınır
# Server=localhost,1433;Database=appdb;User Id=appuser;Password=...;TrustServerCertificate=true

Linux + systemd ile Kestrel Servisi

# /etc/systemd/system/kestrel-app.service
[Unit]
Description=ASP.NET Core App
After=network.target

[Service]
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/dotnet /var/www/myapp/MyApp.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=kestrel-app
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=ASPNETCORE_URLS=http://127.0.0.1:5000
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

# Aktivasyon
sudo systemctl daemon-reload
sudo systemctl enable kestrel-app
sudo systemctl start kestrel-app
sudo systemctl status kestrel-app

# Log takibi
sudo journalctl -u kestrel-app -f --since "5 minutes ago"

Nginx Reverse Proxy ile Kestrel'i HTTPS'e Açmak

Kestrel TLS terminasyonunu kendi başına yapabilir ama production'da güvenli ve ölçeklenebilir tercih: TLS'i Nginx'te sonlandırmak, Kestrel'e plain HTTP ile iletmek. Bu mimari hem Let's Encrypt yenilemesini kolaylaştırır hem de WAF/rate limit kuralları için tek nokta sunar.

# /etc/nginx/sites-available/myapp.conf
upstream kestrel_app {
 server 127.0.0.1:5000;
 keepalive 32;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 listen 443 quic reuseport;
 listen [::]:443 quic;
 server_name app.example.com.tr;

 ssl_certificate /etc/letsencrypt/live/app.example.com.tr/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/app.example.com.tr/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_session_cache shared:SSL:20m;
 ssl_session_timeout 1d;

 add_header Alt-Svc 'h3=":443"; ma=86400';
 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

 client_max_body_size 50m;

 location / {
 proxy_pass http://kestrel_app;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 300s;
 }

 # SignalR / WebSocket route
 location /hubs/ {
 proxy_pass http://kestrel_app;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_read_timeout 7200s;
 }
}

# HTTP -> HTTPS
server {
 listen 80;
 server_name app.example.com.tr;
 return 301 https://$server_name$request_uri;
}

ASP.NET Core uygulamasının doğru remote IP ve şema bilgisi alabilmesi için Startup/Program.cs içinde UseForwardedHeaders middleware'i etkinleştirin; aksi halde HttpContext.Connection.RemoteIpAddress her zaman 127.0.0.1 döner.

// Program.cs (.NET 8/9 minimal hosting)
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
 options.ForwardedHeaders =
 ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
 options.KnownProxies.Add(IPAddress.Parse("127.0.0.1"));
});

var app = builder.Build();
app.UseForwardedHeaders();

MSSQL Hosting: Paylaşımlı vs Yönetilen vs Self-Hosted

MSSQL Server lisansı pahalıdır (Standard Edition CAL başına ~200 USD, Core lisansı ~7000 USD/2 core). Bu nedenle paylaşımlı.NET hosting paketlerinde tipik olarak tek bir DB instance, paket başına 50-500 MB kotalı veritabanları verilir. Profesyonel ihtiyaçlar için üç seçenek var:

• Paylaşımlı MSSQL: Hosting paketinde dahil; düşük maliyetli ama bound on shared CPU. Sadece <500 MB veritabanı ve düşük QPS için.
• Yönetilen MSSQL (Azure SQL DB, AWS RDS): Aylık 30-300 USD; otomatik patch, backup, geo-replication. En kolay yol.
• Self-hosted MSSQL Developer/Express: Express edition 10 GB veritabanı sınırıyla ücretsiz; küçük SaaS'ler için yeterli. VPS üzerinde host edilir.
• Alternatif: PostgreSQL / MariaDB: ASP.NET Core EF Core üzerinden sorunsuz çalışır, lisans maliyeti yok. MySQL vs PostgreSQL karşılaştırmamız seçim için yardımcı olur.

MSSQL backup stratejisinde 3-2-1 kuralını ihmal etmeyin. Veritabanı yedekleme stratejileri yazımız Full + Differential + Transaction Log üçlüsü ile RPO/RTO hesaplamasını detaylı işliyor.

-- MSSQL: günlük full + 6 saatte bir log backup
-- T-SQL Agent job örneği (msdb.dbo.sp_add_job)

USE [appdb];

-- Full backup (her gece 02:00)
BACKUP DATABASE [appdb]
TO DISK = N'D:\Backup\appdb_full_20260506.bak'
WITH COMPRESSION, CHECKSUM, INIT, STATS = 10;

-- Transaction log backup (6 saatte bir)
BACKUP LOG [appdb]
TO DISK = N'D:\Backup\appdb_log_20260506_0800.trn'
WITH COMPRESSION, CHECKSUM;

-- Recovery model kontrolü (Full olmalı, Simple ise log backup çalışmaz)
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'appdb';

NVMe, RAM ve CPU: Gerçekten Ne Kadar Önemli?

Pazarlama materyalleri "NVMe SSD" ibaresine vurgu yapar; ama gerçek soru: kaç IOPS, kaç MB/s sequential read, kaç ms latency garantili? NVMe disk SATA SSD'ye göre tipik değerlerle 5-7 kat IOPS, 4 kat throughput sunar. Kabaca:

• SATA SSD: ~80K-100K IOPS random read, ~550 MB/s sequential.
• NVMe Gen3: ~400K-500K IOPS, ~3500 MB/s sequential.
• NVMe Gen4: ~700K-1M IOPS, ~7000 MB/s sequential.
• NVMe Gen5: 1.5M+ IOPS, 14000 MB/s — DC SSD'lerde yaygınlaşıyor.

Ancak paylaşımlı hosting'de 100 müşterinin paylaştığı tek bir NVMe Gen4 disk, müşteri başına Gen3 SATA değerlerinin altına düşebilir. Gerçek performansı test etmek için fio kullanın:

# Linux VPS üzerinde 4K random read IOPS testi (1 dakika)
fio --name=randread --ioengine=libaio --rw=randread \
 --bs=4k --direct=1 --size=2G --numjobs=4 \
 --runtime=60 --group_reporting --time_based

# 1M sequential read throughput
fio --name=seqread --ioengine=libaio --rw=read \
 --bs=1M --direct=1 --size=4G --runtime=30 --time_based

# Write latency (production öncesi yapın, veri yazar!)
fio --name=randwrite --ioengine=libaio --rw=randwrite \
 --bs=4k --direct=1 --size=1G --numjobs=2 \
 --runtime=30 --group_reporting --time_based --fsync=1

CPU steal time KVM/Xen sanallaştırma altında hypervisor'ın sizden çaldığı CPU yüzdesidir; top komutunda %st kolonunda görünür. %5 üstü ciddi bir yoğun komşu sorunu, %15 üstü hosting kalitesinin kötü olduğunun göstergesidir. Sustained yük altında %30+ steal time görüyorsanız sağlayıcıdan yeni bir host'a taşınma talep edin; reddedilirse iade hakkınızı kullanın.

RAM tarafında "3 GB RAM dahil" demek her zaman "3 GB ayrılmış RAM" anlamına gelmez. Bazı paylaşımlı paketler burst RAM verir: müsaitse 3 GB'a kadar çıkarsınız ama paylaşılan host yoğunken aniden 512 MB'a düşersiniz. Bu durum ASP.NET Core uygulamasında GC pause'larını ve out-of-memory kaynaklı 502 hatalarını tetikler. Sağlayıcıdan "guaranteed RAM" mi yoksa "burstable" mı sorduğunuzda yazılı cevap isteyin.

# 1 saniye aralıkla CPU steal time izle
vmstat 1 30

# Detaylı per-core CPU breakdown
mpstat -P ALL 2 10

# Sustained CPU benchmark (sysbench)
sysbench cpu --threads=4 --cpu-max-prime=20000 run

HTTP/2, HTTP/3 ve TLS Optimizasyonu

Profesyonel bir hosting 2026'da hâlâ HTTP/1.1 servis ediyorsa profesyonel değildir. HTTP/2 tek TCP bağlantısında multiplexing yapar, header compression sunar. HTTP/3 (QUIC üzerinde) UDP tabanlıdır, head-of-line blocking sorununu çözer ve özellikle mobil bağlantılarda %10-30 hızlanma sağlar.

TLS 1.3, handshake'i 1-RTT'e indirir; 0-RTT resumption ile tekrar gelen istemcide neredeyse handshake yokmuş gibi davranır. HTTPS ve TLS 1.3 rehberimiz şifreleme algoritma seçimi, OCSP stapling ve HSTS preload sürecini detaylı anlatır.

Kestrel HTTP/3'ü.NET 8 itibariyle GA olarak destekler; ancak Kestrel'i public'e açmak yerine Nginx 1.25+ veya Caddy 2 ile QUIC sonlandırması yapmak çok daha pratiktir. Yapılandırmanızı SSL Labs SSL Test ile A+ skoruna getirin.

Hosting Performans Karşılaştırması: Gerçek Ölçüm Yöntemi

Sağlayıcı pazarlamasına güvenmek yerine 14 günlük para iade penceresi içinde gerçek benchmark yapın. ASP.NET Core uygulaması için tipik test seti şu şekilde çalışır. Test sırasında en kritik nokta: yük üretici makineyi sağlayıcının kendi datacenter'ında konumlandırmamak. Aynı bölgedeki bir ölçüm gerçek son kullanıcı deneyimini yansıtmaz; bunun yerine farklı continent'lerden (us-east, eu-west, asia) eş zamanlı testlerle p95 ve TTFB değerlerini gözlemleyin. WebPageTest ücretsiz katmanı 13 farklı şehirden tek tıklama testi sağlar; profesyonel paket seçim sürecinde mutlaka faydalanın.

# 1) k6 ile yük testi (10 kullanıcı, 30 saniye)
cat > load.js <<'EOF'
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
 vus: 10,
 duration: '30s',
 thresholds: {
 http_req_duration: ['p(95)<400'],
 http_req_failed: ['rate<0.01']
 }
};
export default function () {
 const res = http.get('https://app.example.com.tr/');
 check(res, { 'status 200': r => r.status === 200 });
 sleep(1);
}
EOF
k6 run load.js

# 2) wrk ile saf throughput
wrk -t8 -c200 -d60s --latency https://app.example.com.tr/

# 3) curl ile TTFB ölçümü (10 kez)
for i in $(seq 1 10); do
 curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s Total: %{time_total}s\n' \
 https://app.example.com.tr/
done

Sonuçları değerlendirirken ortalamadan ziyade p95 ve p99 latency rakamlarına bakın. Ortalama yanıltıcıdır; profesyonel bir paketin p99 değeri ortalama LCP hedefinizin (2.5 saniye) altında kalmalıdır.

Konteynerleştirme: Docker ile.NET Hosting

Yeni nesil.NET deploy modeli Docker imajı + container orkestrasyonudur. Docker ile uygulama deploy ve Docker Compose rehberimiz.NET dahil tüm runtime'lar için uygulanabilir.

# Multi-stage Dockerfile - ASP.NET Core 8
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp.csproj", "./"]
RUN dotnet restore
COPY..
RUN dotnet publish -c Release -o /app /p:UseAppHost=false

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app.

# Non-root user (security best practice)
RUN adduser --disabled-password --gecos '' appuser && \
 chown -R appuser:appuser /app
USER appuser

ENV ASPNETCORE_URLS=http://+:8080
ENV DOTNET_RUNNING_IN_CONTAINER=true
ENV DOTNET_USE_POLLING_FILE_WATCHER=false
EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
 CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1

ENTRYPOINT ["dotnet", "MyApp.dll"]

mcr.microsoft.com/dotnet/aspnet:8.0-alpine imajı ~80 MB civarındadır; full Debian-based imaj ~210 MB. Alpine üretim için idealdir ancak bazı native kütüphaneler (ImageMagick, libgdiplus) sorun çıkarabilir; test edin.

# docker-compose.yml — ASP.NET Core + PostgreSQL + Redis + Nginx
version: '3.9'
services:
 app:
 build:.
 image: myapp:latest
 restart: unless-stopped
 environment:
 - ASPNETCORE_ENVIRONMENT=Production
 - ConnectionStrings__Default=Host=db;Database=appdb;Username=app;Password=${DB_PASSWORD}
 - Redis__Configuration=redis:6379
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 networks: [appnet]

 db:
 image: postgres:16-alpine
 restart: unless-stopped
 environment:
 - POSTGRES_DB=appdb
 - POSTGRES_USER=app
 - POSTGRES_PASSWORD=${DB_PASSWORD}
 volumes:
 - dbdata:/var/lib/postgresql/data
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U app"]
 interval: 10s
 retries: 5
 networks: [appnet]

 redis:
 image: redis:7-alpine
 restart: unless-stopped
 networks: [appnet]

 nginx:
 image: nginx:1.25-alpine
 restart: unless-stopped
 ports: ["80:80", "443:443"]
 volumes:
 -./nginx.conf:/etc/nginx/nginx.conf:ro
 -./certs:/etc/letsencrypt:ro
 depends_on: [app]
 networks: [appnet]

volumes: { dbdata: {} }
networks: { appnet: {} }

CI/CD: GitHub Actions ile Otomatik Deploy

Profesyonel bir hosting'i FTP ile yönetmiyorsanız, deploy otomasyonu kurun. GitHub Actions CI/CD rehberimiz kapsamlı örnekler içerir; aşağıda ASP.NET Core için özet workflow:

#.github/workflows/deploy.yml
name: Build & Deploy ASP.NET Core
on:
 push:
 branches: [main]

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '8.0.x'

 - name: Restore & Test
 run: |
 dotnet restore
 dotnet test --no-restore --verbosity minimal

 - name: Publish
 run: dotnet publish -c Release -o./publish --no-restore

 - name: Build Docker image
 run: |
 docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }}.
 echo ${{ secrets.GHCR_TOKEN }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
 docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

 - name: Deploy via SSH
 uses: appleboy/ssh-action@v1
 with:
 host: ${{ secrets.PROD_HOST }}
 username: deploy
 key: ${{ secrets.SSH_KEY }}
 script: |
 cd /srv/myapp
 docker compose pull app
 docker compose up -d app
 docker image prune -f

Backup, Disaster Recovery ve Yedekleme Stratejisi

"Günlük yedek" pazarlaması yetmez. Profesyonel kurumsal hosting'de yedeklemenin üç boyutunu sorun: frekans, retention ve restore süresi. RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedeflerinizi sağlayıcının SLA'iyle eşleştirin.

• Tier-1 kritik (e-ticaret): RPO ≤ 1 saat, RTO ≤ 4 saat. 6 saatte bir DB log backup, geo-replication.
• Tier-2 önemli (kurumsal CMS): RPO ≤ 24 saat, RTO ≤ 24 saat. Günlük full + transaction log.
• Tier-3 düşük (statik site): RPO ≤ 7 gün, RTO ≤ 72 saat. Haftalık full backup + git repo.

Yedek dosyalarını aynı sağlayıcıda tutmayın. Sağlayıcı çökerse veya hesabınız askıya alınırsa kapısı kapalı bir kasaya bakarsınız. AWS S3 / Backblaze B2 / Hetzner Storage Box gibi üçüncü taraf object storage'a kopya gönderin. Veritabanı yedekleme stratejileri yazımız 3-2-1 kuralını detaylandırıyor.

Güvenlik: Profesyonel Hosting Hijyen Listesi

İyi bir hosting paketi güvenliğin %50'sini sunar; geri kalan %50 sizin sorumluluğunuzdur. Aşağıdaki kontrol listesini her yeni proje için uygulayın:

• SSH'a parola değil key ile bağlanın: PasswordAuthentication no; Fail2ban kurun.
• Tüm trafik HTTPS: HSTS preload aktif (max-age=63072000; includeSubDomains; preload).
• Web uygulama firewall: ModSecurity OWASP CRS veya Cloudflare WAF.
• Rate limiting: API rate limiting ile login/API endpoint'leri koruyun.
• OWASP Top 10 audit: 2026 listesini proje başında geçin.
• SQL injection ve XSS: parameterized query (rehberimiz) ve CSP başlıkları.
• Düzenli patch: dotnet, aspnet runtime, IIS hotfix, Linux kernel; en az ayda bir.
• Secret management: connection string'i kodda tutmayın; Azure Key Vault, AWS Secrets Manager, dotenv + ignore.
• Log + alerting: ELK Stack veya Prometheus+Grafana ile şüpheli aktivite alarmı.
• VPS güvenlik sertleştirme: VPS sertleştirme rehberimizi takip edin.

Domain ve SSL Yönetimi

Profesyonel hosting kararından önce ya da paralel olarak domain stratejinizi netleştirin. Domain nedir yazımızda alan adı tescili, WHOIS, DNS kayıt türleri detaylı işleniyor; DNS rehberimiz A/AAAA/CNAME/MX/TXT kayıtlarını anlatır.

SSL tarafında 2026'da hâlâ ücretli sertifika alıyorsanız muhtemelen yanlış sağlayıcı seçtiniz. Let's Encrypt 90 günlük ücretsiz domain validated sertifikası sunar; SSL nasıl alınır yazımızda EV/OV ne zaman gerekli detaylanır. ZeroSSL, Cloudflare Origin CA da alternatif.

Certbot ile Otomatik SSL Yenileme

# Ubuntu 22.04 / 24.04
sudo apt install certbot python3-certbot-nginx

# Yeni sertifika (Nginx auto-config)
sudo certbot --nginx -d app.example.com.tr -d www.example.com.tr \
 --agree-tos --email admin@example.com.tr --no-eff-email

# Wildcard sertifika (DNS challenge)
sudo certbot certonly --manual --preferred-challenges=dns \
 -d '*.example.com.tr' -d example.com.tr

# Otomatik yenileme test (cron varsayılan kurulu)
sudo certbot renew --dry-run

# Yenileme sonrası Nginx reload (deploy hook)
sudo certbot renew --deploy-hook 'systemctl reload nginx'

E-posta Hosting: Web Hosting'den Ayırmak

Profesyonel kurumsal kurulumlarda e-postayı web sunucunuzdan ayırmanızı şiddetle öneriyoruz. Sebep: e-posta sunucusu kara listeye düşerse (spam botnet enfekte olmuş tek müşteri yüzünden) tüm IP bloğunuz Gmail/Outlook tarafından engellenebilir. Microsoft 365, Google Workspace, Zoho Mail veya kurumsal Plesk Mail çözümleri ayrı tutulmalıdır.

SPF + DKIM + DMARC üçlüsünü kurmadan e-posta göndermeyin. DNS kayıtları için tipik örnek:

; SPF — gönderim için yetkili sunucular
example.com.tr. IN TXT "v=spf1 include:_spf.google.com ip4:198.51.100.10 -all"

; DKIM — Google Workspace seçer
google._domainkey.example.com.tr. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."

; DMARC — strict politika ve raporlama
_dmarc.example.com.tr. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.tr; ruf=mailto:dmarc@example.com.tr; pct=100; adkim=s; aspf=s"

Maliyet-Performans Optimizasyonu

Her sağlayıcının paketleri matematik açıdan eşit değildir. Aynı 200 TL/ay bütçe için sağlayıcı X'te 8 GB RAM yönetilen Linux VPS, sağlayıcı Y'de 4 GB RAM Windows shared paket alabilirsiniz. Ay sonu maliyetinizi etkileyen 6 ana kalem:

• Hosting paketi — ay/yıl ücreti.
• Domain yenileme —.com.tr ~95 TL/yıl,.com ~250 TL/yıl (sağlayıcıya göre değişir).
• SSL — Let's Encrypt ücretsiz; EV gerekirse ~700-2500 TL/yıl.
• Dış servisler — CDN (Cloudflare ücretsiz tier ya da Bunny ~5 USD/TB), e-mail (Workspace ~6 USD/kullanıcı/ay).
• Backup storage — B2/S3 GB başına 0.005-0.02 USD/ay.
• Monitoring — UptimeRobot ücretsiz, Sentry hobby ücretsiz, Datadog 15 USD/host.

Sağlayıcı seçerken "hangisi profesyonel görünüyor" yerine 12 aylık TCO (Total Cost of Ownership) hesaplayın. Yıllık ödeme genelde aylığa göre %20-40 indirim sunar; ancak iade hakkı genelde sadece ilk 30 günü kapsar.

Profesyonel Hosting Tipik Hata ve Mitleri

Hosting sektörü pazarlama dilinin ağır bastığı bir sektör. Aşağıdaki yanlış inanışlar maalesef yaygındır:

• "Sınırsız disk" gerçektir → Yanlış. Tüm sağlayıcılar fair use uygular; tipik tavan 50-200 GB.
• "NVMe = hızlı site" → Eksik. Disk hızı sadece bir değişken; CPU yoğun PHP/.NET kodu yavaşsa NVMe kurtarmaz.
• "7/24 destek" → Çoğunlukla 7/24 chatbot; Tier-2 sysadmin desteği iş saatleri içinde olur.
• ".tr domain offshore'da host edilemez" → Yanlış..tr domain'i Almanya, ABD'de host edilebilir; KVKK ve trafik latency düşünülmeli.
• "Cloud hosting = otomatik yedekli" → Yanlış. AWS EC2'de bile snapshot kurmak SİZİN sorumluluğunuz.
• "Daha pahalı = daha güvenli" → Korelasyon zayıf. Güvenlik konfigürasyona bağlı; ucuz Hetzner VPS, doğru sertleştirilirse 3000 TL/ay shared paketten güvenli olabilir.

.NET 9 ve Sonrası: Hosting Trendleri

.NET 9 ile gelen Native AOT (Ahead-of-Time) compilation, ASP.NET Core uygulamasını tek self-contained binary'ye dönüştürür. Cold start 50ms altına iner, RAM kullanımı 60-70% azalır. Bu, 256 MB RAM'li küçük VPS'lerde bile API service host edilmesine olanak tanır.

# Native AOT publish
dotnet publish -c Release -r linux-x64 \
 --self-contained true \
 -p:PublishAot=true \
 -p:StripSymbols=true \
 -p:OptimizationPreference=Size \
 -o./publish-aot

# Sonuç ~10-15 MB tek binary
ls -lh./publish-aot/MyApp

# RAM kullanımı (boş çalışan)
./publish-aot/MyApp &
ps -o pid,rss,cmd -p $!

Edge function tabanlı hosting platformları (Cloudflare Workers, Deno Deploy, Fastly Compute) henüz native.NET runtime'ını desteklemiyor; ancak WebAssembly (WASM) hedefiyle compile edilen ASP.NET parçaları yakında bu platformlarda da çalışabilir. Bu yön, gelecek 2-3 yılda profesyonel hosting tanımını yeniden şekillendirebilir.

Bir başka trend ise çok bölgeli (multi-region) deploy'un orta ölçek SaaS'ler için olağanlaşmasıdır. Eskiden sadece büyük şirketlerin lüksü olan eu-west, us-east, asia-southeast gibi üç-dört bölgede paralel kümeler kurmak; Cloudflare Tunnel, Fly.io, Hetzner load balancer gibi araçlarla 100-200 USD/ay seviyesine indi..NET 8/9 stateless servisleri için bu kurulum oldukça ucuz; veritabanı tarafında Citus (Postgres distributed) veya CockroachDB ile global tutarlılık problemini çözebilirsiniz.

Sürdürülebilirlik (green hosting) tarafında da fark gözle görülür hale geldi. Hetzner, OVH gibi sağlayıcılar yüzde yüz yenilenebilir enerji sertifikaları yayınlıyor. Kurumsal müşterilerin tedarikçi seçim kriterlerine ESG raporu girdikçe, datacenter PUE (Power Usage Effectiveness) skorunu RFP'lerinde sorması artıyor. PUE 1.2 altı ideal, 1.5 üstü modası geçmiş sayılır.

Profesyonel Hosting Geçişinde 14 Günlük Plan

Mevcut hostingden profesyonel bir paketin/VPS'in altına geçiş, doğru planlanmazsa SEO ve gelir kaybına neden olur. Önerilen 14 günlük rotamız şudur:

• Gün 1-2: Trafik, sayfa hızı ve hata oranı baseline ölçümü (Lighthouse, GA4).
• Gün 3: Yeni hosting'i kira; staging.example.com.tr alt domain'i ile test ortamı kur.
• Gün 4-6: Kod + DB taşıma; staging üzerinde tam fonksiyon testleri.
• Gün 7: Yük testi (k6/wrk) staging'de p95 ölçümü.
• Gün 8: DNS TTL'i 300 saniyeye düşür (geçiş öncesi 24 saat).
• Gün 9: DNS A kaydını yeni IP'ye yönlendir; eski sunucu açık tut.
• Gün 10-12: 48-72 saat trafik takibi; eski sunucudaki son istekleri logla.
• Gün 13: SSL renewal, monitoring uyarıları kontrol; eski paneli pasifleştir.
• Gün 14: Eski hosting iptal; backup'ları yeni sunucu ve dış object storage'a kopyala.

İzleme: Profesyonel Hosting Sürekli Görünürlük İster

Hosting'i kurmak ve unutmak en yaygın hatadır. Prometheus + Grafana ile aşağıdaki metrikleri panellerde takip edin:

• HTTP latency p50/p95/p99 — sağlayıcı SLA'sı ile karşılaştırın.
• 5xx hata oranı — %0.1 üstü uyarı tetiklenmeli.
• CPU, RAM, disk doluluk — %80 üstü 24 saatten uzun → upgrade düşün.
• Disk IOPS ve latency — node_exporter veya cAdvisor.
• SSL expiry — Cert-Manager veya Blackbox Exporter ile 30 gün önce uyarı.
• Domain expiry — yıllık manuel ya da hosting paneli üzerinden auto-renew.
• Synthetic uptime check — UptimeRobot/Better Uptime, çoklu lokasyon.

OpenTelemetry ASP.NET Core ile resmi entegre çalışır; distributed tracing rehberimiz Jaeger/Tempo backend ile mikroservis görünürlüğünü detaylandırır.

Sıkça Sorulanlar

.NET Core uygulaması shared Linux hosting'de çalışır mı?

Çoğu cPanel-tabanlı paylaşımlı Linux hosting Phusion Passenger veya "Application Manager" eklentisiyle.NET Core uygulamasını host edebilir; ancak performans VPS'e göre düşüktür ve sürüm seçenekleri sınırlıdır. Profesyonel kullanım için VPS veya yönetilen bir sağlayıcı tercih edin.

MSSQL yerine PostgreSQL kullanmak ne kazandırır?

Lisans maliyeti sıfır, Linux ekosistemiyle tam uyum, JSONB ve full-text search avantajları, EF Core üzerinden hızlı geçiş. PostgreSQL performans optimizasyonu rehberimiz tuning detaylarını verir.

Windows VPS'te lisans dahil mi?

Çoğunlukla evet — Windows Server Datacenter Edition lisansı sağlayıcı tarafından SPLA (Service Provider License Agreement) kapsamında dağıtılır. Lisans ayrı satılırsa aylık 25-50 USD ek maliyet doğurur.

Kestrel'i public'e açmak güvenli mi?

Microsoft.NET 8 itibariyle Kestrel'i production-ready public listener olarak işaretledi; ancak HTTP/3, WAF, rate limit, koruyucu header'lar için Nginx/Caddy önünde durması hâlâ best practice. WebSocket trafiğinde Nginx'in keep-alive overhead'i ihmal edilebilir.

Hangi panel tercih edilmeli: Plesk mi cPanel mi?

Windows +.NET odaklıysanız Plesk; Linux + PHP+Node.js tercihinizse cPanel daha olgun. Açık kaynak alternatif arıyorsanız Webmin veya HestiaCP düşünün.

Kaynaklar

• learn.microsoft.com — ASP.NET Core Host and Deploy
• Microsoft Learn — Kestrel web server
• .NET Support Policy
• nginx.org/en/docs
• SSL Labs Server Test
• OWASP Top 10
• letsencrypt.org/docs
• docs.docker.com
• k6 yük testi dokümantasyonu
• Tier Classification — datacenter sertifikaları

İlgili Yazılar

• Hosting nedir ve hosting türleri
• VPS Nedir? VPS vs VDS
• Plesk Panel Yönetimi
• cPanel ile Site Yönetimi
• Nginx yapılandırma rehberi
• Let's Encrypt SSL kurulumu
• Docker ile uygulama deploy
• GitHub Actions CI/CD
• Veritabanı yedekleme stratejileri
• VPS güvenlik sertleştirme