FTP still shows up in WordPress workflows like a fax machine at a startup. Drag files in FileZilla, overwrite production, hope you grabbed the right folder. Git deploy sounds grown-up: push to main, pipeline runs, site updates.
Both can work. Both can wreck a Friday. The right choice depends on who deploys, what you are changing, and whether you have staging in the middle.
What FTP/SFTP is good at
Direct file copy to the server. No build step. Fine for:
- One-off hotfixes on a small site when Git is not set up
- Agencies downloading a theme tweak from a client who only has cPanel
- Emergency rollback (upload yesterday's zip) when everything else failed
Problems pile up when FTP is the default deploy path:
- No record of who changed what file
- Easy to overwrite uploads or wp-config by accident
- Partial uploads leave the site half-updated
- Credentials shared across contractors
- Plugins and media mixed with code in one blind sync
If you use SFTP, use SSH keys where possible, least-privilege accounts, and never store passwords in email threads.
What Git deploy is good at
Version history, branches, pull requests, and repeatable deploys. Typical flow: developers commit to a repo, CI or a hook pulls to staging, tests pass, then production gets the same commit hash.
Wins:
- Rollback is "deploy previous commit," not guess which FTP backup
- Code review before production
- Same process for every developer
- Works well with custom themes and plugins you actually own in Git
Git deploy does not magically deploy WordPress core or database content. You still need a strategy for plugins (Composer, WPackagist, manual updates), uploads (usually not in Git), and wp-config secrets (env vars, not committed).
WordPress-specific reality check
Custom theme/plugin in Git: Git deploy shines. Exclude wp-content/uploads, cache folders, and vendor noise via .gitignore.
Page builder site with everything in the database: Deploying PHP files via Git does not move Elementor layouts. You still export/import or use staging DB sync.
Plugin updates from wp-admin: Neither Git nor FTP replaces clicking update unless you automate with Composer or WP-CLI in your pipeline.
Read plugin updates without breaking production before you automate blindly.
Common Git deploy patterns on Canadian hosting
Git pull on server via SSH hook: Simple VPS setups. Post-receive hook runs git pull into the web root. Fast to set up. Requires discipline about branch and permissions.
CI/CD (GitHub Actions, GitLab CI): Build artifact, rsync or SFTP to host, or deploy to container. Better audit trail. Needs secrets management.
Managed WordPress Git tools: Some hosts offer Git integration in panel. Read whether production auto-pulls on every push (scary) or deploy is a button (better).
Bedrock/Trellis-style structure: Composer-managed WordPress for teams who treat WP like an app. More setup, cleaner long term for agencies with many builds.
When FTP is still the honest answer
Legacy client on shared hosting with no SSH. Tiny budget. One developer who touches the site twice a year. Forcing Git pipeline cost on that client may not pay off. Use SFTP carefully, backup first, document the steps.
When FTP is temporary, say so in the README. "We FTP hotfixes until migration in Q2" beats pretending Git exists.
Security comparison (brief)
FTP plain text is unacceptable in 2026. Use SFTP or SSH. Rotate credentials when contractors leave.
Git deploy reduces shared FTP passwords but introduces deploy keys and CI secrets. Protect those like production passwords. MFA on GitHub/GitLab orgs. No deploy keys with write access to everything if read-only pull suffices.
Hybrid workflow many agencies use
- Custom code in Git, deployed via CI to staging then production
- Plugin updates tested on staging, then applied on production via WP-CLI or controlled admin updates
- Media stays on server or syncs via migration tools, not Git
- FTP/SFTP reserved for rescue missions only
Bottom line
Git deploy beats FTP for teams shipping custom WordPress code on a schedule. FTP/SFTP remains a backup tool for emergencies and legacy hosts, not a strategy. Match the workflow to what actually changes on the site (files vs database vs plugins) and always stage before production.
Want Git-friendly hosting or a sane deploy path on Canadian infrastructure? Talk with Swift Host. We will help you pick SSH, staging, and automation that fits your team size.
