Install the Manager

Install the WordPress plugin, activate it to create its tables, and point it at your CLI server.

Install

Release zips are attached to GitHub Releases under the asset name captaincore-manager.zip, built by bin/build-zip.sh. Install the latest one with WP-CLI:

wp plugin install https://github.com/CaptainCore/captaincore-manager/releases/latest/download/captaincore-manager.zip --activate

To pin a version, use the tagged asset path instead. manifest.json in the repository always names the current one, for example:

https://github.com/CaptainCore/captaincore-manager/releases/download/v1.1.0/captaincore-manager.zip

You can also download the zip and upload it through the WordPress Plugins screen.

What activation does

Activation runs Captaincore_Activator::activate(), which:

  1. Calls CaptainCore\DB::upgrade(). This is the dbDelta migration that creates every wp_captaincore_* table: sites, environments, accounts, providers, domains, the account_site / account_domain / account_user junctions, captures, snapshots, processes, process_logs, recipes, scripts, keys, invites, job_tokens, activity_logs, site_audits, session_snapshots and the rest.
  2. Adds the rewrite rules for the dashboard through CaptainCore\Router and flushes them.
  3. Redirects you to /account unless you are running under WP-CLI.

The schema is also checked on every init and admin_init by captaincore_maybe_upgrade_db(). It compares the captaincore_db_version site option against CaptainCore\DB::REQUIRED_VERSION and runs the migration under a lock (captaincore_db_upgrade_lock) that is reclaimed after 15 minutes. So an upgrade that lands with the plugin already active migrates itself on the next page load.

Point the Manager at the CLI

The Manager talks to the CLI server through a constant. Add it to wp-config.php:

define( 'CAPTAINCORE_CLI_ADDRESS', 'https://captaincore-api.example.com' );
define( 'CAPTAINCORE_CLI_SOCKET_ADDRESS', 'captaincore-api.example.com' );

CAPTAINCORE_CLI_ADDRESS is the base URL of captaincore server. Every dispatch appends a path to it (/run, /run/background, /run/stream, /tasks, /task/{id}, /progress). CAPTAINCORE_CLI_SOCKET_ADDRESS is optional; without it, captaincore_fetch_socket_address() derives the WebSocket URL by swapping https:// for wss:// in the address.

There is no Settings screen field for either constant. They are read from wp-config.php only, and the Manager has no fallback if CAPTAINCORE_CLI_ADDRESS is undefined.

The CLI token

The shared secret between the two halves comes from captaincore_get_cli_token():

  • If CAPTAINCORE_CLI_TOKEN is defined in wp-config.php, that value is used.
  • Otherwise the token is read from the captaincore_cli_token option, and generated with wp_generate_password( 64, false ) on first use.

You do not have to create it by hand. Run captaincore connect on the CLI server and it fetches the token over an authenticated request. See Install the CLI.

The self-updater

includes/class-captaincore-manager-updater.php feeds WordPress its own update information, so updates arrive through the normal Plugins screen and wp plugin update.

  • The manifest is fetched from the pinned URL https://raw.githubusercontent.com/CaptainCore/captaincore-manager/master/manifest.json and cached in the captaincore_manager_updater transient for one hour. If GitHub is unreachable, the bundled manifest.json is used and the failure is cached for five minutes.
  • An update is only offered when the manifest’s download_url is https, on github.com, objects.githubusercontent.com or codeload.github.com, under the path prefix /CaptainCore/captaincore-manager/, and the manifest publishes a non-empty sha256.
  • Before install, verify_package() downloads the zip and compares hash_file( 'sha256', $file ) against the published hash with hash_equals(). A mismatch, or a manifest with no hash, rejects the update rather than installing it.

To force a re-check:

wp transient delete captaincore_manager_updater

Where settings live

Operational settings are edited in the Settings section of the /account dashboard, not on a wp-admin options page. templates/core/settings.js loads six sources:

Screen area Route
Branding (name, colors, logo width) GET /configurations/, saved with PUT /configurations/global
Providers GET /providers, verified with GET /providers/{id}/verify
Site defaults (email, timezone, recipes, users) GET /defaults/, saved with PUT /defaults/global
SSH keys GET /keys/, deleted with DELETE /keys/{id}
Cookbook recipes GET /recipes/
Handbook processes GET /processes/

Providers, defaults, keys and processes are operator-only; customers see the Cookbook tab.