Skip to article
Web App Service deployment

FTP deployment

FTP deployment is an Azure App Service deployment method where application files are uploaded to a web app through FTP or FTPS publishing endpoints. Teams use it to support simple or legacy file-based releases when a full CI/CD pipeline, container image, or ZIP deployment flow is not available. In daily Azure work, it shows up when engineers publish static content, migrate an older web app, recover a small site, rotate deployment credentials, or disable basic publishing after modernization. It is not source control, a build pipeline, a secure secret-management strategy, or the preferred deployment method for regulated production systems.

Source: Microsoft Learn - Deploy content using FTP/S to Azure App Service Reviewed 2026-05-14

Exam trap
Treating FTP deployment as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
Production check
Verify the intended scope, owner tags, enabled state, identity, diagnostics, and linked resources before changing FTP deployment.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
FTPS deployment, App Service FTP deployment, FTP/S deployment
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-14
Learning paths Graph Web concept cluster FTP deployment
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

FTP deployment matters because it turns architecture intent into runtime behavior. When teams misunderstand it, they may change the wrong scope, grant access too broadly, overload capacity, hide a data exposure path, or chase an application bug that is really platform configuration. For this term, that means FTP can be convenient for small releases but dangerous when credentials are shared, stale, or allowed on apps that should use controlled deployment automation. It affects security, reliability, operations, cost, and performance because one choice can change how users, identities, traffic, data, deployments, or events behave. Review owner, scope, evidence, dependencies, and rollback before production change.

Official wording and source

An Azure App Service deployment method that uploads application files through FTP or FTPS using publishing credentials and the app deployment endpoint.

Open Microsoft Learn

Technical context

Technically, FTP deployment is configured through App Service publishing profiles, deployment credentials, FTP and FTPS endpoints, basic authentication settings, app files under site content, deployment logs, and platform access controls. Important settings include FTPS state, publishing username, deployment password, app name, resource group, deployment endpoint, allowed authentication method, SCM site access, deployment slot, and content path. Operators inspect it with publishing profile output, App Service deployment center settings, Activity Log entries, Kudu or deployment logs, file timestamps, FTPS configuration, and credential rotation records.

Exam context

Compare with

Local Git deployment GitHub Actions deployment

Where it is used

Where you see it

  1. A publishing profile contains FTP or FTPS endpoint details, deployment username, and generated credentials that allow file upload to an App Service app. Review owner, scope, evidence, dependencies, and rollback before production change.
  2. Deployment center or configuration settings show whether FTP basic authentication is allowed, whether FTPS is required, and which app or slot can receive files. Review owner, scope, evidence, dependencies, and rollback before production change.
  3. Kudu logs, file timestamps, or release notes show manual uploads where application files changed without a normal build pipeline or source-control release. Review owner, scope, evidence, dependencies, and rollback before production change.

Common situations

  • Design and document FTP deployment before a production release changes traffic, identity, data access, deployment, or runtime behavior.
  • Use FTP deployment during incident triage to narrow the affected scope and gather evidence before changing live settings.
  • Review FTP deployment during architecture, security, cost, performance, and reliability planning for the workload.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 FTP deployment in action for nonprofit website recovery Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BrightAid Foundation, a nonprofit organization, needed to restore a small public donation site after a failed manual content update from an outside vendor.

Goals
  • Recover the site within one business day
  • Require FTPS for uploads
  • Rotate publishing credentials
  • Plan migration to pipeline deployment
Approach using FTP deployment

The operations team used FTP deployment only as a controlled recovery method. Engineers retrieved the App Service publishing profile, required FtpsOnly mode, rotated deployment credentials, and uploaded a verified file manifest to the correct production slot. They compared file timestamps and Kudu logs after the upload, then disabled vendor access when the recovery was complete. A follow-up task moved the site toward ZIP deployment through Deployment Center so future releases would have source control, approvals, and repeatable rollback. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release.

Potential outcomes
  • Donation pages were restored in four hours
  • FTPS was enforced before upload
  • Vendor credentials were rotated the same day
  • A pipeline migration plan was approved
What to learn

FTP deployment can be useful for emergency or legacy releases, but it needs strict credential and evidence controls.

Scenario 02 FTP deployment in action for manufacturing partner content Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Contoso Fabrication, a manufacturing company, allowed a design partner to update static product sheets on an App Service site before a trade show.

Goals
  • Limit upload scope and time window
  • Avoid sharing Azure owner access
  • Capture proof of uploaded files
  • Remove manual access after the event
Approach using FTP deployment

The team used FTP deployment with short-lived publishing credentials and a documented file manifest. FTPS was required, the upload targeted a staging slot, and engineers verified the site before swapping. The partner never received Azure portal access. Operators saved publishing profile evidence, deployment logs, and file timestamps, then rotated credentials immediately after the release. Longer term, the same content moved to source control with an approval workflow because recurring FTP uploads were too hard to audit. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release.

Potential outcomes
  • Trade-show content launched on schedule
  • No Azure role assignment was granted to the partner
  • Credentials were rotated within one hour
  • Future releases moved to controlled automation
What to learn

FTP deployment is safest when it is temporary, scoped, logged, and replaced by normal deployment automation.

Scenario 03 FTP deployment in action for education legacy app migration Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Lakeview College, an education institution, needed to keep a legacy App Service app updated while a small team migrated it to GitHub Actions.

Goals
  • Maintain current student portal content
  • Reduce production deployment risk
  • Document manual upload evidence
  • Disable FTP after modernization
Approach using FTP deployment

The team used FTP deployment as a bridge, not a target state. They enforced FTPS, documented who owned the publishing credentials, and required a preapproved package with a checksum before every upload. App settings and logs were captured before the change, and support tested the portal after files landed. When GitHub Actions deployment succeeded for the same app, operators disabled FTP publishing access and updated the runbook so future releases used source control and deployment history instead of manual file transfer. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.

Potential outcomes
  • Student portal updates continued during migration
  • Manual uploads dropped from weekly to zero
  • Deployment evidence became searchable
  • FTP access was disabled after pipeline cutover
What to learn

FTP deployment should be treated as a legacy convenience that needs controls and a modernization exit path.

Azure CLI

CLI checks make FTP deployment review repeatable because they capture scoped evidence for configuration, ownership, dependencies, health, and change impact before operators modify production.

Useful for

  • List or show the Azure resources related to FTP deployment before selecting a target for deeper review.
  • Capture read-only evidence for FTP deployment during release approval, incident response, access review, or cost investigation.
  • Compare configuration, metrics, logs, and dependent resources for FTP deployment across environments before approving a mutating command.

Before you run a command

  • Confirm tenant, subscription, resource group, application, profile, account, endpoint, or deployment scope before trusting command output.
  • Run list and show commands first, then save evidence before create, update, restart, delete, purge, scale, or access changes.
  • Check whether the command affects customer traffic, credentials, cached content, model behavior, data access, cost, or compliance evidence.

What the output tells you

  • Names, resource IDs, locations, SKUs, enabled states, and parent relationships show whether you are inspecting the intended target.
  • Settings, identities, routes, deployments, indexes, endpoints, origins, or app settings explain how requests and workloads behave today.
  • Timestamps, metrics, usage, health state, and logs help separate Azure configuration issues from application or downstream failures.

Mapped commands

FTP deployment operational checks

direct 
az webapp deployment list-publishing-profiles --name <app-name> --resource-group <resource-group>
az webapp deploymentdiscoverWeb
sensitive-read Microsoft Learn 
az webapp config show --name <app-name> --resource-group <resource-group>
az webapp configdiscoverWeb
read-only Microsoft Learn 
az webapp config set --name <app-name> --resource-group <resource-group> --ftps-state FtpsOnly
az webapp configconfigureWeb
mutating Microsoft Learn 
az webapp deployment user set --user-name <deployment-user> --password <password>
az webapp deployment usersecureWeb
sensitive-mutating Microsoft Learn

Architecture context

Technically, FTP deployment is configured through App Service publishing profiles, deployment credentials, FTP and FTPS endpoints, basic authentication settings, app files under site content, deployment logs, and platform access controls. Important settings include FTPS state, publishing username, deployment password, app name, resource group, deployment endpoint, allowed authentication method, SCM site access, deployment slot, and content path. Operators inspect it with publishing profile output, App Service deployment center settings, Activity Log entries, Kudu or deployment logs, file timestamps, FTPS configuration, and credential rotation records.

Security
Security for FTP deployment starts with publishing credentials, FTPS enforcement, basic authentication, credential rotation, role access to publishing profiles, SCM exposure, deployment slots, and whether FTP is disabled when unused. Review who can create, update, delete, execute, read logs, approve dependencies, and manage credentials or identities. Prefer Microsoft Entra ID, managed identity, private networking, least privilege, and audited automation where the service supports them. Keep secrets out of code and avoid broad public exposure unless there is a documented exception. Capture role assignments, diagnostic settings, policy decisions, Activity Log entries, and owner approvals so access and data handling are intentional and reviewable.
Cost
Cost for FTP deployment is driven by support effort from manual releases, downtime during bad uploads, monitoring logs, duplicate environments, stale apps kept for FTP access, and time spent reconciling files with source control. The expensive mistake is not only Azure consumption; it can also be duplicate experiments, emergency support, overprovisioned capacity, unnecessary data transfer, or cleanup after weak design evidence. Review whether the workload truly needs the selected tier, retention, diagnostics, network path, scale rule, cache behavior, or automation pattern. Use tags, budgets, alerts, and cleanup reviews so teams can explain why the design exists and remove stale resources safely.
Reliability
Reliability for FTP deployment depends on partial uploads, file locks, deployment timing, slot selection, restart behavior, missing build steps, overwritten files, rollback copies, and differences between deployed files and source control. A resource can be present and still fail the business workflow if routing, identity, quota, storage, code, cache, scale, or downstream health is wrong. Test failure modes, retries, deployment behavior, disabled states, rollback steps, and maintenance windows before relying on the design. During incidents, compare platform metrics, logs, deployment history, and application traces from the same time window before changing production. The goal is a recoverable configuration support teams can verify quickly.
Performance
Performance for FTP deployment depends on upload size, network stability, file count, app restart behavior, runtime warmup, static content caching, deployment slot usage, and whether partial changes leave the app serving mixed versions. Measure platform metrics and application-side completion times because a fast control-plane response does not prove users received the right result. Test with realistic regions, data sizes, concurrency, authentication paths, route choices, cache state, package size, and downstream limits. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one service. Tune with evidence from the exact environment and traffic pattern.
Operations
Operations for FTP deployment require credential ownership, upload evidence, deployment windows, file manifests, logs, slot awareness, rollback packages, FTP disablement checks, and migration plans to ZIP or pipeline deployment. Before a change, capture read-only CLI output, portal evidence when useful, owner tags, expected behavior, and rollback steps. During incidents, avoid changing several settings at once; compare metrics, logs, deployment operations, identity evidence, network state, and downstream health first. Keep runbooks clear enough for support teams to verify current behavior quickly. Good operations make the term observable, reviewable, and recoverable during releases, audits, and incidents. Review owner, scope, evidence, dependencies, and rollback before production change.

Common mistakes

  • Treating FTP deployment as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
  • Running a mutating command for FTP deployment in the wrong subscription, resource group, app, profile, route, or account context.
  • Assuming successful deployment proves FTP deployment works without checking logs, metrics, user behavior, and rollback evidence.