Requirements

CaptainCore Manager

The plugin’s manifest.json declares the versions the self-updater reports to WordPress.

A standard WordPress install with MySQL or MariaDB is enough to activate the plugin. The Manager creates its own tables rather than using custom post types.

Composer dependencies ship inside the release zip (vendor/ is included by bin/build-zip.sh), so you do not need Composer to install it. The declared requirements in composer.json are kriswallsmith/buzz, badcow/dns, spomky-labs/otphp and geoip2/geoip2.

Billing features run on WooCommerce. If you are not using them, you do not need it.

WP-CLI on the Manager host is not strictly required, but the wp captaincore commands are how scheduled fleet work is run, so in practice you want it.

CaptainCore CLI server

The CLI is a single compiled Go binary. The bash scripts it shells out to (~/.captaincore/app/ for some commands, ~/.captaincore/lib/remote-scripts/ for work done over SSH) are embedded in the binary and unpacked into ~/.captaincore/ the first time it runs, and again whenever the binary version changes. No local WordPress, WP-CLI or PHP is needed on the CLI server.

Operating system. Linux or macOS on x86_64, arm64 or armv7. Release builds are static (CGO_ENABLED=0), so any Linux distribution works, glibc or musl. install.sh exits with “Unsupported” on anything else. There is no Windows build; the CLI runs bash.

Runtime dependencies. captaincore connect checks for three binaries on PATH and warns if any are missing:

Building from source. go.mod declares go 1.25.0, so you need Go 1.25 or newer to build. You do not need Go if you install a released binary.

Storage. The CLI keeps a SQLite database at ~/.captaincore/data/captaincore.db. It holds plaintext SSH, database and offload credentials, so the CLI chmods it to 0600 on open. Give the CLI server the same care you would give a credential store.

Managed sites

Each environment CaptainCore manages needs:

• SSH or SFTP access. An environment record stores an address, username, password, protocol (sftp or ssh) and port. captaincore ssh and every remote script run over that connection.
• WP-CLI on the remote host. The fetch-site-data remote script calls wp plugin list, wp theme list, wp core version, wp option get home, wp user list and wp core verify-checksums. Without WP-CLI, syncs return nothing useful.
• A WordPress install in the connection’s home directory. fetch-site-data exits with WordPress not found if there is no wp-config.php there.

fetch-site-data also installs a CaptainCore helper mu-plugin when it is missing, by piping https://run.captaincore.io/deploy-helper to bash. If your sites cannot reach that URL, that step will fail.

Third-party services

Nothing in this list is needed to install and activate either half. Each one gates a specific feature.

The provider types the Settings screen offers are the twelve listed in templates/core/settings.js as PROVIDER_TYPES: kinsta, wpengine, rocketdotnet, gridpane, constellix, hoverdotcom, spaceship, mailgun, forwardemail, fathom, intercom and envato.