API/CLI guide

Use the BinaryLane API or CLI to move an existing server to another region. Migration keeps the server's existing IPv4 addresses.

This moves the same server; it does not transfer an IP address to a different server or clone another server onto it.

Prefer the control panel? Follow How to Migrate Your Server (Change Location).

Table of contents

Before you begin

You need:

  • a BinaryLane API token authorised to read the server and perform the migration
  • Bash with either the configured bl CLI or curl 7.76.0 or later. For curl, check your version with curl --version.
  • one existing BinaryLane server and its server ID
  • an eligible destination region and the migration prerequisites completed

Applies to

BinaryLane API 0.40.2 and binarylane-cli 0.21.0. Choose the CLI or API examples at each step; do not submit the migration with both methods.

For bl, follow the CLI configuration instructions. For curl, set BINARYLANE_API_TOKEN securely in your shell environment. The CLI uses its configured authentication context; setting that curl variable alone is not CLI configuration. Do not put tokens in screenshots or support messages.

For token setup, see Getting Started with BinaryLane API. The variable assignments and examples below use Bash syntax, not PowerShell syntax.

Complete the prerequisites in How to Migrate Your Server (Change Location) first. That guide covers region-group restrictions, VPC-only servers, restart behaviour and network preparation. Using the API does not bypass those requirements.

The examples use ${BINARYLANE_API_TOKEN} for your token, ${server_id} for the server you are moving, ${target_region} for the destination region slug, and ${action_id} for the migration action returned by the API.

Step 1: Check the server and region

Use the server ID from mPanel to retrieve and check the intended server. Replace 123456 with your server's ID.

With the CLI:

server_id=123456
bl server get ${server_id} --output json
bl region list --output json

Check the server's id, name, region and networks. Note the destination region's slug.

With the API:

server_id=123456
curl --silent --show-error --fail-with-body \
  -H "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  -H "Accept: application/json" \
  "https://api.binarylane.com.au/v2/servers/${server_id}"

Check the returned server.id, server.name, server.region and server.networks. Keep the current network details for comparison after migration.

Retrieve the region list and copy the destination's slug:

curl --silent --show-error --fail-with-body \
  -H "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  -H "Accept: application/json" \
  "https://api.binarylane.com.au/v2/regions"

The response contains regions with names and slugs. Follow pagination links if present. The available field describes availability for new resources; it is not a guarantee that your server can migrate there. Region eligibility and destination capacity still apply.

Step 2: Start the migration

Send a change_region action with the destination slug.

This request changes the server's location
Check the server ID, destination and migration prerequisites before running it. Allow for a network interruption and the effects of any prerequisite network changes.

Replace DESTINATION_SLUG with the value returned by the region list.

With the CLI:

target_region='DESTINATION_SLUG'
bl server action change-region ${server_id} --region "${target_region}" --output json

The CLI waits for the action by default and shows progress. Wait for successful completion before checking the destination. If it reports an error or your terminal disconnects, check the action before retrying. The --async option disables waiting; it is intentionally omitted here.

With the API instead:

target_region='DESTINATION_SLUG'
curl --silent --show-error --fail-with-body --include \
  -X POST \
  -H "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"change_region\",\"region\":\"${target_region}\"}" \
  "https://api.binarylane.com.au/v2/servers/${server_id}/actions"

A successful HTTP response is not proof that the move has finished. A 200 response contains an action object; record its id. The API also documents 202 Accepted without a response-body schema. If no action ID is returned, check the server's action list rather than resubmitting the migration.

Step 3: Monitor the migration

Retrieve the action using its ID. Replace 789012 with the returned action ID.

With the CLI: if the waiting command completed successfully, continue to Step 4. To inspect an action separately, use:

action_id=789012
bl action get ${action_id} --output json

If you do not have its ID, run bl server action list ${server_id} --output json and identify the migration by its type and start time. Inspect the returned status and reason.

With the API:

Allow time for the move: servers with small amounts of storage may migrate in a few minutes, while larger servers can take significantly longer. See the main guide's duration and restart guidance. Recheck the action status periodically; a long-running action is not, by itself, a reason to submit another migration.

action_id=789012
curl --silent --show-error --fail-with-body \
  -H "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  -H "Accept: application/json" \
  "https://api.binarylane.com.au/v2/servers/${server_id}/actions/${action_id}"
  • in-progress: the action is still running.
  • completed: the action completed successfully.
  • errored: the action failed; read its reason and contact support if needed.

Check action.status, action.reason and action.progress. If user_interaction_required is present and non-null, inspect the request in mPanel before proceeding; do not automatically approve prompts.

For more detail on checking actions and handling requests for input, see Poll a long-running action and respond when input is required.

To find an action ID after a missing response or 202, request the server's actions:

curl --silent --show-error --fail-with-body \
  -H "Authorization: Bearer ${BINARYLANE_API_TOKEN}" \
  -H "Accept: application/json" \
  "https://api.binarylane.com.au/v2/servers/${server_id}/actions"

Identify the change_region action by its type and start time, following pagination links if needed. Do not assume the first result is your request. If the outcome is unclear, check mPanel or contact support before retrying the POST.

Step 4: Verify the result

After the action completes, retrieve the server again using the first command. Confirm server.region.slug matches your destination and compare its IPv4 addresses with your recorded values.

With the CLI, run bl server get ${server_id} --output json again and check region.slug and networks. The API response wraps those fields inside server.

Do not use an IP-geolocation database's city label to verify the move. It may differ from the server's actual region.

Test your applications and connections, then complete the main guide's post-migration network checks. When asking support for help, include the server ID, action ID and error text, but never your API token.