Deploying from a zip file or url

To deploy the content of a zip file or URL to your site.

Using curl:

curl -X POST -u <user> https://{sitename}.scm.azurewebsites.net/api/zipdeploy -T <zipfile> 

curl -X PUT -u <user> https://{sitename}.scm.azurewebsites.net/api/zipdeploy -H "Content-Type: application/json" -d "{'packageUri':'<zipUrl>'}"

zipdeploy is intended for fast and easy deployments from development environments, as well as deployment of ready-to-run sites built by continuous integration services such as Visual Studio Team Services. Unlike other Kudu deployment mechanisms, Kudu assumes by default that deployments from zip files are ready to run and do not require additional build steps during deployment, such as npm install or dotnet restore/dotnet publish. This can be overridden by setting the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting to true, or by specifying custom script generator arguments or a custom deployment script.

Asynchronous zip deployment

Add ?isAsync=true to the URL to deploy asynchronously. You will receive a response as soon as the zip file is uploaded with a Location header pointing to the pollable deployment status URL.

Comparison with zip API

Kudu's zip API is an effective way to move multiple files to your site, but zipdeploy is preferable for deployments for a number of reasons:

• Deletion of files no longer in the build: When a new build is deployed with zipdeploy, files and directories that were created by the previous deployment(made via zipDeploy) but are no longer present in the build will be deleted. Any other files and directories found in the site that aren't being overwritten by the deployment, such as those placed there via FTP or created by your app during runtime, will be preserved. e.g. a previous folder 'BackupLogs' created from an FTP upload or manual creation would be preserved even if the zip doesn't contain this folder.
• Efficient file copy: Files will only be copied if their timestamps don't match what is already deployed. Generating a zip using a build process that caches outputs can result in faster deployments.
• Function trigger sync: If you are running Functions on a Consumption plan, modifying their triggers requires a synchronization process that doesn't occur when using the zip API or other file-based deployment methods like FTP. Zipdeploy will perform this synchronization for you.
• Logging, status tracking and history: zipdeploy generates live status, deployment logs and recorded history in Kudu's deployment API. However, zip deployments cannot be redeployed.
• Async support: By adding ?isAsync=true to the URL, the deployment will run asynchronously. The Location header of the response will contain the deployment URL that can be polled for deployment status. Webhooks can be used for fully asynchronous notification of completion.
• Customizable deployment: Deployment-related settings will be respected, including app settings and values in a .deployment file.
• Build support: By default, zipdeploy assumes that the zip contains a ready-to-run site, but Kudu's built-in build process can be re-enabled via the SCM_DO_BUILD_DURING_DEPLOYMENT deployment setting.
• Safe deployment: zipdeploy engages Kudu's deployment locks, preventing multiple simultaneous deployments from clobbering your site.
• Auto Swap and container restart support: A zip deployment will trigger an Auto Swap if your site is configured for it. On App Service on Linux, zip deployment will trigger a restart of the app container.

Issues and investigation

• Zip deploy does not update node module files for NPM 5.6 and later

See https://github.com/projectkudu/kudu/issues/2917 and https://github.com/npm/npm/issues/20439. This affects the default zipdeploy behavior where it is optimized to only copy files that are changed. To workaround the issue, do set appSettings SCM_ZIPDEPLOY_DONOT_PRESERVE_FILETIME=1. Zipdeploy files will always be updated and, as a result, overwriting the existing ones regardless of change.