> **Superseded 2026-09-10:** host now manages this server with its OWN key
> (server id `server263`). The `vbm-launch-20260903` key described below was removed from the
> panel and must not be re-added. Make live changes through host (`srv-gw live-wp --project
> villasatbluemountain -- …`, see `/srv/CLAUDE.md`), never by SSH from a session.

# Onboarding server263 into host.bowden.works

Everything needed to register the Hartling hosting account. Facts gathered live over SSH
2026-09-03, not assumed.

## Platform classification

The `platform_kind` enum in `app/models/hierarchy.py` allows:
`cloudways · flywheel · digitalocean · wpengine · rocketnet · generic`

This host is a branded shared control panel (SureSupport-style), not any of the named
providers, so it registers as **`generic`**. That means no provider API discovery, and the
gateway talks to it over plain SSH.

## Account

| Field | Value |
|---|---|
| platform | `generic` |
| slug | suggest `hartling-server263` |
| name | suggest `Hartling Group (server263)` |
| credential_ref | the gateway key name, see SSH key below |
| notes | panel at https://panel.server263.com, hosting account `bluemountain` |

Account contact emails on the panel are currently `account@adventurescape.com` and
`gab@adventurescape.com`, both the outgoing developer's. Worth changing.

## Server

Gateway registry entry (`servers.<id>` in the sync registry). `Server.slug` in hosting-web
must equal this gateway server id.

| Field | Value |
|---|---|
| id / slug | suggest `server263` |
| name | `server263 (Hartling)` |
| provider | `generic` |
| enabled | `true` |
| is_passthrough | `false` — this host has a real server tier |
| ssh.host | `server263.com` (resolves to `192.252.144.13`) |
| ssh.port | `22` (confirmed) |
| ssh.default_user | `bluemountain` |
| ssh.key_ref | defaults to the server id, so `server263` |

**Password auth is disabled on this account — key only.** That is already handled: a
dedicated ed25519 keypair was generated and its public half imported through the panel
(SSH Access > SSH Keys, comment `vbm-launch-20260903`).

## The SSH key — the one manual step

The gateway looks for the private key at `SYNC_KEYS_DIR/<key_ref>.key`. The private key
currently lives on mosiah at `~/.ssh/vbm_server263` (0600, no passphrase).

To register, that file needs to be copied to the gateway's key path as `server263.key` with
0600 permissions. **Do not paste the key anywhere** — copy the file directly. The public
half is already installed on the host, so nothing needs doing on the remote side.

If you would rather the gateway generate its own key, `srv-gw sync-server-pubkey` /
`hosting-server-pubkey` hands back a public key to add through the panel instead, and the
key we made can be deleted from the panel.

## Sites on this server (3 WordPress installs, all WP 7.1, all `wp_` prefix)

| project | live_url | path | database | notes |
|---|---|---|---|---|
| `villasatbluemountain` | https://villasatbluemountain.com | `~/www/www` | `bluemountain_re` | **the live site** |
| `vbm-luxury` | https://luxury.villasatbluemountain.com | `~/www/luxury` | `bluemountain_wp05ac2c7d208868338f86f8932fa7f5fe` | retired, now 301s to live |
| `vbm-rentals` | https://rentals.villasatbluemountain.com | `~/www/rentals` | `bluemountain_wp` | old rentals site, still live |

Per-site `remote` block for the registry:

    "remote": {
      "ssh_user": "bluemountain",
      "wp_path":  "/home/bluemountain/www/www",
      "wp_cli":   "/usr/local/bin/wp",
      "key_ref":  "server263"
    }

`wp-cli` is at `/usr/local/bin/wp` and PHP 8.1 at `/usr/local/php81/bin/php`, both confirmed
working against all three installs.

## Recommendation on which sites to add

Add **villasatbluemountain** as a normal managed site. Add **vbm-rentals** as
`monitor_only` until it is retired. I would not add **vbm-luxury** at all now that it only
serves redirects, or if you want it tracked, add it monitor-only so nobody pushes to it by
accident.

## Two things worth knowing before you rely on it

1. **Network tools are disabled** on this hosting account (curl, wget, rclone are all off in
   the panel under SSH Access). Anything in the sync engine that expects the remote end to
   fetch over HTTP will fail here until that is switched on.
2. **Server-side page caching is on** for the main domain and it is aggressive. Nothing
   looks changed until it is purged, which is exactly what made the launch look broken. If
   the dashboard ever does deploys here, a cache purge belongs in the post-deploy step.

## Account resource context

Disk 23GB of 102GB. 3 MySQL databases, 3 FTP accounts, 17 mailboxes, 2 subdomains
(`luxury`, `rentals`), 1 parked domain (`bluemountain.tc`). Nameservers ns1/ns2.server263.com.