No, on shared hosting based services you are not allowed to install your own software, COM objects, or services on our servers. Customers are also not allowed to run any customized executables, services or applications. If you require a specialized component or application you can upgrade to a VPS or dedicated server solution.

This restriction protects the shared server environment that hosts dozens or hundreds of customer sites simultaneously. It prevents one account from introducing instability, excessive resource usage, or security risks that would affect all other customers on the same hardware.

#Understanding the Restrictions

Shared Windows hosting provides a pre-configured IIS environment with standard .NET frameworks, databases, and supporting components already installed and patched. You receive permissions sufficient to deploy and run web applications, manage files via FTP, configure application settings, and work with databases. However, you do not receive administrative rights to the operating system itself. This means commands that modify the global server state, install system-level components, or launch persistent processes are blocked at the OS permission layer.

#Why These Restrictions Exist

In multi-tenant shared hosting, resource allocation and system stability are paramount. A single custom service or COM object with a memory leak or inefficient polling loop can consume CPU cycles, RAM, or disk throughput that should be available to every site on the server. Security is another critical factor: untrusted executables could contain vulnerabilities, backdoors, or privilege-escalation paths that put the entire host at risk. Support overhead also increases dramatically when every customer maintains a unique server configuration; standardization allows rapid patching, monitoring, and troubleshooting across the platform.

These rules are not arbitrary. They are the direct result of operating a reliable, high-density Windows hosting platform that delivers consistent performance at economical price points. Without them, the shared model would become unsustainable.

#Common Prohibited Activities

  • Registering custom COM or ActiveX components with regsvr32 or similar tools
  • Installing and running persistent Windows services or background executables
  • Deploying compiled binaries that execute outside the IIS application pool
  • Adding or modifying server-wide software such as additional database engines, mail relays, or caching daemons
  • Altering system PATH variables, registry keys outside your application scope, or IIS global configuration

#What You Can Build Within Shared Hosting

The majority of .NET web applications run successfully without any server-level customizations. You may use the installed versions of .NET Framework and .NET Core, classic ASP, standard IIS modules, ADO.NET, Entity Framework, and any assemblies already present in the Global Assembly Cache. Application-specific logic, business rules, and user interface code can be as complex as needed provided they operate inside the sandbox created by your application pool identity.

Configuration at the web-application level remains highly flexible. You control your own web.config or appsettings files and can register custom HTTP modules, handlers, URL rewrites, and authentication providers without requiring administrator intervention.

xml 
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <modules>
      <add name="CustomHttpModule" 
           type="MyCompany.CustomModule, MyAssembly" />
    </modules>
    <handlers>
      <add name="CustomHandler" 
           path="*.custom" 
           verb="*" 
           type="MyCompany.CustomHandler" />
    </handlers>
  </system.webServer>
</configuration>

The example above demonstrates registering application-level components safely inside your own site. Such changes are permitted because they affect only your application pool and do not alter the shared server configuration.

#When to Upgrade to VPS or Dedicated

Projects that depend on specific COM libraries, legacy executables, custom Windows services, additional server roles, or non-standard software should run on a VPS or dedicated server. These solutions give you full administrator access to the operating system, allowing you to install, configure, start, stop, and monitor any software you require. You can also tune IIS settings globally, adjust firewall rules, manage scheduled tasks, and install third-party monitoring or backup agents.

The transition from shared to VPS or dedicated is straightforward once you determine your application truly needs elevated privileges. Planning for the correct hosting tier from the beginning avoids refactoring effort and downtime later.

Review your project architecture against the limitations described here. If you are uncertain whether a particular component or service can run under shared hosting, compile a clear list of required binaries and dependencies and consult the support team before deployment. Choosing the right environment upfront ensures both compliance and optimal performance.