spawn/cherry
A cf53ea1fb2
fix: use log_step (cyan) for in-progress messages instead of log_info (green) (#757)
Consistently use log_step for progress/status messages ("Waiting for...",
"Fetching...", "Creating...") and reserve log_info for success/completion
messages. This gives users a clear visual distinction between operations
that are still running (cyan) vs operations that have completed (green).

Also adds periodic progress updates to silent polling loops in ramnode,
cherry, and netcup IP wait functions so users see activity during long waits.

Agent: ux-engineer

Co-authored-by: A <6723574+louisgv@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-02-12 15:48:38 -08:00
..
lib fix: use log_step (cyan) for in-progress messages instead of log_info (green) (#757) 2026-02-12 15:48:38 -08:00
aider.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
amazonq.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
claude.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
cline.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
codex.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
continue.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
gemini.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
goose.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
gptme.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
interpreter.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
kilocode.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
nanoclaw.sh fix: replace log_warn with log_step/log_info for non-warning messages (#604) 2026-02-12 03:24:30 -08:00
openclaw.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
opencode.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
plandex.sh fix: use log_step (cyan) for progress messages instead of log_warn (yellow) (#534) 2026-02-11 14:37:43 -08:00
README.md feat: Add Cherry Servers cloud provider with openclaw and goose (#286) 2026-02-10 15:27:23 -08:00

Cherry Servers

Cherry Servers is a European cloud provider offering bare metal and cloud VPS with full root access, hourly billing, and a REST API.

Authentication

All Cherry Servers scripts require a CHERRY_AUTH_TOKEN environment variable.

Getting your API token

  1. Visit Cherry Servers Portal
  2. Click on your profile in the top right
  3. Navigate to API Tokens
  4. Create a new token or copy an existing one

Setting the token

export CHERRY_AUTH_TOKEN="your-token-here"

Configuration

Optional environment variables:

  • CHERRY_AUTH_TOKEN - API authentication token (required)
  • CHERRY_DEFAULT_PLAN - Server plan (default: cloud_vps_1)
  • CHERRY_DEFAULT_REGION - Deployment region (default: eu_nord_1)
  • CHERRY_DEFAULT_IMAGE - OS image (default: Ubuntu 24.04 64bit)
  • CHERRY_SERVER_NAME - Custom server hostname

Available Plans

Cherry Servers offers various cloud VPS and bare metal plans:

  • cloud_vps_1 - 1 vCPU, 2GB RAM, 40GB SSD (default)
  • cloud_vps_2 - 2 vCPU, 4GB RAM, 80GB SSD
  • cloud_vps_3 - 4 vCPU, 8GB RAM, 160GB SSD
  • Bare metal plans available through the API

View all plans: https://portal.cherryservers.com/

Regions

Available regions:

  • eu_nord_1 - Lithuania (default)
  • eu_west_1 - Netherlands
  • us_east_1 - USA East Coast
  • us_west_1 - USA West Coast
  • ap_southeast_1 - Singapore

Usage Examples

OpenClaw on Cherry Servers

export CHERRY_AUTH_TOKEN="your-token"
bash <(curl -fsSL https://raw.githubusercontent.com/OpenRouterTeam/spawn/main/cherry/openclaw.sh)

Goose on Cherry Servers

export CHERRY_AUTH_TOKEN="your-token"
bash <(curl -fsSL https://raw.githubusercontent.com/OpenRouterTeam/spawn/main/cherry/goose.sh)

Custom configuration

export CHERRY_AUTH_TOKEN="your-token"
export CHERRY_DEFAULT_PLAN="cloud_vps_2"
export CHERRY_DEFAULT_REGION="us_east_1"
bash <(curl -fsSL https://raw.githubusercontent.com/OpenRouterTeam/spawn/main/cherry/openclaw.sh)

How it works

  1. Authentication - Validates CHERRY_AUTH_TOKEN with Cherry Servers API
  2. SSH Key - Generates SSH key pair if needed and registers public key
  3. Project - Fetches your default project ID from Cherry Servers account
  4. Provisioning - Creates cloud VPS with specified plan, region, and image
  5. Connectivity - Waits for SSH access and cloud-init completion
  6. Agent Setup - Installs agent, injects OpenRouter credentials, launches interactive session

API Documentation

Pricing

Cherry Servers uses hourly billing with no long-term commitments. Prices vary by plan and region.

View current pricing: https://www.cherryservers.com/pricing

Notes

  • All Cherry Servers instances use root user for SSH access
  • Servers are created with your registered SSH key automatically attached
  • Full root access and IP-KVM available
  • Cloud-init is supported for automated setup
  • Servers can be managed via API, CLI (cherryctl), or web portal