The Cleanest Way to Install IIS on a Windows VPS and Get ASP.NET Core Running

If you are planning to host an ASP.NET Core app on a remote Windows machine, the fastest path is usually the one that feels most boring: install IIS on Windows VPS, add the right runtime components, and keep the configuration simple. Most deployment failures happen because one small prerequisite is missing, the application pool is misconfigured, or the site folder permissions are not set for the identity that IIS actually uses.
This walkthrough is written for people who want a stable IIS setup they can reuse for multiple projects, not a one-off test that breaks the next time Windows updates. You will learn what to enable in IIS, why the .NET Hosting Bundle matters, how application pools fit into the picture, and how to structure a basic deployment so you do not end up stuck in endless 500 errors. I am assuming you have Administrator access to your VPS, and you can connect over Remote Desktop. If you are using a Windows VPS from PerLod, this is the same core approach you can follow whether you are hosting a simple API or a full ASP.NET Core web app.
Why IIS is still a great fit for ASP.NET Core on a VPS
IIS is not just a web server. On Windows Server, it is a whole ecosystem of management tools, process isolation, logging, bindings, and security controls that are hard to replicate with a quick install of something else.
When you host ASP.NET Core behind IIS, you are effectively combining:
• IIS as the front door, handling site bindings, TLS, and request routing.
• The ASP.NET Core hosting integration that allows the app to run properly under IIS.
• A deployment model where you copy a published output folder, not your source code.
That combination is why many teams choose to install IIS on Windows VPS even when they run Linux elsewhere.
Prerequisites you should confirm before you start
Before touching roles and features, it helps to confirm your baseline. This reduces the chance you complete the setup and then discover your VPS is missing an expected component.
Quick checklist:
• You have Administrator access and can open Server Manager.
• You know which Windows Server version you are on (2012 R2 or later is commonly used).
• You have enough disk space for IIS, logs, and your published app output.
• You have a plan for inbound ports (80 and 443, or a custom port for testing).
If you are setting this up for production, decide early whether you will bind to a domain name or start with an IP and add DNS later.
How to install IIS on Windows VPS using Server Manager
The most reliable way to install IIS on Windows VPS is through Server Manager, because it ensures required features are installed in a supported way.
High-level steps:

1. Open Server Manager.
2. Go to Manage and choose Add Roles and Features.
3. Select Role-based or feature-based installation.
4. Pick your VPS from the server pool.
5. Check Web Server (IIS).
6. Accept the prompt to add required features.
7. In Role Services, keep defaults unless you know you need something specific.
8. Click Install.
   After it finishes, you should be able to open IIS Manager and see the default site. For a quick sanity check, browsing to the local server’s default website (or its public IP if firewall rules allow it) should show the IIS welcome page.
   H3 Choosing role services without overcomplicating things
   A common mistake is enabling every role service “just in case.” That can increase attack surface and make troubleshooting harder.
   A sane baseline for ASP.NET Core hosting usually includes:
   • The core web server role
   • Management tools so you can use IIS Manager
   • Features you know you need (for example, static content)
   You can always add role services later if your app requires something special.
   Install the .NET Hosting Bundle and why it matters
   A Windows VPS can have IIS installed perfectly and still fail to run an ASP.NET Core app if the server does not have the correct runtime components. That is what the .NET Hosting Bundle is for.
   Think of it as the “bridge” between IIS and your ASP.NET Core app. It installs the runtime and the IIS integration needed so IIS can properly start and manage your application.
   Once you install the Hosting Bundle, it is smart to restart IIS services so the new components are recognized. You do not usually need a full server reboot, but you do want IIS to reload.
   H3 A quick note on matching your app’s runtime
   If your app targets a specific .NET version, your server needs a compatible runtime available. If you deploy an app built for a newer runtime than what is installed, the app may fail at startup and look like an IIS problem when it is actually a runtime mismatch.
   Configure an application pool the right way for ASP.NET Core
   Application pools are IIS’s way of isolating apps. Each pool runs under its own worker process, which keeps one misbehaving site from taking down everything else.
   For ASP.NET Core, application pool configuration is often simpler than people expect.
   Key idea: IIS does not need to load the classic .NET CLR for an ASP.NET Core app. In many cases, you should set the pool to No Managed Code.
   Basic steps in IIS Manager:
9. Go to Application Pools.
10. Create a new pool (recommended) or configure an existing one.
11. Set .NET CLR version to No Managed Code.
    H3 Naming conventions that save you pain later
    If you plan to host more than one site, do not use vague names like “NewPool” or “AppPool2.” Use something tied to the app or domain, so log review and permission management stay obvious.
    Create an IIS site with clean bindings and a clear folder layout
    Once IIS is installed and the runtime prerequisites are in place, your next job is to create a site entry that points to a specific folder on disk.
    A clean layout helps you troubleshoot and upgrade.
    Recommended folder approach:
    • Use a dedicated folder per site
    • Avoid scattering apps across random paths
    • Keep a predictable structure so backups and permissions are straightforward
    When creating your site in IIS Manager:
    • Give the site a clear name
    • Set a physical path to the folder where you will deploy the published output
    • Configure binding to a port and optionally a host name
    Here is a simple example of how to think about the binding decisions:
    Binding choice Best for Common gotcha
    IP + port 80 quick testing conflicts if you host multiple apps on port 80
    Host name + port 80 multiple sites on one IP DNS must point to the VPS IP
    HTTPS + host name production certificate management and firewall rules
    If you are starting from scratch, begin with HTTP on a known port, confirm the app loads, then add HTTPS afterward.
    Fix permissions so IIS can actually read your deployed files
    One of the most frustrating “silent failures” is when the site exists, but IIS cannot access the files it needs. IIS typically runs under an application pool identity, not your Administrator account.
    That means your app folder needs at least Read and Execute permissions for the identity that runs your pool.
    A practical way to think about it:
    • Your deployment copies files into a folder
    • IIS must be able to read those files
    • Your app may also need write access to a logs folder, uploads folder, or temp directory
    If you skip permissions, the site might return errors that look like configuration problems.
    Publish and deploy an ASP.NET Core app the safe way
    IIS cannot run your project source folder directly. You deploy a published output, which is the compiled and packaged version of your app.
    A reliable deployment workflow looks like this:
12. Publish your app from your development machine.
13. Copy only the published output to the IIS site folder.
14. Confirm the app starts on the server.
15. Then optimize and harden.
    Short deployment checklist:
    • Publish in Release mode.
    • Copy the full publish output folder contents.
    • Do not forget configuration files your app relies on.
    • Verify the site’s physical path matches where you copied the files.
    • Restart the site or recycle the app pool after a significant update.
    H3 How to avoid “it works locally” deployment traps
    Many apps work locally because Visual Studio or your local machine already has the runtime installed and your environment variables are set.
    On a Windows VPS, you should treat the server as a clean environment. Make sure:
    • The runtime is installed on the server.
    • Your app settings are present (environment variables or appsettings).
    • Your process has the permissions it needs.
    • Your port and binding choices match how you plan to access the app.
    Troubleshooting: the most common IIS errors and what they usually mean
    If you install IIS on Windows VPS and your app still fails, it is usually one of a few repeat offenders.
    H3 HTTP Error 500.30: app failed to start
    This often means the app process did not start correctly. When you see this:
    • Confirm the .NET Hosting Bundle is installed.
    • Verify the app pool is configured as expected.
    • Re-check folder permissions for the application pool identity.
    • Look for details in Event Viewer, which often points to the missing runtime or configuration issue.
    H3 HTTP 500.19 after deployment
    This commonly shows up when IIS cannot read a configuration file or a required module is missing.
    Two frequent causes:
    • A malformed configuration entry in the site’s configuration
    • Missing components such as a rewrite module when a configuration expects it
    H3 Hosting multiple apps on one VPS
    Yes, you can run several ASP.NET Core apps on a single Windows VPS, but you must keep them clearly separated:
    • Separate site folders
    • Separate application pools when you want isolation
    • Unique bindings (different host names, ports, or IPs)
    This is where a tidy naming convention pays off.
    Final step: confirm the setup and keep it repeatable
    Before you call it done, do a quick validation pass:
    • The IIS site starts without errors
    • The default landing page or your app responds as expected
    • Logs are being written where you expect them
    • Your firewall or security group allows inbound traffic for the chosen binding
    If you are planning to replicate this across multiple servers, write down your baseline choices: which role services you enabled, which runtime you installed, and how you structure site folders.
    Conclusion
    A stable IIS deployment is mostly about discipline: keep the prerequisites tight, publish a clean app output, and configure IIS in a way you can explain to yourself six months from now. When you install IIS on Windows VPS, remember that IIS is only one part of the pipeline. The hosting bundle, application pool settings, site bindings, and file permissions all have to line up for the app to start cleanly.
    If you want a reference guide that walks through the same end-to-end flow from installation to deployment and common errors, you can follow this tutorial: Install IIS on Windows VPS for ASP.NET Core .