High-performance distributed object storage

Scale object storage without scaling complexity.

X2 delivers an S3-compatible data platform built for demanding workloads, with scale-out capacity, resilient data services, secure access, and complete operational visibility.

Download current release Start installation guide

Loading the signed release catalog…

S3-compatibleConnect existing applications and tools

Scale-out throughputGrow performance with your infrastructure

Continuous protectionKeep data healthy throughout its lifecycle

Unified operationsManage storage, identity, and health together

Why X2

Built for demanding data workloads

Run primary object storage, analytics data, backups, archives, and application content on one horizontally scalable platform.

Performance at scale

Parallel streaming paths and distributed placement keep data moving as nodes and storage devices are added.

Elastic capacity

Expand storage incrementally across heterogeneous disks and servers without redesigning application access.

Resilient data services

Integrated healing, lifecycle management, multipart coordination, replication, and safe maintenance workflows.

Enterprise access control

Central IAM, short-lived sessions, audit activity, scoped administration, and optional external KMS protection.

Open data workflows

Serve S3 applications while enabling Iceberg catalogs, Delta Sharing, MCP, inventory, and automation.

Operational clarity

Use one console for capacity, health, logs, statistics, maintenance, updates, and cluster-wide administration.

Release artifacts

Download X2

Select the target machine. The catalog resolves the exact binary, verification data, and installation scripts from the published release manifest.

Version: —
Channel: —
Published: —

Operating system

Architecture

Linux · AMD64

Installation helpers

Platform setup files

Download these beside the binaries. The service installers stage files but never erase data, bootstrap a cluster, or silently start an unconfigured service.

Verify before installation

Compare the SHA-256 value shown on the artifact card. Production x2-node releases also carry an Ed25519 detached signature used by the rolling updater.

Open complete release manifest

Documentation

Choose a guide

Start with installation, then move to scaling, encryption, or day-two operations when you are ready.

01Install X2Download, configure, start, and connect XC. 02Scale the clusterEnroll nodes and safely add storage capacity. 03Enable encryptionConfigure X2 KMS or HashiCorp Vault. 04Operate X2Monitor health and perform signed updates.

Installation guide

From download to first login

Use empty data and metadata roots. X2 intentionally does not import legacy service state or run mixed-version service topologies.

Show commands for

Download X2 Node, XC, and the service installer

Select the operating system and architecture above. These commands are generated from the current signed release catalog and save each executable with its standard product name.

Loading release catalog…

Loading release catalog…

Loading release catalog…

Download only from this HTTPS release center. The next step verifies the X2 Node digest before installation.

Prepare the host

Use a supported 64-bit Linux, Windows, or macOS host, static node addresses, synchronized time, and empty dedicated storage paths. Allow the public HTTPS listener and TCP 9443 between X2 nodes. Keep metadata on a dedicated, durable path.

Administrator/root access for service installation
Unique node ID, public URL, and routable mesh address
One or more empty object-data roots and at least one empty metadata root
DNS and a trusted public TLS certificate for production ingress

Verify the downloaded binary

sha256sum ./x2-node
# Compare with the digest on this page or manifest.json
chmod 0755 ./x2-node

Get-FileHash .\x2-node.exe -Algorithm SHA256
# Compare Hash with the digest on this page or manifest.json

shasum -a 256 ./x2-node
# Compare with the digest on this page or manifest.json
chmod 0755 ./x2-node

Do not install an artifact whose size or digest differs. The cluster updater separately validates the signed immutable release manifest and detached node signature.

Install the unified node service

Keep install-x2-node.sh and x2-node.service in the same directory.

sudo bash ./install-x2-node.sh \
  --binary "$(realpath ./x2-node)"

Open PowerShell as Administrator.

Set-ExecutionPolicy -Scope Process Bypass
.\install-x2-node-service.ps1 `
  -BinaryPath (Resolve-Path .\x2-node.exe)

Keep install-x2-node.sh and com.edgedrive.x2-node.plist together.

sudo bash ./install-x2-node.sh \
  --binary "$PWD/x2-node"

The service is installed but remains unconfigured and stopped.

Configure the first node

sudo /usr/lib/x2/x2-node configure '/data/x2/disk{1...4}' \
  --metadata '/data/x2/metadata' \
  --root /var/lib/x2 \
  --address '10.0.0.11:8443' \
  --public-url 'https://10.0.0.11:8443' \
  --internal-address '0.0.0.0:9443' \
  --internal-advertise '10.0.0.11:9443' \
  --admin-user 'admin' \
  --admin-password 'REPLACE_WITH_A_UNIQUE_PASSWORD' \
  --config /etc/x2/node.yaml

& 'C:\Program Files\X2\x2-node.exe' configure 'D:\x2\data{1...4}' `
  --metadata 'D:\x2\metadata' `
  --root 'C:\ProgramData\X2\runtime' `
  --address '10.0.0.11:8443' `
  --public-url 'https://10.0.0.11:8443' `
  --internal-address '0.0.0.0:9443' `
  --internal-advertise '10.0.0.11:9443' `
  --admin-user 'admin' `
  --admin-password 'REPLACE_WITH_A_UNIQUE_PASSWORD' `
  --config 'C:\ProgramData\X2\config\node.yaml'

sudo /usr/local/lib/x2/x2-node configure '/Volumes/X2Data/disk{1...4}' \
  --metadata '/Volumes/X2Metadata' \
  --root /usr/local/var/lib/x2 \
  --log-root /usr/local/var/log/x2 \
  --address '10.0.0.11:8443' \
  --public-url 'https://10.0.0.11:8443' \
  --internal-address '0.0.0.0:9443' \
  --internal-advertise '10.0.0.11:9443' \
  --admin-user 'admin' \
  --admin-password 'REPLACE_WITH_A_UNIQUE_PASSWORD' \
  --config /usr/local/etc/x2/node.yaml

Production DNS and TLS: replace the example IP with the node or ingress address and provide --tls-cert and --tls-key for a certificate valid for the configured --public-url. The generated bootstrap certificate is intended for initial setup and must be trusted through the printed cluster CA.

Development shortcut: run x2-node server with the same disk, metadata, and administrator arguments to stay in the foreground. Omit KMI options to run without credential or object encryption.

Start and verify

sudo systemctl enable --now x2-node
sudo systemctl status x2-node --no-pager
sudo journalctl -u x2-node -n 100 --no-pager
curl --fail --cacert /var/lib/x2/state/secrets/cluster-ca.crt \
  https://127.0.0.1:8443/health/ready

Set-Service X2Node -StartupType Automatic
Start-Service X2Node
Get-Service X2Node
Get-WinEvent -LogName Application -MaxEvents 50 |
  Where-Object ProviderName -Match 'X2'

sudo launchctl bootstrap system /Library/LaunchDaemons/com.edgedrive.x2-node.plist
sudo launchctl print system/com.edgedrive.x2-node
tail -n 100 /usr/local/var/log/x2/x2-node.stderr.log
curl --fail --cacert /usr/local/var/lib/x2/state/secrets/cluster-ca.crt \
  https://127.0.0.1:8443/health/ready

Open the configured public URL, sign in with the initial administrator, verify quorum and storage capacity, then create a separate day-to-day administrator.

Install and configure XC

sudo install -m 0755 ./xc /usr/local/bin/xc
xc --version
xc alias set x2 https://10.0.0.11:8443 \
  YOUR_ACCESS_KEY YOUR_SECRET_KEY \
  --ca-file /var/lib/x2/state/secrets/cluster-ca.crt --current
xc ls x2

New-Item -ItemType Directory -Force 'C:\Program Files\X2' | Out-Null
Copy-Item .\xc.exe 'C:\Program Files\X2\xc.exe'
& 'C:\Program Files\X2\xc.exe' alias set x2 https://10.0.0.11:8443 `
  YOUR_ACCESS_KEY YOUR_SECRET_KEY `
  --ca-file 'C:\ProgramData\X2\runtime\state\secrets\cluster-ca.crt' --current
& 'C:\Program Files\X2\xc.exe' ls x2

sudo install -m 0755 ./xc /usr/local/bin/xc
xc --version
xc alias set x2 https://10.0.0.11:8443 \
  YOUR_ACCESS_KEY YOUR_SECRET_KEY \
  --ca-file /usr/local/var/lib/x2/state/secrets/cluster-ca.crt --current
xc ls x2

Create the access key in the web console first. Prefer environment-backed credentials for automation and protect the XC configuration as a secret.

Scale out

Add storage nodes safely

The first node creates the cluster. Every additional node joins with a short-lived, single-use enrollment token and begins as a non-voter until it catches up.

Create enrollment

From an existing administrator session, create a node enrollment and copy its endpoint, token, and cluster CA.

Download and install the same release

On the new host, use the platform download command for the cluster version, verify x2-node, and install it without bootstrapping a separate cluster.

Join with empty roots

Run the platform command below with the new node’s unique mesh address and storage paths.

Verify and promote

Start the service, wait for catch-up, verify capacity, then allow consensus to promote the node according to voter policy.

Linux

sudo /usr/lib/x2/x2-node join \
  --endpoint 'https://10.0.0.11:8443' \
  --token 'ONE_TIME_ENROLLMENT_TOKEN' \
  --ca-file '/root/x2-cluster-ca.crt' \
  --state-root '/var/lib/x2/state' \
  --log-root '/var/log/x2' \
  --install-root '/usr/lib/x2' \
  --public-listen '0.0.0.0:8443' \
  --internal-listen '0.0.0.0:9443' \
  --internal-advertise '10.0.0.12:9443' \
  --disk '{"id":"disk-1","volume_id":1,"path":"/data/x2/disk1"}' \
  --metadata-root '{"id":"metadata-1","path":"/data/x2/metadata"}' \
  --config '/etc/x2/node.yaml'

Windows PowerShell

& 'C:\Program Files\X2\x2-node.exe' join `
  --endpoint 'https://10.0.0.11:8443' `
  --token 'ONE_TIME_ENROLLMENT_TOKEN' `
  --ca-file 'C:\Temp\x2-cluster-ca.crt' `
  --state-root 'C:\ProgramData\X2\runtime\state' `
  --log-root 'C:\ProgramData\X2\logs' `
  --install-root 'C:\Program Files\X2' `
  --public-listen '0.0.0.0:8443' `
  --internal-listen '0.0.0.0:9443' `
  --internal-advertise '10.0.0.12:9443' `
  --disk '{"id":"disk-1","volume_id":1,"path":"D:\x2\disk1"}' `
  --metadata-root '{"id":"metadata-1","path":"D:\x2\metadata"}' `
  --config 'C:\ProgramData\X2\config\node.yaml'

macOS

sudo /usr/local/lib/x2/x2-node join \
  --endpoint 'https://10.0.0.11:8443' \
  --token 'ONE_TIME_ENROLLMENT_TOKEN' \
  --ca-file '/private/tmp/x2-cluster-ca.crt' \
  --state-root '/usr/local/var/lib/x2/state' \
  --log-root '/usr/local/var/log/x2' \
  --install-root '/usr/local/lib/x2' \
  --public-listen '0.0.0.0:8443' \
  --internal-listen '0.0.0.0:9443' \
  --internal-advertise '10.0.0.12:9443' \
  --disk '{"id":"disk-1","volume_id":1,"path":"/Volumes/X2Data/disk1"}' \
  --metadata-root '{"id":"metadata-1","path":"/Volumes/X2Metadata"}' \
  --config '/usr/local/etc/x2/node.yaml'

Do not copy node state. Each node must have a unique identity, state root, public listener, and mesh address. When running multiple development nodes on one machine, assign unique public and internal ports.

Key management integration

Encryption with an explicit trust boundary

X2 can run with KMI disabled for evaluation. In that mode credential envelopes and object payloads are not encrypted. Production installations should configure X2 KMS or HashiCorp Vault before admitting data.

Supported

X2 KMS

Sealed, independently operated transit-key cluster with manual unseal, Raft replication, TLS server identity, pinned workload public keys, and least-privilege grants.

Open X2 KMS guide

Supported

HashiCorp Vault

Vault Transit integration using token, AppRole, or client-certificate authentication. Vault remains the source of key policy and audit truth.

Open Vault guide

Adapter required

Cloud KMS providers

AWS KMS, Azure Key Vault, and Google Cloud KMS require provider-specific KMI adapters and are not selectable in the current binary.

Review adapter status

X2 KMS guide

Deploy, initialize, and connect X2 KMS

Operate X2 KMS separately from the storage cluster. Initialize exactly one KMS member, securely retain its root token and five unseal shares, and unseal every member locally with any three distinct shares.

Complete setup guide10 steps · download, installation, initialization, workload identity, grants, and node integration

Download X2 KMS and its service installer

The command below is generated from the selected platform, architecture, and current signed release.

Loading release catalog…

Loading release catalog…

Loading release catalog…

Install

sudo bash ./install-x2-kms.sh \
  --binary "$(realpath ./x2-kms)"

.\install-x2-kms-service.ps1 `
  -BinaryPath (Resolve-Path .\x2-kms.exe)

sudo bash ./install-x2-kms.sh \
  --binary "$PWD/x2-kms"

Generate HTTPS identity

sudo /usr/lib/x2/x2-kms certificates generate \
          --name kms-server --usage server \
  --host kms.example.com --host 127.0.0.1 --host localhost \
  --out-dir /var/lib/x2-kms/tls

& 'C:\Program Files\X2\x2-kms.exe' certificates generate `
  --name kms-server --usage server `
  --host kms.example.com --host 127.0.0.1 --host localhost `
  --out-dir 'C:\ProgramData\X2KMS\tls'

sudo /usr/local/lib/x2/x2-kms certificates generate \
  --name kms-server --usage server \
  --host kms.example.com --host 127.0.0.1 --host localhost \
  --out-dir /usr/local/var/lib/x2-kms/tls

Configure and start

Create the platform KMS configuration with unique API, Raft, storage, and TLS paths. Start the first service only after validating the file.

sudo systemctl enable --now x2-kms
sudo journalctl -u x2-kms -f

Set-Service X2KMS -StartupType Automatic
Start-Service X2KMS
Get-Service X2KMS

sudo launchctl bootstrap system /Library/LaunchDaemons/com.edgedrive.x2-kms.plist
sudo launchctl print system/com.edgedrive.x2-kms
tail -f /usr/local/var/log/x2-kms/x2-kms.stderr.log

Initialize once

export X2_KMS_ADDR='https://127.0.0.1:18200'
export X2_KMS_SERVER_CERT='/secure/kms-server.crt'
/usr/lib/x2/x2-kms operator init

$env:X2_KMS_ADDR='https://127.0.0.1:18200'
$env:X2_KMS_SERVER_CERT='C:\Secure\kms-server.crt'
& 'C:\Program Files\X2\x2-kms.exe' operator init

export X2_KMS_ADDR='https://127.0.0.1:18200'
export X2_KMS_SERVER_CERT='/private/secure/kms-server.crt'
/usr/local/lib/x2/x2-kms operator init

Move the root token and all five shares to separate protected operator custody. They are not recoverable from X2.

Unseal locally

read -rsp 'Unseal share: ' SHARE; printf '%s' "$SHARE" | \
  /usr/lib/x2/x2-kms operator unseal --key -; unset SHARE
# Repeat with two other shares

Read-Host 'Share 1' -MaskInput |
  & 'C:\Program Files\X2\x2-kms.exe' operator unseal --key -
# Repeat with two other shares

read -rsp 'Unseal share: ' SHARE; printf '%s' "$SHARE" | \
  /usr/local/lib/x2/x2-kms operator unseal --key -; unset SHARE
# Repeat with two other shares

Create node workload identity

sudo /usr/lib/x2/x2-kms workloads generate-identity \
  --name node-1 \
  --out-dir /var/lib/x2/state/secrets \
  --kms-endpoint https://kms.example.com:18200 \
  --server-certificate /secure/kms-server.crt

& 'C:\Program Files\X2\x2-kms.exe' workloads generate-identity `
  --name node-1 `
  --out-dir 'C:\ProgramData\X2\runtime\secrets' `
  --kms-endpoint 'https://kms.example.com:18200' `
  --server-certificate 'C:\Secure\kms-server.crt'

sudo /usr/local/lib/x2/x2-kms workloads generate-identity \
  --name node-1 \
  --out-dir /usr/local/var/lib/x2/state/secrets \
  --kms-endpoint https://kms.example.com:18200 \
  --server-certificate /private/secure/kms-server.crt

Merge the printed client-key ID and grants into every KMS member’s configuration. Configure the printed X2_X2KMS_* values on that X2 node, then restart KMS and X2 node in that order.

Perform authorized key administration

export X2_KMS_ADDR='https://127.0.0.1:18200'
export X2_KMS_SERVER_CERT='/secure/kms-server.crt'
read -rsp 'Root token: ' X2_KMS_TOKEN; export X2_KMS_TOKEN
/usr/lib/x2/x2-kms keys create \
  --key customer-finance-key --type aes256-gcm96
unset X2_KMS_TOKEN

$env:X2_KMS_ADDR='https://127.0.0.1:18200'
$env:X2_KMS_SERVER_CERT='C:\Secure\kms-server.crt'
$env:X2_KMS_TOKEN=Read-Host 'Root token' -MaskInput
& 'C:\Program Files\X2\x2-kms.exe' keys create `
  --key customer-finance-key --type aes256-gcm96
Remove-Item Env:X2_KMS_TOKEN

export X2_KMS_ADDR='https://127.0.0.1:18200'
export X2_KMS_SERVER_CERT='/private/secure/kms-server.crt'
read -rsp 'Root token: ' X2_KMS_TOKEN; export X2_KMS_TOKEN
/usr/local/lib/x2/x2-kms keys create \
  --key customer-finance-key --type aes256-gcm96
unset X2_KMS_TOKEN

Add an exact grant for a customer key before selecting it for bucket encryption. Keep the root token out of shell history and remove it from the environment immediately after administration.

Add and promote a KMS member

Prepare the new member with a unique node ID, peer address, encrypted-store path, empty Raft path, and peer certificate. Start it, then execute membership changes locally on a current unsealed member.

export X2_KMS_ADDR='https://127.0.0.1:18200'
read -rsp 'Root token: ' X2_KMS_TOKEN; export X2_KMS_TOKEN
/usr/lib/x2/x2-kms members add \
  --node-id kms-2 --peer-address 10.0.0.22:18201
/usr/lib/x2/x2-kms members list
# Unseal kms-2 locally with three original shares after catch-up
/usr/lib/x2/x2-kms members promote --node-id kms-2
unset X2_KMS_TOKEN

$env:X2_KMS_ADDR='https://127.0.0.1:18200'
$env:X2_KMS_TOKEN=Read-Host 'Root token' -MaskInput
& 'C:\Program Files\X2\x2-kms.exe' members add `
  --node-id kms-2 --peer-address 10.0.0.22:18201
& 'C:\Program Files\X2\x2-kms.exe' members list
# Unseal kms-2 locally with three original shares after catch-up
& 'C:\Program Files\X2\x2-kms.exe' members promote --node-id kms-2
Remove-Item Env:X2_KMS_TOKEN

export X2_KMS_ADDR='https://127.0.0.1:18200'
read -rsp 'Root token: ' X2_KMS_TOKEN; export X2_KMS_TOKEN
/usr/local/lib/x2/x2-kms members add \
  --node-id kms-2 --peer-address 10.0.0.22:18201
/usr/local/lib/x2/x2-kms members list
# Unseal kms-2 locally with three original shares after catch-up
/usr/local/lib/x2/x2-kms members promote --node-id kms-2
unset X2_KMS_TOKEN

Membership is persisted in Raft; do not hard-code a seed list or restart every existing member when adding a node.

Enable KMI on the X2 node

After the KMS workload grant is active, persist the values printed by workloads generate-identity in the node service environment and restart the node.

sudo install -d -m 0755 /etc/systemd/system/x2-node.service.d
sudo tee /etc/systemd/system/x2-node.service.d/kmi.conf >/dev/null <<'EOF'
[Service]
Environment=X2_KMI_ENABLED=true
Environment=X2_KMI_PROVIDER=x2-kms
Environment=X2_X2KMS_ENDPOINT=https://kms.example.com:18200
Environment=X2_X2KMS_WORKLOAD_ID=x2w-REPLACE
Environment=X2_X2KMS_SERVER_CERT=/var/lib/x2/state/secrets/kms-server.crt
Environment=X2_X2KMS_CLIENT_CERT=/var/lib/x2/state/secrets/node-1.crt
Environment=X2_X2KMS_CLIENT_KEY=/var/lib/x2/state/secrets/node-1.key
EOF
sudo systemctl daemon-reload
sudo systemctl restart x2-node

[Environment]::SetEnvironmentVariable('X2_KMI_ENABLED','true','Machine')
[Environment]::SetEnvironmentVariable('X2_KMI_PROVIDER','x2-kms','Machine')
[Environment]::SetEnvironmentVariable('X2_X2KMS_ENDPOINT','https://kms.example.com:18200','Machine')
[Environment]::SetEnvironmentVariable('X2_X2KMS_WORKLOAD_ID','x2w-REPLACE','Machine')
[Environment]::SetEnvironmentVariable('X2_X2KMS_SERVER_CERT','C:\ProgramData\X2\runtime\state\secrets\kms-server.crt','Machine')
[Environment]::SetEnvironmentVariable('X2_X2KMS_CLIENT_CERT','C:\ProgramData\X2\runtime\state\secrets\node-1.crt','Machine')
[Environment]::SetEnvironmentVariable('X2_X2KMS_CLIENT_KEY','C:\ProgramData\X2\runtime\state\secrets\node-1.key','Machine')
Restart-Service X2Node

sudo /usr/local/lib/x2/x2-node configure \
  --config /usr/local/etc/x2/node.yaml \
  --kmi-enabled --kmi-provider x2-kms \
  --x2-kms-endpoint https://kms.example.com:18200 \
  --x2-kms-workload-id x2w-REPLACE \
  --x2-kms-server-cert /usr/local/var/lib/x2/state/secrets/kms-server.crt \
  --x2-kms-client-cert /usr/local/var/lib/x2/state/secrets/node-1.crt \
  --x2-kms-client-key /usr/local/var/lib/x2/state/secrets/node-1.key
sudo launchctl kickstart -k system/com.edgedrive.x2-node

Verify the X2 startup banner reports KMI enabled. New credential envelopes and objects can then use KMS; enabling KMI does not silently rewrite previously stored unencrypted data.

Example single-member X2 KMS configuration

address: "0.0.0.0:18200"
storage_path: "/var/lib/x2-kms/store.json.enc"
cluster:
  node_id: "kms-1"
  address: "10.0.0.21:18201"
  storage_path: "/var/lib/x2-kms/raft"
  tls:
    certificate_file: "/var/lib/x2-kms/peer/kms-1.crt"
    private_key_file: "/var/lib/x2-kms/peer/kms-1.key"
    ca_file: "/var/lib/x2-kms/peer/peer-ca.crt"
tls:
  certificate_file: "/var/lib/x2-kms/tls/kms-server.crt"
  private_key_file: "/var/lib/x2-kms/tls/kms-server.key"
log_level: "warn"
request_timeout: "15s"
shutdown_timeout: "10s"

Raft peer TLS is a separate trust domain. Supply peer certificates issued by one KMS peer CA. Give every member a unique node ID, address, encrypted-store path, and Raft path.

Example X2 KMS workload grants

workloads:
  - name: "x2w-storage-production"
    client_keys:
      - spki_sha256: "sha256:REPLACE_WITH_64_HEX_DIGEST"
    grants:
      - key: "x2-workload-x2w-storage-production-session-signing"
        operations: [ensure-key, public-key, sign]
      - key: "x2-workload-x2w-storage-production-credentials"
        operations: [ensure-key, generate-data-key, decrypt-data-key]
      - key: "x2-workload-x2w-storage-production-default-objects"
        operations: [ensure-key, generate-data-key, decrypt-data-key]

HashiCorp Vault guide

Connect Vault Transit

Enable a dedicated Transit mount and authentication role. Grant only the signing and data-key operations required by the X2 key paths. Keep Vault credentials in the node secrets root.

Show Vault configurationProvider environment, authentication methods, and secure credential handling

Linux environment

export X2_KMI_ENABLED=true
export X2_KMI_PROVIDER=hashicorp-vault
export X2_VAULT_ADDRESS=https://vault.example.com:8200
export X2_VAULT_TRANSIT_MOUNT=transit
export X2_VAULT_AUTH_METHOD=approle
export X2_VAULT_ROLE_ID_FILE=/var/lib/x2/secrets/vault-role-id
export X2_VAULT_SECRET_ID_FILE=/var/lib/x2/secrets/vault-secret-id
export X2_VAULT_CA=/var/lib/x2/secrets/vault-ca.crt

Windows PowerShell environment

$env:X2_KMI_ENABLED='true'
$env:X2_KMI_PROVIDER='hashicorp-vault'
$env:X2_VAULT_ADDRESS='https://vault.example.com:8200'
$env:X2_VAULT_TRANSIT_MOUNT='transit'
$env:X2_VAULT_AUTH_METHOD='approle'
$env:X2_VAULT_ROLE_ID_FILE='C:\ProgramData\X2\secrets\vault-role-id'
$env:X2_VAULT_SECRET_ID_FILE='C:\ProgramData\X2\secrets\vault-secret-id'
$env:X2_VAULT_CA='C:\ProgramData\X2\secrets\vault-ca.crt'

macOS configuration

sudo /usr/local/lib/x2/x2-node configure \
  --config /usr/local/etc/x2/node.yaml \
  --kmi-enabled --kmi-provider hashicorp-vault \
  --vault-address https://vault.example.com:8200 \
  --vault-transit-mount transit \
  --vault-auth-method approle \
  --vault-role-id-file /usr/local/var/lib/x2/state/secrets/vault-role-id \
  --vault-secret-id-file /usr/local/var/lib/x2/state/secrets/vault-secret-id \
  --vault-ca /usr/local/var/lib/x2/state/secrets/vault-ca.crt
sudo launchctl kickstart -k system/com.edgedrive.x2-node

Also supported: Vault token-file and certificate authentication. Do not place tokens, Secret IDs, client private keys, or unseal material in node.yaml, consensus, the UI, or release manifests.

Provider status

Cloud KMS integrations

The KMI boundary supports provider adapters, but the current release deliberately rejects unsupported provider names instead of silently disabling encryption.

Compare provider supportX2 KMS, Vault, AWS, Azure, and Google Cloud identity and key-operation requirements

Provider	Status	Required identity model	Required operations
X2 KMS	Supported	Pinned client public-key ID	Sign and data-key transit
HashiCorp Vault	Supported	Token, AppRole, or client certificate	Transit sign/encrypt/decrypt
AWS KMS	Adapter required	Workload IAM role	Sign, GetPublicKey, GenerateDataKey, Decrypt
Azure Key Vault	Adapter required	Managed identity or federation	Sign and key wrap/unwrap
Google Cloud KMS	Adapter required	Workload identity	Asymmetric sign and symmetric data-key protection

Day-two operations

Update and operate with confidence

X2 updates are cluster workflows, not ad-hoc binary replacements. KMS maintenance remains deliberately separate from storage-node rolling updates.

Rolling x2-node updates

Publish a signed, immutable schema-v2 release.
Open Control → Updates.
Submit the HTTPS URL ending in /releases/<version>/manifest.json.
Review target OS, architecture, digest, signature, and node order.
Start the workflow and monitor drain, restart, catch-up, and convergence.

Never submit latest.json as an update target; use the immutable version manifest.

X2 KMS updates

Update KMS members one at a time during a separately authorized maintenance window. Preserve quorum, encrypted storage, TLS identities, client-key grants, and unseal custody. Every restarted member returns sealed and must be unsealed locally.

XC updates

Verify the new XC artifact, replace the client binary, and run xc --version. Existing aliases remain in the user configuration and are not part of cluster consensus.

Health and logs

systemctl status x2-node
journalctl -u x2-node --since today
curl --fail https://x2.example.com/health/ready

Get-Service X2Node
Get-WinEvent -LogName Application -MaxEvents 100
Invoke-WebRequest https://x2.example.com/health/ready

sudo launchctl print system/com.edgedrive.x2-node
tail -n 100 /usr/local/var/log/x2/x2-node.stderr.log
curl --fail https://x2.example.com/health/ready

Default network ports

8443/TCP: Public HTTPS, console, S3, API, MCP
9443/TCP: Inter-node mTLS mesh
18200/TCP: X2 KMS HTTPS API
18201/TCP: X2 KMS Raft peer traffic

Persistent paths

Linux: /etc/x2, /var/lib/x2, /var/log/x2
Windows: C:\ProgramData\X2
macOS: /usr/local/etc/x2, /usr/local/var/lib/x2, /usr/local/var/log/x2
KMS: Independent configuration, encrypted state, TLS, and logs

Security boundaries

KMS root token and shares remain with KMS operators.
Node enrollment tokens are single-use and short-lived.
Private keys and provider credentials remain node-local.
Normal startup never erases storage.

Reference

Common deployment questions

Can several X2 nodes run on one development machine?

Yes. Give every process unique --address, --public-url, --internal-address, --internal-advertise, state, log, metadata, and disk paths. Never share node state directories.

Can I change the bootstrap administrator password on restart?

No. Bootstrap credentials are consumed only when the administrator is first created. Change an existing password through IAM administration; passing another --admin-password on restart does not reset it.

What happens when KMI is disabled?

X2 remains functional for evaluation, but credential envelopes and object data are stored without provider-backed encryption. The banner and health information report that state explicitly.

Can an old multi-service cluster be upgraded in place?

No. This architecture uses a destructive clean-cluster migration with no legacy state import, compatibility runtime, or mixed-version support. Production erasure requires its own explicitly authorized cutover procedure.

Where is node.yaml documented?

x2-node configure writes the restart snapshot from command-line or environment values. Operators normally provide disks, metadata, administrator, listener, topology, TLS, and KMI settings through the CLI or environment instead of manually maintaining a large YAML file.