App Service: slots, capacity and paths

Preparing a slot

Cloning settings when creating a slot copies neither application content nor the private endpoint. Prepare the new slot’s deployment and connectivity before a trial. Slots have their own hostnames and are live applications; absence of main-URL traffic does not mean absence of execution.

Select settings that must remain with each slot, including connection strings where required. Check plan capability for existing slots.

Preview and external effects

During swap with preview, the source receives target settings and restarts for validation. Startup code can therefore reach production dependencies before final switching. Control jobs and external effects at that point.

If a release changes data and you later reverse the swap, previous code returns but external database transactions are not automatically undone. Maintain data compatibility and a separate reconciliation procedure.

Shared capacity

In a dedicated App Service plan, apps and slots share plan instances. Without per-app scaling, they scale together. Dedicated separates the plan from other customers; it does not automatically give each app an independent VM.

An intensive staging test can compete with production. Measure consumption and surviving capacity, and assess separate plans when isolation is required. Creating more slots is not equivalent to increasing compute capacity.

Inbound and outbound

VNet integration permits outbound application calls through a virtual network; it does not create private inbound access. For private ingress, prepare a private endpoint, client DNS and public-endpoint control. To send all Internet traffic through a firewall, configure all traffic routing and corresponding routes and dependencies.

A UDR helps only flows that actually enter that path. In the exercise, draw client-to-app and app-to-dependency paths separately.

Common pitfalls

Do not confuse slots with physical isolation, reverse swap with data rollback, or outbound integration with private ingress.