App Services

app-services

app-services is the web-app triage command for Azure App Service posture, ingress, runtime, and identity cues.

Use it when you need to know which web apps deserve review before deeper config or deployment detail.

What This Command Answers

• Which App Service workloads matter first?
• Which apps combine reachability, identity, or weaker hardening in a way that matters now?
• Which web app should change what you inspect next?

Run It

azurefox app-services --output table

For saved structured output:

azurefox app-services --output json

Example Table Output

app service	hostname	runtime	identity	exposure	posture
app-empty-mi	app-empty-mi.azurewebsites.net	`DOTNETCORE	8.0`	SystemAssigned	hostname; public=Enabled
app-public-api	app-public-api.azurewebsites.net	`NODE	20-lts`	SystemAssigned	hostname; public=Enabled

When To Use It

• when App Service hosts customer-facing apps, internal portals, or automation surfaces
• when public reachability and managed identity matter more than generic config export
• when you need to rank web workloads before opening deeper settings or deployment paths

What To Look For

• externally reachable apps and public hostnames
• managed identity presence
• weaker hardening cues such as https_only=false or ftps_state=AllAllowed
• runtime and hostname context that makes one app operationally important

Why It Matters

App Service often sits at a high-value point between public reachability and Azure identity.

A public app with a managed identity, custom hostnames, or weaker web hardening can matter much more immediately than a quiet internal app. app-services helps you surface those workloads without turning into a raw app-setting dump.

What Should Stand Out First

• externally reachable apps first
• managed-identity-backed apps near the top
• weaker hardening cues easy to spot
• runtime and hostname context visible enough to recognize important app classes quickly

If You See..., Go Next To...

• If you see https_only=false, ftps_state=AllAllowed, or another weak web-hardening cue on a public app, go next to Endpoints because it surfaces the hostnames the analyst should validate first.
• If you see an app using managed identity, go next to Managed-Identities because it shows whether that web workload is also an Azure token path.
• If the app looks operationally important, go next to Env-Vars because it shows whether that same app also exposes secret-bearing configuration.

What To Do Next

• Start with the apps that combine exposure, identity, and weaker hardening.
• Treat App Service posture as the web-workload story, then pivot into config, identity, or ingress detail as needed.
• Use this command to decide whether the next question is about hostnames, Azure tokens, or secret-bearing settings.

Boundary

app-services is a web-workload triage command.

It should rank the App Service workloads that most deserve follow-up first. It is not a raw app-setting export, code-retrieval path, or generic deployment-history command.