Publish an Azure Web App from JetBrains with a simple script

Sometimes I just want to publish an Azure Web App from JetBrains without setting up a full CI/CD pipeline first.

For production systems I still prefer a proper pipeline. But for small tools, prototypes, demos, internal apps, or quick customer examples, I often want something simpler. Build the project, package it, deploy it to Azure App Service, and move on.

That is why I shared a small repository with deploy scripts:

github.com/erwinbierens/azure-webapp-deploy-scripts

Why publish an Azure Web App from JetBrains this way

I use JetBrains Rider for a lot of .NET work. When I am already inside the IDE, it feels natural to run the deployment from there as well.

The scripts give me a repeatable local deploy flow:

publish.sh builds, packages, and deploys the app
status.sh shows the current Azure Web App status
logs.sh streams the live logs
restart.sh restarts the Web App

The main benefit is that I do not have to remember every Azure CLI command. I configure the app once, then run the same script every time.

How the deploy script works

The publish.sh script does a few practical checks before deploying:

It checks if the .NET SDK is available.
It checks if the Azure CLI is available.
It checks if you are logged in to Azure.
It selects the configured Azure subscription.
It finds the first .csproj file in the project.
It runs dotnet publish.
It creates a zip package.
It deploys the zip to Azure App Service.
It stores a copy of the deployed artifact in _deploy/artifacts.

That last part is useful. If something goes wrong later, you can still see what was deployed.

Add the scripts to your project

Clone or download the repository and copy the _deploy folder into the root of your .NET project.

Then copy the example config:

cp _deploy/deploy.conf.example _deploy/deploy.conf
chmod +x _deploy/*.sh

Open _deploy/deploy.conf and enter your Azure details:

APP_NAME="my-web-app"
RESOURCE_GROUP="my-resource-group"
SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
CONFIGURATION="Release"
OUTPUT="publish"
ZIP="app.zip"

The real deploy.conf file should stay local. Do not commit your own Azure values to Git.

Run it from JetBrains

In JetBrains Rider, I add the script as an External Tool.

Open:

Settings > Tools > External Tools

Add a new tool for publishing:

Name: Publish Azure Web App
Program: $ProjectFileDir$/_deploy/publish.sh
Working directory: $ProjectFileDir$

You can do the same for the helper scripts:

$ProjectFileDir$/_deploy/status.sh
$ProjectFileDir$/_deploy/logs.sh
$ProjectFileDir$/_deploy/restart.sh

After that, you can run the deploy from the JetBrains menu instead of switching to a terminal and typing the command manually.

Practical example

My usual flow looks like this:

Change the code in Rider.
Run the application locally.
Test the change.
Run Publish Azure Web App from External Tools.
Open the site when the script asks.
Use the log script when I want to quickly check startup or runtime output.

It is not fancy, but that is the point. For small projects this is often enough.

Tips and common mistakes

Make sure the Azure Web App already exists. These scripts deploy to an existing App Service, they do not create the Azure resources for you.

Run az login first if you use multiple tenants or accounts. The script can start the login flow, but I prefer to make sure I am in the right account before deploying.

Check the subscription value in deploy.conf. A wrong subscription is one of those small mistakes that can waste more time than the deployment itself.

Keep _deploy/deploy.conf out of Git. The example config belongs in the repository, your real config does not.

Use a pipeline when the deployment needs approvals, shared ownership, environment promotion, or a proper audit trail. This script is useful for fast local publishing, not as a replacement for mature release management.

End Note

This little setup works well for me when I need a fast and repeatable way to publish an Azure Web App from JetBrains. It keeps the deployment close to the project and removes a bit of friction from small .NET apps.

For serious production workloads, I still recommend GitHub Actions, Azure DevOps, or another proper CI/CD flow. But for demos, internal tools, and quick iterations, a simple script can be the right tool.