Module 6: Bring Your Own App | AZD for Beginners

"Templates are great, but you already have an app. Here's how to add azd to your project and deploy it."

Level: Beginner · Time: ~2 days · Prerequisites: Module 5

Learning Objectives

By the end of this module, you will be able to:

Add azd to an existing application
Generate infrastructure for your own app
Structure a project so azd can deploy it
Know what azd needs to work with your code

1. Starting from Your Own Code

You don't have to begin from a template. Inside your existing project folder, run:

bash

azd init

and choose "Use code in the current directory." azd scans your project, detects the languages and frameworks, and offers to generate the pieces it needs — an azure.yaml and starter infrastructure. This is the same azd init you'd use for a template, just pointed at code you already have. It won't move or rewrite your source; it adds files alongside it, so your project keeps working exactly as before.

Concept: azd meets you where you are. Whether it's a Flask API, a React frontend, or a .NET service, azd can wrap your existing code with the config and infrastructure to ship it.

2. What azd Detects

During init, azd looks for signals about your app: a requirements.txt (Python), package.json (Node), a Dockerfile, and so on. From these it guesses each service's language and a sensible host, then writes them into azure.yaml for you to confirm or adjust.

If azd guesses wrong — say it picks App Service but you wanted Container Apps — you just edit the host line in azure.yaml. Detection is a helpful starting draft, not a final decision.

Explain like I'm new: It's like a tailor sizing you up at a glance. azd looks at your project's telltale files and drafts a fitting deployment plan, which you then tweak to taste.

3. Generating Infrastructure

azd can scaffold the Bicep infrastructure your app needs — a Container App or App Service to run it, plus supporting resources. You get working IaC without writing it from scratch, which you can then customize (Module 7).

text

your-app/
├── azure.yaml          ← added by azd
├── infra/              ← generated Bicep
│   ├── main.bicep
│   └── main.parameters.json
└── src/                ← your existing code

Here main.bicep wires the resources together, while main.parameters.json holds the per-deployment values (like region or name). You can deploy the generated infrastructure exactly as it is and refine it later.

Try this: Look at the generated infra/ folder after init. Even if Bicep is new to you, skim main.bicep — it's a readable list of the Azure resources your app will get.

4. Making Your App Deploy-Ready

A few habits make your app play nicely with azd:

Read config from environment variables (not hard-coded values), so azd can inject Azure settings.
Listen on the port the host provides (often via an env var).
Include a Dockerfile if you want container-based hosting.
Log to stdout/stderr, not to files, so the platform can collect your logs.

These conventions come straight from the twelve-factor app methodology, and following them keeps the same build portable across any host.

Common mistake: Hard-coding a database URL or API key in your code. Cloud hosts supply these as environment variables — read them from the environment so the same code works locally and on Azure.

5. From Local to Live

Once azure.yaml and infra/ exist, deploying your own app is the same as any template:

bash

azd up

Your existing project is now provisioned and running on Azure, and every future change is one azd deploy away.

Real-world use case: A developer has a working Flask app on their laptop. Fifteen minutes with azd init and azd up later, it's live on Azure Container Apps with real infrastructure — no rewrite, just wrapped with azd.

✅ Checkpoint

How do you start azd from your own existing code?
What files does azd look at to detect your app's languages?
Why should your app read config from environment variables?

Answers: 1) Run azd init and choose "Use code in the current directory." 2) Signals like requirements.txt, package.json, or a Dockerfile. 3) So the host can inject Azure settings (like connection strings) without changing code.

Key Takeaway: You don't need a template — azd init on your existing project detects your languages, generates an azure.yaml and starter Bicep infrastructure, and gets you to azd up. Make your app deploy-ready by reading config from environment variables, listening on the provided port, and including a Dockerfile for container hosting. Then your own app deploys just like any template.

Further Learning

Part of "AZD for Beginners." Adapted from Microsoft's open AZD curriculum (MIT License).