Stop using FTP for WordPress development. This guide breaks down three modern workflows, from simple Git setups to full CI/CD pipelines, to level up your freelance game and prevent production disasters.

From Cowboy Coder to Cloud Captain: A DevOps Take on Modern WordPress Workflows

I still remember the pager buzz at 2:17 AM. It was a Tuesday. A major e-commerce client’s site was down, throwing 500 errors right in the middle of a flash sale. The cause? A junior dev, trying to be helpful, had “quickly uploaded a fix” via FileZilla for a minor CSS bug. In the process, he overwrote a custom `functions.php` file with an old version from his laptop. No version control, no rollback plan, just pure panic. We lost an hour of sales and all trust in our deployment process. That night, I swore off FTP forever. If you’re a freelancer still dragging and dropping files, let’s have a talk.

The Root of the Problem: Why Your Old Workflow Is a Ticking Time Bomb

The “old way” of WordPress development—editing files locally, then uploading them via FTP—feels simple, but it’s fundamentally broken. The problem isn’t just about overwriting files; it’s about a complete lack of state management and repeatability.

• No Version History: You have no reliable record of what changed, when, or why. Rolling back is a guessing game.
• Code and Content Drift: Your local machine, a staging server (if you even have one), and the production server become three different versions of reality. The database on `prod-db-01` has new orders and user accounts, while your local copy is days old.
• It’s Error-Prone: Manual processes are where mistakes live. You forget to upload one file, upload to the wrong directory, or get interrupted mid-upload, leaving the site in a broken state.

Modern development isn’t about avoiding mistakes; it’s about making them safe and easy to fix. Your workflow should be a reliable, automated assembly line, not a delicate, manual art project.

Level 1: The ‘Better Than FTP’ Baseline

If you’re a solo freelancer and the idea of CI/CD pipelines makes you break out in a cold sweat, start here. This is the absolute minimum viable modern workflow. The goal is simple: get your theme and plugin code into Git.

The Core Idea: Your code lives in a Git repository (like GitHub or GitLab). The production server just pulls the latest changes from your main branch. It’s simple, but it’s a massive leap forward.

How it Works:

1. Initialize Git in your `wp-content/themes/your-theme` folder.
2. Push your code to a remote repository on GitHub.
3. On your server, you have two main options:
   • The Manual Pull: SSH into your server, navigate to the theme directory, and run git pull. It’s basic, but it’s version-controlled.
   • The Plugin-Assisted Pull: Use a plugin like WP Pusher. You connect it to your GitHub repo, and you can deploy new commits right from the WordPress admin dashboard.

For the database, you still need to sync it. A great tool for this is LocalWP which has easy pull/push features with some hosts, or the standalone plugin WP Migrate DB Pro. You periodically pull the production database down to your local environment to stay in sync. You rarely, if ever, push your local database up.

Pro Tip from the Trenches: Add your `wp-config.php` file and the `uploads` directory to your `.gitignore` immediately. You should never commit credentials, and you don’t want to bloat your repository with user-uploaded images.

Level 2: The Professional Git-Flow (CI/CD)

Okay, you’ve got the basics of Git. Now it’s time to automate it and make it bulletproof. This is how professional teams and agencies work. We introduce a staging environment and a CI/CD (Continuous Integration/Continuous Deployment) pipeline.

The Core Idea: You never push code directly to production. Every change is tested on a staging site first. The deployment itself is handled by an automated script that runs when you merge code into a specific Git branch.

A Typical Workflow:

1. Branching: You create a new branch for every feature or bugfix (e.g., `feature/contact-form-update`).
2. Develop Locally: You write and test your code on your machine.
3. Push to Staging: You merge your feature branch into a `staging` branch. This automatically triggers your pipeline.
4. Automation Runs: A service like GitHub Actions or Buddy.works picks up the change. It runs a script that logs into your staging server and deploys the code. It might also run build steps (like compiling SCSS or JavaScript).
5. Client Review: The client reviews the changes on the staging site.
6. Deploy to Production: Once approved, you merge the `staging` branch into `main`. This triggers the same automated process, but this time it targets the production server.

Here’s a dead-simple example of a GitHub Actions workflow file (`.github/workflows/deploy.yml`) that deploys via SSH and rsync:

name: Deploy Theme to Production

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Install SSH Key
      uses: shimataro/ssh-key-action@v2
      with:
        key: ${{ secrets.SERVER_SSH_KEY }}
        known_hosts: 'just-a-placeholder'

    - name: Deploy with rsync
      run: |
        rsync -avz -e "ssh -o StrictHostKeyChecking=no" \
        ./your-theme-folder/ \
        ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }}:/var/www/html/wp-content/themes/your-theme-folder/

Warning: The database is still the tricky part. For CI/CD, you typically use WP-CLI on the server. Your deployment script might run wp db upgrade or wp search-replace commands to handle database migrations and URL changes. This is an advanced topic, but it’s the key to fully automated deployments.

Level 3: The ‘It’s Not Me, It’s You’ Headless Approach

Sometimes, the problem isn’t your workflow—it’s WordPress itself. For certain projects, the traditional monolith architecture is a liability. That’s when we, as architects, decide to go “headless”.

The Core Idea: You use WordPress purely as a backend content management system (CMS), accessible only via its REST API or GraphQL. The frontend—what the user actually sees—is a completely separate application built with modern tools like Next.js, Nuxt, or SvelteKit.

Why Go Nuclear?

• Security: Your public-facing site is just static HTML, CSS, and JavaScript. The WordPress backend can be locked down, hidden from the public, and only accessible to content editors. No more PHP vulnerabilities on the frontend.
• Performance: Headless frontends are ridiculously fast. They can be deployed to global CDNs like Vercel or Netlify, giving users near-instant load times.
• Developer Experience: You get to leave the quirks of the WordPress theme layer behind and work with modern, component-based frameworks. It’s a joy.

This isn’t a solution for your average five-page brochure site. But if you’re building a web application, a media site that needs to scale, or a project where performance is non-negotiable, it’s time to consider decoupling. The deployment for the frontend is a simple `git push` to Vercel, and the WordPress backend becomes a boring, stable utility that you rarely have to touch.

Ultimately, the “best” workflow is the one that prevents you from getting a 2 AM emergency call. Start with Level 1 today. Your future self—and your clients—will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions