Shared Hosting'de ASP.NET Core Deploy Rehberi ASP.NET Core Deploy Guide for Shared Hosting

Shared hosting, birden fazla müşterinin aynı fiziksel sunucuyu paylaştığı barındırma modelidir. Ucuz, kurulumu kolay — ama kısıtlı.

SSH erişimi yok, root yetkin yok, istediğin servisi kuramazsın. Dosya yönetimi FTP ile, uygulama yönetimi Plesk veya cPanel gibi paneller üzerinden yapılır.

ASP.NET Core uygulamalarını shared hosting'de çalıştırmak mümkün — ama birkaç önemli noktayı bilmek gerekir.

Shared hosting is a hosting model where multiple customers share the same physical server. Cheap, easy to set up — but limited.

No SSH access, no root privileges, can't install the services you want. File management is done via FTP, and application management is done through panels like Plesk or cPanel.

Running ASP.NET Core applications on shared hosting is possible — but you need to know a few important things.

Büyük bir proje birden fazla ASP.NET Core uygulamasından oluşabilir. Her subdomain ayrı bir uygulama olabilir:

• api.site.com — API projesi
• app.site.com — kullanıcı paneli
• manage.site.com — yönetim paneli
• ops.site.com — operasyonel araçlar

Bu uygulamaların tümü aynı IIS app pool'u paylaşıyorsa, outofprocess zorunludur. Bir uygulamanın çökmesi diğerlerini etkilememeli.

Migration konusuna da dikkat etmek gerekir. Program.cs'te MigrateAsync() kullanıyorsan, ilk açılışta birkaç saniyelik gecikme yaşanabilir — bu normal.

A large project can consist of multiple ASP.NET Core applications. Each subdomain can be a separate application:

• api.site.com — API project
• app.site.com — user panel
• manage.site.com — management panel
• ops.site.com — operational tools

If all these applications share the same IIS app pool, outofprocess is required. The crash of one application should not affect the others.

Migration also needs attention. If you use MigrateAsync() in Program.cs, there may be a few seconds of delay on first startup — this is normal.

Her deploy öncesi şu listeyi gözden geçirmek, sonradan saatlerce sürecek hata ayıklamayı önler:

• ✅ appsettings.Production.json → CopyToPublishDirectory: Never
• ✅ appsettings.Development.json → CopyToPublishDirectory: Never
• ✅ private.key (varsa) → CopyToPublishDirectory: Always
• ✅ web.config environmentVariables → tüm sırlar girildi mi?
• ✅ hostingModel → outofprocess (shared hosting için)
• ✅ stdoutLogEnabled → false (production'da kapalı)
• ✅ Connection string → TrustServerCertificate=True var mı?
• ✅ Migration → çalıştırıldı mı?

Going through this list before every deploy prevents hours of debugging later:

• ✅ appsettings.Production.json → CopyToPublishDirectory: Never
• ✅ appsettings.Development.json → CopyToPublishDirectory: Never
• ✅ private.key (if present) → CopyToPublishDirectory: Always
• ✅ web.config environmentVariables → are all secrets entered?
• ✅ hostingModel → outofprocess (for shared hosting)
• ✅ stdoutLogEnabled → false (closed in production)
• ✅ Connection string → does it have TrustServerCertificate=True?
• ✅ Migration → has it been run?

Shared hosting'de production deploy yaparken karşılaşılan en yaygın hatalar ve çözümleri:

1. Plesk subscription plan çakışması
Yeni subscription oluştururken disk_space, mssql_dbase_space veya total_mboxes_quota kotaları çakışabilir. Çözüm: subscription planı olarak "hiçbiri" seç (Custom mod), kotaları tek tek Sınırsız yap.

2. Connection string key eşleşmemesi
GetConnectionString("database") yazıp env var'a ConnectionStrings__DefaultConnection koymak — eşleşmez, null döner, bağlantı kurulamaz. Key'in sonu C# kodu ile birebir aynı olmalı.

3. TrustServerCertificate eksikliği
Bağlantı kurulur ama login sırasında SqlException fırlar. Connection string'e TrustServerCertificate=True ekle.

4. appsettings.Production.json publish'e gitmiş
CopyToPublishDirectory=Never ayarı unutulmuşsa, bu dosya sunucuya gider. Sırların publish çıktısında olmaması için bu ayarı kontrol et.

The most common errors encountered when doing a production deploy on shared hosting, and their solutions:

1. Plesk subscription plan conflict
When creating a new subscription, disk_space, mssql_dbase_space, or total_mboxes_quota quotas may conflict. Solution: select "none" as the subscription plan (Custom mode), set quotas to Unlimited one by one.

2. Connection string key mismatch
Writing GetConnectionString("database") but putting ConnectionStrings__DefaultConnection in the env var — it doesn't match, returns null, connection fails. The end of the key must exactly match the C# code.

3. Missing TrustServerCertificate
Connection is established but a SqlException is thrown during login. Add TrustServerCertificate=True to the connection string.

4. appsettings.Production.json went into publish
If the CopyToPublishDirectory=Never setting was forgotten, this file goes to the server. Check this setting to make sure secrets are not in the publish output.

Deploy tamamlandıktan sonra uygulamanın gerçekten çalışıp çalışmadığını doğrulamak için sıralı test adımları:

• 1. Swagger / ana sayfa — site açılıyor mu? HTTP 200 geliyor mu?
• 2. Ping endpoint — API varsa /api/ping gibi basit bir endpoint çağır. [AllowAnonymous] olmalı.
• 3. DB bağlantısı — DB'ye bağlanan bir endpoint çağır. Hata dönüyorsa connection string veya TrustServerCertificate sorunu olabilir.
• 4. Log kontrol — stdoutLogEnabled=true yap, bir istek gönder, log dosyasını FTP'den çek, kontrol et, tekrar false yap.
• 5. Migration kontrolü — tablolar oluşmuş mu? DB'yi Plesk üzerinden kontrol edebilirsin.

After deploy is complete, sequential test steps to verify the application is actually working:

• 1. Swagger / home page — does the site open? Is there an HTTP 200 response?
• 2. Ping endpoint — if there is an API, call a simple endpoint like /api/ping. It should be [AllowAnonymous].
• 3. DB connection — call an endpoint that connects to the DB. If it returns an error, it may be a connection string or TrustServerCertificate issue.
• 4. Log check — set stdoutLogEnabled=true, send a request, pull the log file via FTP, check it, then set it back to false.
• 5. Migration check — were the tables created? You can check the DB through Plesk.