I have recently developed a MVC application for a client and they would like to host it, along with a few other apps on the same server.

I am more of a developer than a server admin, but my instinct was to set up a new site in IIS with it's own sub-domain binding.

The client, however, would like to instead create a virtual directory in the default site that points to the application. So, for example, you would have:


Rather than:


This did work; however, it conflicted with relative URLs in standard HTTP markup, a problem that was quickly resolved.


Is it better to host multiple web apps on the same server as separate sites or as virtual directories within the default website? Are there any pitfalls with the virtual directory approach?

I am not judging the virtual directory approach, it is just new to me and I want to ensure that it won't cause problems now or in the future.

  • I have the same question as OP. I currently use one site per application because it allows me to start and stop the individual websites. However, we don't have DNS set up to allows us to use host headers, so each website has to run on a different port. This makes for unfriendly URLs. VDs under Default Web Site would allow for friendly URLs at the cost of granularity. – Walter Stabosz Dec 13 '12 at 17:18
  • Huh? If it was truly relative URLs it would not have mattered if the application was in its own site, in a virtual directory, or in another sites directory several levels deep. – Ants May 6 '16 at 1:05

I have always tried to stick to individual sites for applications. You get much more control over everything and if you're running ASP.NET you don't run into web.config cascading issues that are easy to hit. Plus you have finer grained control over application pools and actually being able to watch the performance of each individual application. This is all preference.

Regardless, probably the best answer is that you apply bindings at the website level and NOT the application level. So if each app needs its own URL or SSL as opposed to non-SSL you really do have to look at individual sites.

Plus as you mention you almost have to program with the deployment mechanism in mind. As any use of relative URLs breaks lots of stuff.

Lastly: why don't they want to use sub-domains? It provides nice clean RESTfulish separation of resources if you ask me.

| improve this answer | |
  • Nice RESTful separation of resources that can't be easily shared without configuring CORS or Jsonp.... – Chris Pfohl Dec 12 '14 at 13:33

I'd say it depends... Are the applications very similar to one another in that you could be comfortable making a single change at the higher level that would cascade down to each virtual directory that would not impact the functionality of any single app? If you have a separate site for each app then you will need to separately manage each site's settings (Certs, IPs, ports, etc), which could be a headache if there are a lot of them, but they are totally independent sites so a setting would not affect another app. The real work is done by the worker process/App Pool so in either setup you could share the same app pool for multiple apps or have a separate one for each app.

  • Applications on separate sites = much more granular control over the app and how to connect to it at the cost of more maintenance for each site
  • Applications on same site = easier to manage if they are all very similar, but you could run into configuration issues if the apps have conflicting requirements
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.