Last updated on 2nd October 2026

Configuring an Azure App Service server over FTPS

Azure App Service exposes an FTPS endpoint for deployments, and DeployHQ connects to it over FTPS. The connection details come from your app's Deployment Center in the Azure portal.

There are three Azure specifics that catch most people out, so we will call them out up front:

  • Set the TLS version to Auto-negotiate. Azure's FTP service refuses TLS 1.0 and does not support TLS 1.3. The Default option in our TLS version dropdown connects using TLS 1.0 only, so leaving it on Default means the connection can never succeed. Auto-negotiate settles on TLS 1.2, which Azure accepts.
  • Enable both Basic authentication settings on the app. Azure requires both SCM Basic Auth Publishing Credentials and FTP Basic Auth Publishing Credentials to be enabled for FTPS deployment. These are switched off by default on newer App Service apps, and while either one is off the FTPS login is rejected even though the encrypted connection itself is fine.
  • The username contains a $. Azure's application-scope username has the form <app-name>\$<app-name>. Copy it exactly as the portal shows it.

Get your FTPS details from Azure

  1. In the Azure portal, open your App Service app and go to Deployment > Deployment Center.
  2. Open the FTPS credentials tab.
  3. Make sure both SCM Basic Auth Publishing Credentials and FTP Basic Auth Publishing Credentials are enabled for the app. Azure requires both for FTPS deployment — if either is disabled, FTPS logins are refused and the FTPS credentials are hidden in the Deployment Center entirely. You may need to enable them under Configuration > General settings, or ask whoever administers the subscription, as some organisations disable basic authentication by policy.
  4. Note the FTPS endpoint, the username and the password. The endpoint looks like ftps://waws-prod-xxx-nnn.ftp.azurewebsites.windows.net/site/wwwroot.

Use the FTPS publishing password shown here, not your Azure portal login.

Add the server in DeployHQ

  1. In your project, go to Servers & Groups and click New Server.
  2. Enter a name for the server and select FTPS as the protocol.
  3. Fill in the Server Details:
    • Hostname: the host part of the FTPS endpoint only, for example waws-prod-xxx-nnn.ftp.azurewebsites.windows.net. Leave off the ftps:// prefix and the path.
    • Port: 21 for explicit FTPS, or 990 for implicit. Both work, but the port must match the Use implicit TLS/SSL mode? setting below — port 990 with implicit mode ticked, or port 21 with it unticked.
    • Username: the Azure username, for example my-app\$my-app
    • Password: the FTPS publishing password from the Deployment Center
  4. Set the Deployment path to the directory you want to deploy into, for example /site/wwwroot for the whole app, or /site/wwwroot/wp-content/themes/your-theme for a single WordPress theme.
  5. Under Advanced Options:
    • Set the TLS version to Auto-negotiate.
    • Tick Use implicit TLS/SSL mode? only if you set the port to 990. For port 21, leave it unticked. Mixing the two is a common cause of connection failures.
    • Tick Use passive (PASV) mode?.
  6. Click Create Server.

DeployHQ runs a connection test when you save. If the test fails, the server is not saved, so you will land back on the form with the error.

Uploads larger than 1 MB arriving corrupted

Azure App Service's FTP service can misinterpret the TLS shutdown message at the end of a transfer as file data, which appends around 41 bytes of binary junk to uploaded files over roughly 1 MB. If you see corrupted files after a deployment, tick Skip TLS close notification? under Advanced Options on this server.

Only enable this for Azure servers. Some other FTPS servers require a proper TLS shutdown and will fail with transfer errors if it is skipped, which is why the option is off by default.

Troubleshooting

  • SSL_connect SYSCALL returned=5 or another TLS/SSL error during the connection test: the TLS version is the usual cause. Set it to Auto-negotiate. Both Default (TLS 1.0 only) and TLS 1.3 fail against Azure's FTP service.
  • The connection test fails after the TLS handshake, at the login step: check that both SCM and FTP Basic Auth Publishing Credentials are enabled on the app, and that you are using the FTPS publishing password from the Deployment Center rather than your Azure portal login. If you cannot see FTPS credentials in the Deployment Center at all, basic authentication is disabled. See FTPS authentication errors.
  • The connection fails with the port and mode mismatched: the Use implicit TLS/SSL mode? setting decides how the connection starts, not the port. With it ticked, DeployHQ begins the TLS handshake immediately; with it unticked, it connects in plain text and then upgrades with AUTH TLS. Azure expects the immediate handshake on port 990 and the plain-text start on port 21, so ticking implicit mode while using port 21 fails — often with a "wrong version number" TLS error, because the handshake meets a plain-text FTP greeting.
  • "Server did not respond within 45 seconds": check the hostname and port. Azure App Service does not offer SSH on port 22 at this address, so an SSH/SFTP server pointed at it will time out. See Server did not respond.
  • "Server could not be written to": confirm the deployment path exists under /site/wwwroot. See Server could not be written to.
  • Files deploy but the site does not change: check that the deployment path points at the directory the app actually serves. Azure serves from /site/wwwroot by default.

Run your first deployment

Your first deployment uploads the whole repository. If your files are already up to date on Azure, you can skip the first deployment. After that, DeployHQ only uploads the files that have changed.