Adding a VPS provider for dedicated Postgres

Dedicated plans need a VPS provider to spin instances up on. ImpulseDB Postgres supports four, all first-class: Vultr, Hetzner Cloud, DigitalOcean, and Linode. They all implement the same provider interface and the addon picks one per server at provision time. Configure all four if you want, and use whichever is cheapest in each region.

This article walks through what to set up. The full per-vendor token instructions live in the deep docs — link at the bottom.

What you need from each provider

For every provider you plan to use:

• An API token scoped to create and destroy instances (and, on most, manage volumes).
• An SSH key uploaded to the provider matching the SSH key path you set in Settings → SSH Key. Vultr, Hetzner, and DigitalOcean reference the key by ID, name, or fingerprint; Linode is the odd one out and takes the raw public key string on every provision.

Provider-specific footnotes worth knowing before you generate tokens:

• Vultr enforces IP allow-listing on the API endpoint. Add your WHMCS server's IPv4 under Account → API → API Access Control or every call will be rejected.
• Hetzner requires identity verification (passport / ID upload) once monthly spend climbs above roughly €100. Plan ahead if your fleet will scale.
• DigitalOcean caps fresh accounts at 100 GiB per volume and 100 GB total volume capacity. The API error is a generic 422: invalid size specified. Request a Resource Limits increase before provisioning a 1 TB database.
• Linode needs Linodes: Read/Write and Volumes: Read/Write scopes. Don't pick token scopes that try to resolve stored SSH key labels — the addon side-steps that by sending the raw key.

Where credentials are stored

Provider credentials are encrypted at rest through ImpulseCore's secret storage and decrypted in-memory at use time. They never appear in plaintext in WHMCS config, module tables, or log lines. The module reads them via the ImpulseCore::* facade rather than touching the secrets table directly.

This is the same store the rest of the Impulse modules use, so the same operator practices apply: rotate tokens on a schedule, and revoke old tokens at the provider after rotation.

How the test-on-save probe works

The save form runs a live API call against the provider before persisting the credentials. The call lists regions or pulls account info — something cheap and read-only — and reports a green tick or the exact error text. If the probe fails, the credentials aren't saved; you fix the token and try again.

You can re-run the probe later via Tools → Diagnostics → VPS Provider. That call exercises every configured provider and reports success plus a sample regions list. Run it after any token rotation.

Audit trail

Every credential add, rotation, and removal lands in ImpulseCore's audit log under the impulsepostgres source, with the actor (admin user id), action (provider.credentials.added, provider.credentials.rotated, provider.credentials.removed), and the provider key. The credential value itself is never logged.

Look in Addons → ImpulseCore → Audit to investigate when a token last changed.

Provider credentials vs per-host SSH/admin proxy credentials

Two different things, easy to conflate:

• Provider credentials — the API token. Used at provision time to create or destroy a VPS. After the host is online and Postgres is running, the provider token is not in the hot path.
• Per-host SSH and admin-proxy credentials — generated per host during cloud-init. The module uses these for all post-provision operations (running patches, taking backups, applying CVE fixes, restarting Postgres). The admin-proxy secret is per-region, never global.

Rotating a provider token has no effect on running Postgres hosts. Rotating a per-host SSH key does — that's a different workflow.

Related

• Provider credentials deep dive — per-vendor token instructions and gotchas
• Postgres plans overview