-
Notifications
You must be signed in to change notification settings - Fork 70
Migration from CPA Manager
This guide is for users moving from the old seakee/cpa-manager project to seakee/cpa-manager-plus.
The goal is to preserve historical usage events, model prices, API key aliases, and saved CPA connection settings where possible.
| Old CPA-Manager | CPA Manager Plus |
|---|---|
seakee/cpa-manager |
seakee/cpa-manager-plus |
cpa-manager binary |
cpa-manager-plus binary |
| Usage Service | Manager Server |
| Full mode login with CPA Management Key | Full mode login with CPAMP admin key |
| CPA Management Key stored in old setup data | CPA Management Key encrypted with data.key
|
| CPA panel + external Usage Service URL | Not supported in Plus; use Manager Server-hosted panel |
Compatible endpoints such as /usage-service/info and /usage-service/config still exist, but they are Manager Server compatibility endpoints in Plus.
- Confirm CPA version. Recommended:
v7.1.39+; HTTP usage queue minimum:v6.10.8+. - Locate the old data directory or volume.
- Stop the old CPA-Manager service so SQLite WAL files are no longer being written.
- Back up the full old data directory, including:
usage.sqlite
usage.sqlite-wal
usage.sqlite-shm
- Decide the CPAMP admin key. Prefer setting
CPA_MANAGER_ADMIN_KEYorCPA_MANAGER_ADMIN_KEY_FILEexplicitly.
Old deployments commonly used:
services:
cpa-manager:
image: seakee/cpa-manager:latest
volumes:
- cpa-manager-data:/data
volumes:
cpa-manager-data:Start Plus with the same old volume:
services:
cpa-manager-plus:
image: seakee/cpa-manager-plus:latest
restart: unless-stopped
ports:
- "18317:18317"
environment:
HTTP_ADDR: "0.0.0.0:18317"
USAGE_DB_PATH: "/data/usage.sqlite"
CPA_MANAGER_DATA_KEY_PATH: "/data/data.key"
CPA_MANAGER_ADMIN_KEY: "replace-with-a-long-random-admin-key"
USAGE_COLLECTOR_MODE: "auto"
volumes:
- cpa-manager-data:/data
volumes:
cpa-manager-data:
external: trueDo not accidentally start Plus with a new empty cpa-manager-plus-data volume if you expect old data to appear.
Old example:
docker run -d \
--name cpa-manager \
-p 18317:18317 \
-v /srv/cpa-manager-data:/data \
seakee/cpa-manager:latestMigration:
docker stop cpa-manager
cp -a /srv/cpa-manager-data /srv/cpa-manager-data.backup
docker run -d \
--name cpa-manager-plus \
--restart unless-stopped \
-p 18317:18317 \
-v /srv/cpa-manager-data:/data \
-e CPA_MANAGER_ADMIN_KEY='replace-with-a-long-random-admin-key' \
seakee/cpa-manager-plus:latestThen open:
http://<host>:18317/management.html
and log in with the CPAMP admin key.
- Stop the old
cpa-managerprocess. - Back up the old program directory, especially
data/usage.sqlite*. - Extract the
cpa-manager-plus_<version>_<os>_<arch>package. - Copy the old
datadirectory into the new package directory, or setUSAGE_DATA_DIR/USAGE_DB_PATHto the old path. - Start with an explicit admin key:
CPA_MANAGER_ADMIN_KEY='replace-with-a-long-random-admin-key' ./cpa-manager-plusCheck startup logs:
- Save the generated
cmp_admin_...value if you did not setCPA_MANAGER_ADMIN_KEY - Confirm there are no SQLite, decrypt, or bootstrap errors
Then check:
curl -H "Authorization: Bearer <CPAMP_ADMIN_KEY>" \
http://<host>:18317/statusIn the panel:
- Open Configuration -> CPA Manager Plus Configuration
- Confirm the bound CPA URL
- Confirm request monitoring, collection mode, and polling interval
- Open Dashboard or Monitoring and verify historical data is visible
Plus adds:
/data/data.key
From now on, backups must include:
usage.sqlite
usage.sqlite-wal
usage.sqlite-shm
data.key
If data.key is lost, encrypted CPA Management Key values cannot be recovered.
Stop Plus before rollback.
The old CPA-Manager can read the main usage tables and old settings.setup, but it does not understand Plus admin credentials, bootstrap state, or data.key. Prefer rollback to the backup taken before first Plus startup.
- Old data is missing: Plus is probably using a new empty volume.
- Login returns 401: use the CPAMP admin key, not the CPA Management Key.
- Monitoring is empty: confirm CPA usage publishing, collector mode, CPA version, and that only one Manager Server consumes the queue.
- Decryption fails: confirm
data.keywas not lost or replaced.