Wordmove for WordPress Deployment Across Multiple Environments

Wordmove's WordPress Mirroring Scope

Wordmove addresses the recurring task of copying a WordPress installation and its database between a development machine and one or more hosting environments. Its intended users are developers who already work from the WordPress command line and need repeatable transfer commands instead of assembling database dumps, uploads, plugins, themes, and configuration files by hand. The tool handles WordPress data as a coordinated operation, while SSH or FTP supplies the transport.

The distinction between files and database data matters. Wordmove can push local files and database data to a selected remote environment, or pull remote files and database data into the local WordPress directory. A multi-environment configuration can represent production, staging, or another named target. This is useful when the same command workflow must address different hosts, databases, and virtual hosts without producing separate scripts.

Wordmove does not present itself as a complete WordPress hosting panel or CI service. The README positions it as automation between tools that the developer or hosting environment already has. Database export and import depend on `mysql` and `mysqldump`, while `wp-cli` is the default SQL adapter. File transfer behavior depends on the selected protocol. That makes Wordmove most appropriate for teams comfortable managing a command line deployment environment, not for users seeking an all-in-one hosting interface.

How Wordmove Transfers WordPress Data

Wordmove reads a YAML file named `movefile.yml` and interprets its sections as local settings, remote environments, global options, exclusions, and hooks. The database section identifies the database name, user, password, and host. File paths can include the WordPress root and selected internal directories such as uploads, plugins, themes, and languages. An `exclude` list keeps repository metadata, dependency directories, WordPress configuration, and local artifacts from entering a transfer.

The available `pull` and `push` commands define the direction of movement. The `-e` option selects a named environment for a multi-stage operation. Under the SSH protocol, the README requires `rsync` locally and expects `gzip`, `nice`, `mysql`, and `rsync` on the remote server. FTP instead requires `lftp`. This division of work explains why Wordmove can coordinate a complex transfer, but it also means diagnostics can fail at any missing executable or unreachable destination command.

Hooks add a command runner around transfers. A hook can execute a local command or, when SSH is used, a remote command before or after `push` or `pull`. The `raise` setting determines whether failure stops the operation, with `true` documented as the default. These hooks can represent operational steps around file and database movement, but they also expand the failure surface. A deployment can succeed at data transfer and still return failure because a cleanup, cache, or validation command failed.

Sensitive values can be read through ERB expressions from environment variables or a `.env` file. This keeps database credentials out of the literal YAML values and permits a movefile to be shared between developers. It does not make secrets harmless by itself, so whether `.env`, deployment artifacts, and generated movefiles are covered by the project's exclusion configuration remains an operational concern.

Installing Wordmove and Running Initial Checks

The README identifies `gem install wordmove` as the installation method. Wordmove is packaged as a Ruby gem, but installation alone does not supply all peer dependencies. The local commands `rsync`, `mysql`, `mysqldump`, and `wp-cli` must be executable through `$PATH` when their associated features are used. `lftp` is also required for FTP. The remote SSH server must expose `gzip`, `nice`, `mysql`, and `rsync`.

Install the command from the terminal:

gem install wordmove

After RubyGems completes, use the documented environment check from a local system configured for the WordPress project:

wordmove doctor

The README describes this command as a local configuration and environment check. It does not provide its individual output or a guarantee that every remote server is reachable, so a successful check should not be treated as proof that production credentials and destination paths are correct.

Wordmove is also distributed through Docker, as indicated by the repository's Docker build badge and Docker-related topics. However, the README does not give a Docker image pull command, image name syntax, volume configuration, or first-use example. The confirmed first-use path is therefore the Ruby gem route.

Creating and Targeting the First movefile.yml

From the WordPress directory, `wordmove init` generates a new movefile. The file should be edited before any transfer because the generated skeleton cannot know the correct virtual host, absolute WordPress path, database credentials, or SSH host.

Create the file with:

wordmove init

The README requires `global` and `local`, then treats other first-level keys as remote environments. A minimal structure based on the documented fields is:

global:
  sql_adapter: wpcli

local:
  vhost: http://vhost.local
  wordpress_path: /home/john/sites/your_site
  database:
    name: database_name
    user: user
    password: password
    host: localhost

staging:
  vhost: http://example.com
  wordpress_path: /var/www/your_site
  database:
    name: database_name
    user: user
    password: password
    host: host
  ssh:
    host: host
    user: user

Absolute WordPress paths are explicitly required in the example. The target name here is `staging`, which makes it available to `-e`. Before transferring anything, compare `wordpress_path` and `host` with the actual server, then review `exclude` entries. A mistaken path or database host is more consequential than a syntax error because the command can direct valid credentials to the wrong environment.

Environment variables can replace literal credentials:

export PROD_DB_USER="username" PROD_DB_PASS="password"

The corresponding YAML values use the documented ERB syntax:

production:
  database:
    user: "<%= ENV['PROD_DB_USER'] %>"
    password: "<%= ENV['PROD_DB_PASS'] %>"

This removes credentials from the displayed YAML, but exporting a long-lived shell variable can still expose them to the process environment. The README also supports dotenv files but discourages `.env.{environmentname}` files.

Pushing to Staging with an Explicit Environment

After the target configuration and exclusions have been reviewed, the documented transfer syntax can push local database and WordPress data to a named environment. The `-d` flag appears in the README's multistage example. The README does not explain that flag in detail, so its exact effects should be checked in the linked usage and flags documentation before it is used outside the example.

Run the documented staging push as follows:

wordmove push -e staging -d

The `-e staging` portion selects the `staging` section rather than requiring a separate tool for each host. The file exclusions in the configuration are significant during this operation. The sample excludes `.git/`, `node_modules/`, `bin/`, `tmp/*`, `Movefile`, `movefile`, `movefile.yml`, `movefile.yaml`, `wp-config.php`, local SQL archives, and `*.orig`. Applications with different generated files or secrets need their own reviewed rules.

A safe first exercise would use the repository's `wordmove list` command to confirm that the intended environment and virtual hosts are parsed:

wordmove list

The README says this lists environments and vhosts. It does not document a dry-run transfer mode, a rollback command, or transactional verification of a destination. The repository's FTP disclaimer also states that FTP development has been discontinued and not every feature is available with that protocol. For a broad feature set, SSH is the documented path.

Wordmove Versus a Manual rsync and Database Workflow

The clearest alternative is a hand-written shell workflow built from the same peer dependencies: use database utilities to export and import SQL, use `rsync` over SSH for files, and invoke `wp-cli` for WordPress-specific operations. This approach is less unified, but it leaves each command and its destination visible and makes it easier to add transfer-specific checks without adopting Wordmove's configuration and hook semantics.

Wordmove's advantage is coordination. One `push` or `pull` command covers the configured WordPress data and database, while named environments reduce duplication. Hooks provide documented positions for commands before and after a transfer. Environment variables and dotenv support also fit directly into the movefile.

The trade-off is added dependency and configuration scope. Wordmove expects several local tools, several remote SSH tools, a valid movefile, and compatible behavior for the chosen SQL adapter. FTP support is explicitly incomplete. A direct shell workflow may be easier to understand for a one-transfer site, while Wordmove becomes more relevant when the same local installation is repeatedly synchronized among several targets.

Wordmove Maintenance, License, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-06-22. The listed releases are older: `v5.2.2` was released on 2021-09-14, `v5.2.1` on 2020-12-13, and `v5.1.0` on 2020-05-16. These dates show continued repository activity without establishing a recent release cadence, so adoption should account for both the push date and the age of the available tagged releases.

Upgrades are installed through RubyGems with the documented command:

gem update wordmove

The README does not provide a compatibility matrix across Wordmove versions, Ruby versions, wp-cli releases, or database servers. It also does not document an automatic configuration migration. An existing movefile and any custom hooks therefore need review when the installed gem changes.

The project is distributed under the MIT license. That identifier permits use, modification, distribution, and sublicensing subject to the license terms, but the README does not state how Wordmove handles hosted service distribution or whether bundled dependencies introduce separate obligations. Users needing organization-specific compliance conclusions must inspect the `LICENSE` and dependency terms directly. The practical upgrade cost is primarily configuration review and verification of the external command toolchain, rather than an application rewrite.

Editorial conclusion

Developers with an existing WordPress and shell toolchain may adopt Wordmove when repeatable environment selection, file and database transfers, and before-and-after hooks justify an additional Ruby configuration layer. Projects that require first-class FTP parity, extensive verification of the destination, or support without careful dependency management should choose a simpler workflow. Before the first production push, verify the exact `movefile.yml` paths, exclusions, database target, and whether the destination commands are available.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. welaika/wordmove on GitHub