Hosting Multiple Websites Inside an Azure App Service
You start hosting multiple websites inside an Azure App Service by sharing one compute plan. You can also map separate folders inside a single web app instance. Teams often use this setup to cut cloud bills and group small web projects. Still, sharing compute or app folders mixes permissions and widens the blast radius during mistakes. How hosting multiple websites inside an Azure App Service works Azure gives teams two main ways to host several sites on shared compute. The first method puts
Azure RBAC + Per-App VPN: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You start hosting multiple websites inside an Azure App Service by sharing one compute plan. You can also map separate folders inside a single web app instance. Teams often use this setup to cut cloud bills and group small web projects. Still, sharing compute or app folders mixes permissions and widens the blast radius during mistakes.
How hosting multiple websites inside an Azure App Service works
Azure gives teams two main ways to host several sites on shared compute. The first method puts separate web apps onto the same App Service Plan. In this model, each site gets its own domain, deploy pipeline, and app settings. Yet all those sites share the exact same underlying virtual machines, memory, and CPU.
The second method runs multiple sites inside one single App Service instance. You set up virtual paths that map URL routes to different file folders. One folder holds the main web app, while another folder holds a second site. Both folders run inside the same root resource and share the same system identity.
Many teams pick the virtual folder method for sub-apps, admin portals, or legacy code. You only manage one cloud resource, one TLS certificate, and one set of rules. Each folder can run its own framework, provided the parent operating system supports it.
What shared hosting solves and what gaps remain
Sharing an App Service Plan or instance solves the problem of wasted server capacity. Small internal apps rarely need a dedicated virtual machine running all day and night. Packing several web apps onto one plan keeps monthly cloud costs low and predictable. It also reduces the number of base compute plans your ops team must patch.
Still, grouping sites inside one app instance creates serious security and access risks. Cloud role rules apply at the App Service level, not at the folder level. If a developer gets deploy rights for one sub-site, they can alter all sites. All folders also share the same environment variables, database keys, and managed identities.
Azure RBAC + Per-App VPN: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This native setup decides who logs in to the cloud portal or deploy pipeline. It does not check what individual commands or database queries do during a session. When an engineer troubleshoots a shared app, they can read secrets for every site. A bad query or file delete in one folder can break the whole service.
When to split apps vs share an instance
You should use separate App Service instances on a shared plan for most workloads. This keeps app settings, managed identities, and deploy roles isolated between different project teams. If one team updates their site, they will not overwrite files for another site. You still save money because all the apps share the same compute pool.
Reserve virtual folders inside a single instance for tightly coupled components owned by one team. Even then, watch resource limits closely because one memory leak will crash every site. Also, review how engineers run live debugging commands or query backing databases during incidents. Role checks at login do not stop risky actions once a session starts.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can multiple websites share one App Service Plan with separate domains?
Yes, each App Service instance inside a shared plan can bind its own custom domain. Each site also manages its own TLS certificates and deployment slots independently.
Do virtual applications inside one App Service share environment variables?
Yes, all virtual paths inside a single App Service instance share the same app settings. Any connection string or secret key is readable by every folder in that instance.
Does one heavy website slow down other sites on the same plan?
Yes, all sites on an App Service Plan pull from the same CPU and memory. A traffic spike on one site can starve the other sites of compute resources.