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](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-did-not-respond).
- **"Server could not be written to"**: confirm the deployment path exists under `/site/wwwroot`. See [Server could not be written to](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.