Automating WordPress Deployment with Bitbucket: Dev & Live Environments Made Easy

Managing a WordPress project across multiple environments—especially when working with a team—can become complex and error-prone. That’s why automating deployment using Bitbucket, and integrating a workflow for Dev and Live servers, can save hours of manual work and reduce risk.

In this blog post, we’ll walk you through a complete setup of automated WordPress deployment using Bitbucket for two environments: Dev and Live, with the goal of:

• Automatically deploying code to the Dev server after pushing to a development branch.
• Automatically deploying to the Live server after merging into the main or live branch.
• Ensuring database safety, security, and version control.

🧩 Technologies Used

• Bitbucket (Git repository and pipelines)
• Bitbucket Pipelines (CI/CD)
• Dev Server (e.g., a subdomain like dev.example.com)
• Live Server (production site like example.com)
• FTP or SCP for deployment (can be SFTP, or use SSH with rsync)
• WordPress Toolkit on cPanel (optional)
• .env / wp-config.php customization for environment separation

🗂️ Repository Structure

Before starting, make sure your WordPress project is in a Git-friendly structure. Recommended setup:

/my-wordpress-project
├── wp-content/
│   ├── themes/
│   └── plugins/
├── .env
├── wp-config.php
├── bitbucket-pipelines.yml        

Avoid committing core WordPress files unless you're managing it as a full Git repo. Ideally, version-control only wp-content, custom plugins, and themes.

🔄 Git Branching Strategy

A clean branching strategy is crucial:

🛠️ Step-by-Step Setup

Step 1: Enable Bitbucket Pipelines

1. Go to your Bitbucket repo.
2. Click on Pipelines → Enable Pipelines.
3. Create a bitbucket-pipelines.yml file at the root of your repo.

Step 2: Prepare Servers

✅ Dev Server (dev.example.com)

• Create a subdomain in your cPanel.
• Setup a WordPress site and connect it to a separate database.
• Give FTP/SFTP or SSH access.

✅ Live Server (example.com)

• Setup your live production WordPress with a separate DB.
• Secure it well.
• Also provide FTP/SFTP or SSH access.

Step 3: Add Environment Variables in Bitbucket

Go to Repository Settings > Repository Variables and add:

For both servers:

• FTP_DEV_HOST
• FTP_DEV_USER
• FTP_DEV_PASS
• FTP_DEV_PATH
• FTP_LIVE_HOST
• FTP_LIVE_USER
• FTP_LIVE_PASS
• FTP_LIVE_PATH

Optional:

• RSYNC_KEY (if using SSH)
• WP_ENV (to control wp-config.php)

Step 4: Setup bitbucket-pipelines.yml

image: atlassian/default-image:latest

pipelines:
  branches:
    dev:
      - step:
          name: Deploy to Dev Server
          script:
            - pipe: atlassian/ftp-deploy:0.4.0
              variables:
                USER: $FTP_DEV_USER
                PASSWORD: $FTP_DEV_PASS
                SERVER: $FTP_DEV_HOST
                REMOTE_PATH: $FTP_DEV_PATH
                LOCAL_PATH: "wp-content"
    main:
      - step:
          name: Deploy to Live Server
          script:
            - pipe: atlassian/ftp-deploy:0.4.0
              variables:
                USER: $FTP_LIVE_USER
                PASSWORD: $FTP_LIVE_PASS
                SERVER: $FTP_LIVE_HOST
                REMOTE_PATH: $FTP_LIVE_PATH
                LOCAL_PATH: "wp-content"        

🧠 Environment-Specific wp-config.php

Use conditional logic to manage environment-specific settings.

<?php
$env = getenv('WP_ENV') ?: 'production';

if ($env === 'development') {
    define('WP_DEBUG', true);
    define('DB_NAME', 'dev_db');
    // other dev config
} else {
    define('WP_DEBUG', false);
    define('DB_NAME', 'live_db');
    // other live config
}        

Set WP_ENV in .htaccess or .env file per server.

🚧 Handling Database and Media

Code deployment is easy, but database and media uploads can be tricky.

Options:

1. Database Sync Manually using plugins like WP Migrate DB Pro or WP-CLI.
2. Do NOT auto-deploy DB changes via CI (to avoid overwriting).
3. Use a shared media storage like S3 or Cloudinary (optional but scalable).

🔒 Best Practices

• NEVER deploy directly to live from feature branches.
• Always test on dev first.
• Keep .env, wp-config.php, and database credentials out of Git.
• Use .gitignore to ignore:

🧪 Optional: Add Slack or Email Notifications

Extend pipelines:

wp-config.php
.env
node_modules/
vendor/        

🧾 Summary

StageActionAutomationCode PushPush to devDeploy to DevQA ApprovalMerge dev → mainDeploy to LiveDeploymentVia Bitbucket PipelinesFTP or SSHDB & MediaManual or semi-autoUse migration tools

🎯 Final Thoughts

With this setup:

• You’ll avoid manual uploads via FTP.
• Team members can focus on code without worrying about deployment.
• Live server always gets tested and stable builds.

Automation not only speeds things up but also enforces discipline in how updates move from local development to production.

If you want this setup customized with GitHub, Jenkins, GitLab, or Cloud-based deployments (e.g., WP Engine, Kinsta) — feel free to drop a comment or message me!