Azure App Service for Beginners - Deploy Your .NET API to Azure

If you have ever built a .NET API and wondered "how do I get this running in the cloud without managing servers?", Azure App Service is the answer.

In this post we will walk through everything a beginner needs to know. We will create a simple .NET 8 Web API, deploy it, configure settings the right way, understand scaling, and see how App Service fits into a real architecture.

No fluff. Just practical steps.

1. What is Azure App Service?

Azure App Service is a fully managed platform for hosting web applications, REST APIs, and mobile backends.

The problem it solves

Normally if you host an API yourself you have to:

• Buy or rent a server
• Install the OS and runtime
• Configure IIS or Kestrel
• Handle OS updates and security patches
• Set up load balancing
• Worry about uptime

App Service removes all of that. You just deploy your code and Azure takes care of the rest.

App Service vs hosting on your own server

How a .NET 8 Web API fits in

Your .NET 8 Web API is just another web application. App Service runs it, gives it a public URL (something like https://my-api.azurewebsites.net), and keeps it online.

2. Create a Simple .NET API

Let's start with the absolute minimum.

Create a new .NET 8 Web API project and add this controller:

[ApiController]
[Route("api/[controller]")]
public class HelloController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok("Hello from Azure!");
    }
}

That's it. One endpoint that returns a simple message. Perfect for testing the deployment.

3. Deploy the API to App Service

The basic flow looks like this:

Visual Studio
     |
     | Publish
     ↓
Azure App Service
     |
     ↓
https://my-api.azurewebsites.net

Steps in Visual Studio

1. Right-click the project → Publish
2. Choose Azure → Azure App Service (Windows or Linux)
3. Sign in with your Azure account
4. Create a new App Service

When creating the App Service you will choose:

• Name: This becomes part of the URL (must be unique)
• Runtime stack: .NET 8
• Region: Choose the one closest to your users
• App Service Plan: This decides the size and cost of the compute resources

Click Publish. Visual Studio builds the project and deploys it.

Once it finishes, open the URL and call /api/hello. You should see:

Hello from Azure!

Congratulations. Your first API is live in Azure.

4. App Settings / Environment Variables

This is one of the most important things for .NET developers.

You should never hard-code production connection strings or secrets in your code or in appsettings.json that gets committed to Git.

Instead, store them in Azure.

Go to your App Service in the Azure portal:

App Service
   → Configuration
      → Application settings

Here you can add key-value pairs. These become environment variables for your app.

In your code you still write:

var connectionString = builder.Configuration.GetConnectionString("Default");

Azure automatically injects the values you configured in the portal. They override whatever is in your local appsettings.json.

This is the clean way to keep secrets out of source control.

5. Development vs Production Configuration

.NET configuration works in layers:

appsettings.json
appsettings.Development.json
+ Environment Variables (from Azure)
     ↓
IConfiguration

When you run locally, the Development settings are used.

When the app runs in Azure, the environment variables you set in App Service Configuration win.

Golden rule: Never put passwords, API keys, or real production connection strings in any file that goes into Git. Always put them in Azure App Settings (or better, Azure Key Vault later).

6. App Service Plan - The Part Beginners Usually Miss

This confuses almost everyone at first.

• App Service = your application (the website or API)
• App Service Plan = the underlying compute resources (CPU, memory, pricing)

Think of it like this:

App Service Plan
┌────────────────────┐
│ CPU / Memory       │
│ Pricing Tier       │
└────────────────────┘
      /          \
     /            \
    ↓              ↓
App Service API   App Service Web

One App Service Plan can host multiple App Services. This is useful when you want several apps to share the same resources (and cost).

The plan also controls how much you pay and how much power you get.

7. Scaling Basics

There are two ways to scale.

Scale Up
Make the machine bigger.

Small Plan
    ↓
Bigger Plan
    ↓
More CPU / Memory

You go from Basic to Standard to Premium, etc.

Scale Out
Add more instances of the same app.

       Load
        |
 +------+------+
 |             |
 ↓             ↓
Instance 1   Instance 2
 |             |
 +------+------+
        ↓
  App Service

Azure puts a load balancer in front of the instances. When many users hit your API at the same time, scale-out is usually the better option.

You can do both manually or set up auto-scaling rules.

8. Environment Variables in .NET

Azure App Settings support hierarchical keys using double underscores.

In the Azure portal you might set:

Database__ConnectionString = Server=...;Database=...;
ApiSettings__BaseUrl = https://api.example.com

In .NET you read them like this:

builder.Configuration["Database:ConnectionString"];
builder.Configuration["ApiSettings:BaseUrl"];

The double underscore __ is automatically mapped to the colon : that .NET configuration expects.

This is extremely useful for nested settings.

9. Logs and Troubleshooting

When something goes wrong, the first place to look is the logs.

In the Azure portal:

1. Go to your App Service
2. Click Log stream

You will see real-time application logs (anything written with ILogger).

Other useful places:

• Deployment Center → check if the latest deployment succeeded
• Restart button (sometimes a simple restart fixes weird issues)
• Diagnose and solve problems (Azure gives you automated suggestions)

For more advanced logging you can later enable Application Insights, but Log stream is perfect when you are just starting.

10. App Service vs Azure Functions

If you have already read about Azure Functions, here is a quick comparison:

Typical usage:

REST API  →  App Service

Service Bus Message  →  Azure Function

They complement each other very well.

11. Real-World Architecture

Here is how the pieces usually fit together:

Browser
   |
   ↓
.NET API
   |
   ↓
Azure App Service
   |
   +------------+------------+
   |                         |
   ↓                         ↓
Azure SQL               Blob Storage
   |
   ↓
Service Bus
   |
   ↓
Azure Function

• The user talks to your API (hosted on App Service)
• The API talks to Azure SQL and Blob Storage
• Heavy or long-running work is pushed to Service Bus
• An Azure Function picks up the message and does the background work

This way each service does what it is good at.

12. Final Takeaway

Azure App Service is the easiest way to host a .NET application in Azure without managing servers.

The simplest mental model is:

Your .NET API
     ↓
Azure App Service
     ↓
Azure manages the hosting
     ↓
You focus on your application

Start with a simple Hello World API, deploy it, play with App Settings, and then gradually add databases, queues, and functions.

Once you are comfortable with App Service, the rest of the Azure ecosystem becomes much easier to understand.

Happy deploying!