ASP.NET Core Deploy Guide for Shared Hosting

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.

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.

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?

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.

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.