How to Host a Website on Azure (App Service, Step by Step)

The fastest correct way to put a web app on Azure is one command from your project folder. The slow way is clicking through the portal without knowing which of four hosting services you actually needed. Here is the fork, the walk-through, and the bill.

New to cloud? CAMPUX is a free, build-first course. Start here →

The 30-second answer: az webapp up and you're live

To host a website on Azure App Service, open a terminal in your project folder and run az webapp up --name my-site --sku B1 --runtime "NODE:20-lts". That one command creates the resource group, the App Service plan, and the web app, then zips and deploys your code. In a couple of minutes your site answers at https://my-site.azurewebsites.net with HTTPS already on. Everything below is context for that line — which tier to pass, what it costs, and how to put your own domain in front of it.

I use az webapp up for the first deploy because it collapses five portal screens into one command and remembers your choices for next time. Pass --sku explicitly, though; the defaults it picks and saves per folder are easy to forget, and you don't want to discover you're on a tier you didn't mean to pay for. Run it a second time after a code change and it redeploys to the same app.

Which Azure hosting service fits your site

Before you type any command, answer one question: does your site run server-side code on each request? A Node or Django or .NET app that talks to a database does. A folder of HTML, CSS, and JavaScript — a React build, a Hugo site, a landing page — does not. That single distinction sends you down two very different, very differently priced paths.

If your site is a pile of static files, App Service is the wrong tool; you'll pay for a plan you don't need. Use Azure Static Web Apps or a Blob storage static site instead, both of which are far cheaper or free. If your site runs a server process, App Service is the boring, correct answer, and the rest of this note is for you. Here is the whole matrix on one screen.

Step by step: deploy a web app with App Service

You have two front doors — the portal and the CLI. The portal is fine for a look; the CLI is what you'll actually use once the novelty wears off. I'll give you both.

The CLI path (what I reach for)

Install the Azure CLI, sign in, then run one command from your project directory. This example is a Node app on the Basic tier, in a resource group the command creates for you:

az login

az webapp up --name campux-demo --resource-group rg-demo --location eastus --sku B1 --runtime "NODE:20-lts"

Swap the runtime for your stack — PYTHON:3.12, DOTNETCORE:8.0, PHP:8.3, and so on; run az webapp list-runtimes to see the current strings. The command zips your working directory, uploads it, and prints the live URL when it finishes. Deploy a change later by running az webapp up again from the same folder — it reuses the saved settings and pushes the new code.

Want to test for free first? Pass --sku F1 instead of B1. Just know the Free tier can't hold a custom domain, so treat it as a proving ground and plan to move up before launch.

The portal path (for the first time)

1. In the Azure portal, choose Create a resource → Web App.
2. Pick a resource group, a globally unique name, your runtime stack, and an OS (Linux is the cheaper default for most stacks).
3. Under Pricing plan, create a new App Service plan and pick a tier — F1 to kick the tires, B1 for a small live site.
4. Review and create; wait for the deployment to finish.
5. Open the app, go to the Deployment Center, and connect GitHub so every push to your main branch ships automatically.

The Deployment Center wiring is the part worth doing on day one. Once GitHub Actions is connected, you stop deploying by hand and your repo becomes the source of truth. That's the difference between a demo and something you can hand to a team.

Your site is live the moment the deploy finishes — on Azure's hostname, with HTTPS. The custom domain is a later, optional errand, not a blocker.

Add a custom domain and free HTTPS

Your app answers at your-app.azurewebsites.net straight away, and that URL already has TLS. To put your own name in front of it, you need two things: a paid tier and a couple of DNS records. The Free tier does not support custom domains at all, so this step is where F1 users hit the wall.

On Basic (B1) or higher, the flow is short:

• In the app's Custom domains blade, add your domain and copy the verification values Azure shows you.
• At your DNS provider, add the TXT record to prove ownership and a CNAME (or A record for an apex domain) pointing at the app.
• Back in Azure, validate and add the binding.
• Create a free App Service managed certificate for that domain and bind it. Azure issues and auto-renews it at no cost, so you never touch a certificate file.

The managed certificate is the quiet win here: free TLS on your own domain, renewed automatically, available on Basic and up. I walk through the whole DNS-and-cert dance in the custom-domain field note if you want the record-by-record version.

What it actually costs per month (F1 / B1 / S1)

Pricing shifts by region and over time, so treat these as shape, not gospel — open the App Service pricing page for your region before you commit real money. The useful part is the relative jump between tiers and what each one buys you.

• F1 (Free) — no cost, shared compute, roughly 60 CPU-minutes of quota per day and about 1 GB of storage. No custom domain, no Always On, no slots. A sandbox, not a home.
• B1 (Basic) — the low tens of dollars a month, billed per hour, dedicated compute, custom domain and managed TLS, Always On. This is the honest floor for a small production site.
• S1 (Standard) — more per month, and worth it when you want autoscale, up to five deployment slots for zero-downtime swaps, and daily backups. This is the tier where releases stop being scary.

One billing detail people miss: you pay for the App Service plan, not per app. Because the plan is the compute, several apps can share one B1 plan and one bill. Scaling the plan scales every app on it at once — cheap when you mean it, a surprise when you don't. For the full mental model, see what Azure App Service is.

The gap nobody mentions: cold starts, Always On, and the Free tier's real limits

Here is what the listicles skip. On the Free and Basic tiers, an app that sits idle gets unloaded, and the next visitor pays for the reload — a cold start of several seconds while your runtime spins back up. On a portfolio site nobody notices. On something a recruiter clicks once, that first slow load is the impression you make.

The fix is Always On, a setting that keeps your app warm by pinging it. It lives on Basic and above; the Free tier can't turn it on, which is the real reason F1 feels sluggish. If your site needs to answer fast on the first hit, that alone is the argument for B1 over F1 — a few dollars a month to delete cold starts.

And the Free tier's ceiling is a hard one, not a soft nudge. Burn through the daily CPU quota and Azure stops serving your app until the clock resets — a 24-hour quota measured across the day, easy to hit if anything hammers the site. Combined with no custom domain and no Always On, F1 is genuinely a testing tier. Prove your deploy on it, then move to B1 the day you want anyone real to see the site. Nobody tells you that until the app goes dark mid-afternoon; now someone has.

Questions people also ask

Can I host a website on Azure for free?

Yes, on the App Service Free (F1) tier, which is meant for development and testing. As of 2026 it gives you shared compute with roughly 60 CPU-minutes of quota per day and about 1 GB of storage, and no Always On. The catch is that F1 does not support a custom domain or a managed TLS certificate, so free hosting only gets you the *.azurewebsites.net URL. For a real domain you move to a paid tier.

How much does it cost to host a website on Azure?

Free on the F1 tier for testing, or roughly the low tens of dollars a month for a small production site on the Basic (B1) tier, billed per hour. Standard (S1) costs more but adds autoscale, deployment slots, and daily backups. Prices vary by region and change over time, so check the App Service pricing page for your region before you commit.

What is the difference between Azure App Service and Static Web Apps?

App Service runs server-side code — .NET, Node, Python, PHP, Java, or a container — on a plan you pay for by the hour. Static Web Apps serves pre-built HTML, CSS, and JavaScript from a global edge, with optional serverless API functions, and has a genuinely free tier that includes a custom domain and HTTPS. If your site has no server process, Static Web Apps is cheaper and simpler; if you run a back end, use App Service.

Can I host a WordPress site on Azure App Service?

Yes. Azure offers a WordPress on App Service option that provisions the container plus a managed MySQL flexible server for you. Because WordPress runs PHP and needs a database, plan on at least a Basic or Standard tier rather than the Free tier, and budget for the database as a separate line item on your bill.

Do I need a custom domain to publish on Azure?

No. Every App Service app gets a free *.azurewebsites.net hostname with HTTPS the moment you deploy, so your site is live and reachable immediately. A custom domain is optional and only needed when you want your own name in the address bar; adding one requires a paid tier and a couple of DNS records.