Deploying ASP.NET Core with IIS on a Windows VDS

To deploy an ASP.NET Core application on a Windows VDS, first verify administrator access through RDP, the correct .NET runtime environment, and that the domain name points to the server. Then create a separate site and application pool in IIS, connect the published files, configure permissions in a limited manner, and test the same URL using new log entries.

What you need before starting with Windows VDS and IIS

This process is intended for a Windows VDS environment running Windows Server that you can access as an administrator through RDP. If you only have permission to add sites in a shared hosting panel, you cannot change IIS and application pool settings; in that case, clarify the provider’s management scope in advance.

Separating which technology the application was built with is the first important decision. An ASP.NET Core application requires the appropriate .NET Hosting Bundle to be present on the server, while a classic ASP.NET Framework application uses a different combination of IIS and .NET Framework components. If your publishing output is for ASP.NET Core, installing only the .NET SDK on the server is not sufficient; IIS also needs the relevant Hosting Bundle and ASP.NET Core Module so that it can start the application.

The domain’s DNS record must point to the server’s public IP address, and the provider-side network rules must allow connections on port 80 for HTTP and port 443 for HTTPS. If DNS has not propagated yet, test first using the server’s local or temporary address; do not mistake domain resolution for an application error. Back up the application files and database information, note the existing IIS settings, and apply changes one at a time.

Deploying the application on IIS

1. Check Windows features and the runtime environment. Verify through Server Manager or IIS Manager that the Web Server role and the required ASP.NET components are installed. If the server does not have a Hosting Bundle compatible with the .NET version targeted by the application, first use the installation package supported by the vendor. After installation, check that IIS recognizes the ASP.NET Core application and that the event logs contain no missing-module warning. If the environment is compatible, continue to the next step; if a version mismatch appears, correct the target version instead of trying to run the application with a randomly selected runtime.
2. Place the published files in a separate folder. Use the publish output created for production, not the source code on the development computer. Transfer this folder to the VDS using a secure transfer method and connect it to the physical path selected in the IIS site settings. In IIS Manager, enter a unique name, the correct physical path, and suitable binding information for the new site. If a simple static file opens in the browser, the IIS path is correct; if you see a 404, correct the file path or site binding first instead of changing the application code.
3. Configure the application pool with the correct hosting model. For ASP.NET Core applications, use suitable application pool settings so that IIS starts the application through the ASP.NET Core Module; do not copy classic ASP.NET Framework settings. The application pool identity should have read and execute access only to the folders it needs. Instead of granting broad write permission to application files, assess separately the locations that genuinely need to be writable, such as an upload or logging folder. After starting the site, check whether the pool stops and whether new errors appear in the Application logs in Windows Event Viewer.
4. Test the first request in a controlled manner. First open the site address from the same VDS, then open the domain name from an external network. If a static file loads but the application returns a 500 error, compare the entry for the same time in the IIS access logs with the new ASP.NET Core event in the Application section of Event Viewer. For example, if the entry reports HTTP Error 500.30 and says that the application could not start, the problem is generally a missing or incompatible runtime, an incorrect environment variable, or the application’s startup configuration; this finding does not prove a permissions error. First correct the target runtime and application settings, then recycle only the relevant application pool.
5. Verify the same operation with new evidence. Note the time of the change, reopen the same application URL that previously failed, and check the new IIS entry corresponding to the time of that request. If the new entry shows a successful HTTP status and the application’s expected response, the deployment problem has been resolved. If the failure continues, inspect the first meaningful error line in the new event instead of interpreting the old entry again. If the change made the problem worse, return to the previous runtime, binding, or application pool value that you recorded; do not change another setting at the same time.

Choosing the right correction based on the symptom

If the site does not open at all and the browser shows a connection timeout, first check DNS resolution, the VDS’s public IP address, and the relevant ports in the provider’s firewall. In contrast, if the default IIS page opens but the site for the domain does not, a host name or port conflict in the binding record is more likely. Correct the network path in the first case and the IIS site binding in the second; do not change the application files for two different symptoms.

Suppose the application files are in the correct folder, a static health file opens, and only the application URL returns 500.30. If the Event Viewer entry says that the targeted .NET runtime is not present on the server, completing the installation with a compatible Hosting Bundle is a logical correction. If, after the same test, the new entry shows a database connection refusal, this indicates that the initial problem has been resolved and that the remaining problem is in the application’s connection settings; expanding IIS permissions is not the correct solution in that situation.

HTTPS and production checks

After the application works over HTTP, add the HTTPS binding. Check that the certificate matches the domain name, is valid, and is connected to the correct site in IIS. If HTTPS fails, first inspect the certificate and binding record; if the application continues to return 500, inspect the application’s new event log. Do not disable security checks to resolve a TLS problem.

After completing the initial setup, when reviewing Turkey VDS server plans, do not make your decision based only on the operating system name. Also verify the RAM, disk type, backup method, network access, and Windows licensing scope required by the application. The safest next step after completing the deployment is to monitor the same health URL at defined intervals and preserve the current publish folder for rollback before a new release.