Azure App Service and Function App Naming Conventions
CAF naming for web apps, function apps, App Service plans, and slots: the azurewebsites.net hostname rules, the 32-character Functions host ID gotcha, and IaC examples.
App Service and Function App names become public hostnames (
yourapp.azurewebsites.net), so they must be globally unique, 2 to 60 characters, alphanumerics and hyphens:app-payments-prod-eus-001,func-orders-prod-eus-001. The App Service plan underneath is only resource-group scoped, soasp-payments-prod-eus-001needs no extra entropy.
Web apps and function apps share the same resource type under the hood (Microsoft.Web/sites), which means they share the same naming rules, and the same trap: the name you pick is a public DNS hostname from the moment you deploy.
The pieces and their rules
| Resource | CAF prefix | Length | Unique within |
|---|---|---|---|
| Web app | app | 2-60 | All of Azure (it becomes name.azurewebsites.net) |
| Function app | func | 2-60 | All of Azure (same reason) |
| Deployment slot | none | 2-59 | Its app |
| App Service plan | asp | 1-60 | Resource group |
| App Service environment | ase | 2-36 | Resource group |
| Static web app | stapp | 2-60 | All of Azure |
Allowed characters for all of them: letters, numbers, and hyphens, and names can’t start or end with a hyphen.
The hostname is the name
Until you attach a custom domain, app-payments-prod-eus-001.azurewebsites.net is what users, webhooks, and API consumers see. Two consequences:
Global uniqueness. Someone else on Azure may already own app-api-prod-001. The region abbreviation and instance number in the CAF pattern add entropy; a short company prefix adds more.
The name leaks context. app-internal-hr-payroll-prod in a hostname tells the internet more than you might want. For public-facing apps, either put a custom domain in front early or keep the workload component neutral.
The CAF pattern
app-{workload}-{environment}-{region}-{instance}
func-{workload}-{environment}-{region}-{instance}
asp-{workload}-{environment}-{region}-{instance}
| Scenario | Name |
|---|---|
| Payments web app, production | app-payments-prod-eus-001 |
| Orders processing functions | func-orders-prod-eus-001 |
| Shared plan hosting both | asp-payments-prod-eus-001 |
| Dev copies | app-payments-dev-eus-001, func-orders-dev-eus-001 |
The plan is resource-group scoped, so the same plan name can exist in every environment’s resource group without conflict. Keep the full pattern anyway, it makes cost reports filterable by plan name.
Deployment slots
Slot hostnames are formed by appending the slot to the app name: app-payments-prod-eus-001-staging.azurewebsites.net. Two rules follow:
Keep slot names short. DNS labels cap at 63 characters, and the app name plus hyphen plus slot name form a single label. A 45-character app name with a 20-character slot name breaks the slot’s hostname. staging, stg, or canary are enough.
Don’t encode environment in slots. A slot named prod inside a dev app is a contradiction waiting for an incident. Slots are for deployment stages of one environment (staging, canary, warmup), not for separating dev from prod. Separate environments get separate apps.
The Functions host ID gotcha
This one is documented in a footnote and bites in production: when a function app starts, the runtime derives a host ID from the first 32 characters of the app name, and uses it to prefix blobs (locks, timers, keys) in the backing storage account.
If two function apps share a storage account and their names are identical in the first 32 characters, their host IDs collide and they silently overwrite each other’s coordination state, timers misfire, singleton functions double-run.
func-payments-orders-processing-prod-eus-001 and func-payments-orders-processing-dev-eus-001 differ only after character 32. Sharing a storage account between them is a live bug.
Mitigations, in order of preference:
- One storage account per function app (also the security best practice)
- Keep function app names unique within their first 32 characters
- Set an explicit
AzureFunctionsWebHost__hostIdapp setting per app
The storage account pairing
Every function app needs a storage account, and its name has the usual storage constraints (24 characters, lowercase, no hyphens). Derive it from the function app so the pair is obvious:
Function app: func-orders-prod-eus-001
Storage account: stfuncordersprodeus001
Terraform example
resource "azurerm_service_plan" "main" {
name = "asp-${var.workload}-${var.environment}-${var.region}-001"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
os_type = "Linux"
sku_name = "P1v3"
}
resource "azurerm_linux_web_app" "main" {
name = "app-${var.workload}-${var.environment}-${var.region}-001"
service_plan_id = azurerm_service_plan.main.id
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
site_config {}
}
resource "azurerm_linux_function_app" "orders" {
name = "func-orders-${var.environment}-${var.region}-001"
service_plan_id = azurerm_service_plan.main.id
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
storage_account_name = azurerm_storage_account.func.name
storage_account_access_key = azurerm_storage_account.func.primary_access_key
site_config {}
}
Common mistakes
Assuming the name is private. It’s a public hostname on day one. Check availability early, and treat the name as internet-visible.
Slot names that blow the DNS label. Long app name plus long slot name breaks the slot hostname at 63 characters.
Sharing storage accounts between long-named function apps. The 32-character host ID truncation turns a naming decision into a runtime bug.
Renaming later. Like most Azure resources, Microsoft.Web/sites can’t be renamed. The hostname you deploy with is the hostname you keep, or you redeploy.
Summary
- Web apps, function apps, and static web apps: 2 to 60 characters, globally unique, they become
azurewebsites.nethostnames - App Service plans: resource-group scoped, same CAF pattern, no entropy needed
- Slots: short names, single environment, watch the 63-character DNS label
- Function apps: unique first 32 characters or dedicated storage accounts
Full rules per resource: web app, function app, App Service plan. AzureNamer generates all of them, including the paired storage account name.
Keep reading
Azure VM Naming Conventions: Resource Name vs Computer Name
How to name Azure virtual machines with CAF: the 64-character resource name, the 15-character Windows computer name, VMSS prefixes, and Terraform/Bicep examples.
Read →Azure API Management Naming Conventions: Service, APIs, and Products
CAF naming for Azure API Management. The service is a globally unique azure-api.net endpoint (1 to 50 chars); APIs, products, backends, and named values inside are function-named. Patterns and examples.
Read →Azure Service Bus Naming Conventions: Namespaces, Queues, and Topics
CAF naming for Azure Service Bus. The namespace is a globally unique servicebus.windows.net endpoint (6 to 50 chars); queues, topics, and subscriptions inside are relaxed. Patterns and examples.
Read →Try AzureNamer
Generate CAF compliant names for all 200+ Azure resource types, free, no login required.
Open the Generator →