HTTPS clone URL
Subversion checkout URL
- Accessing files via ftp
- Accessing the kudu service
- Admin site
- Analyzing a git client trace
- Anatomy of a git request
- Azure runtime environment
- Azure Site Extensions
- Azure Web App sandbox
- Azure Web Sites Development Stacks
- Blog posts and screencasts
- Configurable settings
- Continuous deployment
- Cool user tweets
- Cool WebJobs tweets
- Custom Deployment Script
- Customizing deployments
- Deploy locally built private kudu to azure
- Deploying from github
- Deploying inplace and without repository
- Deploying Perl apps
- Deploying to a server
- Deployment branch
- Deployment credentials
- Deployment Environment
- Deployment hooks
- Deployment Logic Flow
- Deployment vs runtime issues
- Diagnostic Log Stream
- File structure on azure
- Getting started
- Git workflow
- Information about other Azure Web Apps features
- Investigating continuous deployment
- Investigating issues
- Investigating msdeploy ARM failures
- Known issues
- Kudu architecture
- Kudu console
- Kudu deployment configuration prototype
- Kudu deployment script .cmd
- Make sure all your files are committed
- Make sure site correctly deploys locally
- Managing settings and secrets
- Post Deployment Action Hooks
- Process list and minidump
- Process Threads list and minidump gcdump diagsession
- Project governance model
- Project Structure
- Reporting WebJobs issues
- Reporting your site name without posting it publicly
- REST API
- Running tests
- Troubleshooting Node errors
- Troubleshooting PHP errors
- Understanding site swaps
- Using a custom web.config for Node apps
- Using a git repo to report an issue
- Version history
- VSO vs Kudu deployments
- Web hooks
- Web Jobs
- WebJobs API
- Xdt transform samples
Clone this wiki locally
There are three different ways to publish files to an Azure Web App:
- git: the main topic of this wiki, and what the Kudu project is all about!
- Web Deploy (also known as MSDeploy)
When it comes to authenticating with these three mechanisms, you cannot use your Microsoft ID (aka Live ID) credentials (which the protocols can't easily support), but instead need to use deployment credentials.
To make things more interesting, there are actually two sets of deployment credentials that you can use to publish to a Website. This page discusses the two alternatives.
These are the credentials that you choose yourself in the Azure portal. If you're not sure what they are, you can reset them by going to the Dashboard tab for any site and clicking 'Reset deployment credentials' (under quick glance).
These credentials are directly tied to a Microsoft Account, and not to a particular web app. This needs to be emphasized, because the Azure portal UI is a bit confusing, as you need to go under a specific site on order to change them. But changing them under one site affects all of them!
Note that when an Azure subscription has multiple admins/co-admins, each person has their own set of credentials, since they each have a different Microsoft Account. The same is true for users that are given access to a Web App via RBAC (Role Based Access Control). In other words, user-level credentials are never meant to be shared among different users.
One key point about the user-level credentials is that since you specifically set them, they are meant to be memorized, and directly typed by the user when needed (e.g. when doing a git push).
These are the credentials that are automatically generated for each site. In order to see them, you need to download the 'publish profile', which you can do in the Dashboard tab of a site just above the 'Reset deployment credentials' link we discussed above.
The publish profile is an XML file that contains both WebDeploy and FTP related things. If you glance in there, you will easily locate the credentials. They look like:
- Username: if your site is named 'MyCoolSite', the user name will be '$MyCoolSite'
- Password: some long random string
Note that the multi co-admins scenario does not affect those credentials. All the admins/co-admins will end up with the exact same site-level credentials for a given site (but each site has different ones of course).
And unlike User lever credentials, the site-level credentials are definitely not meant to be memorized (though you're welcome to try!). Instead, they're meant to be used by programs that automates deployment for you (like Visual Studio).
Typically, you use the user-level credentials for git and FTP, and the site-level credentials for Web Deploy. However, you can use both sets of credentials for all three publishing techniques.
So why would you want to use the big random site-level credentials when doing a git push? Well, you wouldn't. However, there can be scenarios where a tool needs to do this on your behalf, and using the site-level credentials can make a lot of sense there.
Also, note that when it comes to credentials, everything that mentions git applies equally to all entry points provided by the Kudu service.
Whether you use user-level or site-level credentials, note that you need to prepend the site name to the username you use for FTP. So you'd have FTP full user names that look like this:
- With user-level credentials: MyCoolSite\davidebbo
- With site-level credentials: MyCoolSite\$MyCoolSite
See more details about accessing files via ftp.