Computers & Electronics
47,087 views
25 min · 2 min read
7 steps
Advanced

How to set up a local development environment for WordPress with docker and migrate to live hosting

This guide walks you through creating a local WordPress development environment using Docker, building and testing your site, and then migrating it to live hosting. It focuses on practical steps you can complete in a few hours, with configuration choices that keep development fast and deployments reliable. Follow the sequence to avoid common pitfalls and ensure a smooth go-live.

Verified by pleasexplain editors
  1. Step 1: Install prerequisites

    Install Docker Desktop (or Docker Engine + Docker Compose) and Git on your machine; expect 10–30 minutes depending on downloads. Ensure Docker has at least 2 GB RAM allocated and that ports 80 and 3306 are free to avoid conflicts during container startup.

    [Illustration: computer desktop showing Docker whale icon and terminal window with git clone command]

  2. Step 2: Create project skeleton

    Make a project folder and create docker-compose.yml, a Dockerfile for custom PHP if needed, and a .env file with passwords. Keep passwords simple for local use (e.g., DB_PASSWORD=localpass123) and store files under a projects directory so volume mounts are predictable.

    [Illustration: file explorer view with project folder and files docker-compose.yml .env Dockerfile]

  3. Step 3: Define services in Compose

    Write docker-compose.yml defining services: wordpress (official image), mysql:5.7 or mariadb:10.3, and optionally phpmyadmin and traefik or nginx reverse proxy. Set volumes for ./wordpress:/var/www/html and ./db_data:/var/lib/mysql, expose ports like 8080:80 and 3307:3306 for local access and isolation.

    [Illustration: text editor showing docker-compose.yml with services wordpress and mysql and port mappings]

  4. Step 4: Start containers and complete install

    Run docker-compose up -d and wait 30–90 seconds for containers to initialize. Visit http://localhost:8080 and complete the WordPress setup (site title, admin user with strong password). Verify DB connectivity and that the site loads without errors.

    [Illustration: browser window loading local WordPress setup page on localhost:8080]

  5. Step 5: Develop and test locally

    Install themes and plugins, add sample content, and test functionality for 1–3 hours or as needed. Use WP_DEBUG=true in wp-config.php for development logging, and run automated tests or manual checks across 3 browsers to catch issues early.

    [Illustration: developer editing WordPress theme files in code editor with browser preview on the right]

  6. Step 6: Prepare for migration

    Export the database using WP-CLI or phpMyAdmin and copy the wp-content folder; produce a zip and an SQL file. Replace local URLs (e.g., http://localhost:8080) with the live URL in the SQL using search-replace tools and create a checksum or note file sizes and modified dates for verification.

    [Illustration: terminal showing wp export command and file archive.zip being created with wp-content and database.sql]

  7. Step 7: Deploy to live hosting

    On the live host, upload wp-content zip and import SQL into the remote database, then update wp-config.php with production DB credentials and set correct file permissions (chown www-data:www-data and chmod 755/644). Test the site on the live domain, clear caches, and monitor logs for 24–48 hours after go-live.

    [Illustration: server control panel showing file upload and database import progress]


  • Use volumes for code so edits are instant; bind mount ./wordpress to /var/www/html for 1:1 editing.
  • Commit theme/plugin code to Git and tag releases; keep the database out of version control.
  • Use WP-CLI for repeatable tasks: export/import takes 10–60 seconds for typical sites under 50 MB.
  • Keep a staging environment that mirrors production with identical PHP and MySQL versions. 1:1 parity reduces surprises.
  • Automate backups: schedule daily DB dumps and weekly full backups; keep at least 14 days of retention.
  • Use environment variables for secrets and never hardcode production passwords into Docker images or public repos.

  • Do not expose local containers directly to the public internet without a proper firewall and TLS; local setups are for development only.
  • Never commit production credentials or database dumps containing user data to public repositories; remove or anonymize sensitive data before sharing.
  • When replacing URLs in SQL, use a serialized-aware tool (like WP-CLI search-replace) to avoid corrupting theme or plugin data.
  • Always test file permissions on the live server; incorrect permissions (e.g., 777) create security risks and can break updates.

Was this guide helpful?