In short
IIS Application Pools control how your web app runs on Windows Server: process identity, idle timeout, start mode, memory-based recycling, regular recycling, and runtime behavior. The defaults are acceptable for simple development sites, but production apps need safer settings. For most production IIS workloads, use one app pool per site, keep the app warm with AlwaysRunning, disable or extend idle timeout, set a private memory recycle limit, and verify the final configuration with PowerShell.
Quick verdict
| Situation | Recommended action |
|---|---|
| Production web app | Use a dedicated app pool |
| ASP.NET Core app | Set managed runtime to No Managed Code |
| App has cold starts after idle periods | Set idle timeout to 0 and start mode to AlwaysRunning |
| App memory usage grows over time | Set a private memory recycle limit |
| Multiple apps share one pool | Split into separate pools for isolation |
| App needs network resources under a specific account | Use a dedicated service account |
| Low-traffic dev/test app | Defaults may be acceptable |
The goal is not to tune every IIS setting. The goal is to prevent cold starts, isolate apps, limit memory damage from leaks, and make app pool behavior predictable.
Why IIS Application Pools matter
An IIS application pool wraps one or more web applications inside a worker process named w3wp.exe.
Application pool settings control:
- Which identity the app runs as
- Whether the app pool starts on demand or stays warm
- When idle worker processes are stopped
- When the worker process recycles
- Whether the pool loads the .NET Framework CLR
- How much private memory the process can use before recycling
- How failures are handled
For production hosting, application pools are one of the most important IIS isolation boundaries.
A practical rule:
One production site should have its own application pool.
This way, a crash, memory leak, or recycle in one app does not automatically affect unrelated apps.
What we tested on Raff
We tested this walkthrough on a Raff Windows VPS running Windows Server 2025 Datacenter Evaluation with IIS installed.

Test environment:
| Item | Value |
|---|---|
| Provider | Raff Technologies |
| OS | Windows Server 2025 Datacenter Evaluation |
| IIS | IIS 10 |
| Test app pool | RaffTestAppPool |
| Test date | 2026-05-26 |
| Tester | Aybars Altinyay |
On this VM, we verified:
- IIS feature state
- IIS Manager Application Pools view
- Creation of a test application pool
- Application pool recycling settings
- Final app pool configuration with PowerShell
We used a test app pool named RaffTestAppPool. We did not tune a live production website in this lab.
What you'll need
- A Raff Windows VPS running Windows Server
- IIS installed
- IIS Management Console installed
- Local administrator access
- PowerShell running as Administrator
- A test app pool or a maintenance window for production changes
If IIS is not installed yet, install it with:
Install-WindowsFeature Web-Server, Web-Mgmt-Console, Web-Scripting-Tools -IncludeManagementTools
Then open IIS Manager with:
Win + R -> inetmgr
Step 1 - Review existing application pools
Before changing anything, review the current application pools.
Open IIS Manager:
Start -> Internet Information Services (IIS) Manager -> Application Pools

You can also list app pools with PowerShell:
Import-Module WebAdministration Get-ChildItem IIS:\AppPools
For each production app, check:
| Setting | Why it matters |
|---|---|
| Name | Should clearly match the site/app |
| State | Started or stopped |
| .NET CLR version | ASP.NET Core usually needs No Managed Code |
| Identity | Controls file, network, and database access |
| Idle timeout | Affects cold starts |
| Recycling | Affects process restarts |
| Private memory limit | Limits damage from memory leaks |
Avoid changing multiple pools at once. Tune one app pool, test the app, then continue.
Step 2 - Create a dedicated app pool
For the lab, we created a dedicated test app pool:
Import-Module WebAdministration New-WebAppPool -Name "RaffTestAppPool" Get-Item IIS:\AppPools\RaffTestAppPool

For production, use clear names:
example.com api.example.com customer-portal quickbooks-webconnector internal-erp
Do not put every site into DefaultAppPool.
A dedicated app pool gives you:
- Better isolation
- Separate recycle behavior
- Separate identity
- Easier troubleshooting
- Cleaner performance monitoring
Step 3 - Tune idle timeout
The default IIS idle timeout is commonly 20 minutes. After the app pool receives no traffic for that period, IIS can stop the worker process.
For low-traffic production apps, this causes cold starts. The first user after an idle period may wait several seconds while the app starts again.
For production user-facing apps, disable idle timeout:
Set-ItemProperty IIS:\AppPools\RaffTestAppPool -Name "processModel.idleTimeout" -Value "00:00:00"
Alternative: set a long timeout, such as 8 hours:
Set-ItemProperty IIS:\AppPools\RaffTestAppPool -Name "processModel.idleTimeout" -Value "08:00:00"
Use this guidance:
| App type | Suggested idle timeout |
|---|---|
| Production customer-facing app | 00:00:00 |
| Internal app used all day | 00:00:00 or long timeout |
| Low-traffic dev/test app | Default may be fine |
| Memory-constrained server | Use a longer timeout instead of disabling |
Disabling idle timeout keeps the worker process warm, but it also keeps memory allocated. Make sure the VPS has enough RAM.
Step 4 - Set start mode to AlwaysRunning
Idle timeout controls when the process stops after inactivity. Start mode controls whether IIS starts the application pool proactively or waits for the first request.
For production, set:
Set-ItemProperty IIS:\AppPools\RaffTestAppPool -Name "startMode" -Value "AlwaysRunning"
Recommended combination:
| Setting | Production value |
|---|---|
| Idle timeout | 00:00:00 |
| Start mode | AlwaysRunning |
This reduces cold starts and helps keep the app ready for traffic.
For full warm-up behavior, pair this with Application Initialization when appropriate.


