Examples and Recipes

Legacy

Legacy SPGCLI (`spgctl`) recipes for existing automation.

Updated: March 5, 2026

Below are several legacy scenarios for existing automation built on SPGCLI (spgctl). For new user workflows, prefer Console and API.

1. Create a tenant, create a database, and connect immediately

spgctl tenant create --name acme
spgctl db create --tenant acme --name app --size L1
psql "$(spgctl db dsn --tenant acme --db app)"

If the database was in stopped, the first connection may take a little longer because of cold start.

2. Quickly check Control Plane availability

spgctl ping --json

This is a convenient health check for a local machine, CI runner, or jump host.

3. View the current state before a questionable operation

spgctl db describe --tenant acme --db app

Useful before deletion, migration, or investigation of a slow cold start.

4. Temporary database for CI

A typical workflow looks like this:

  1. create a separate tenant or use a dedicated CI tenant;
  2. create a temporary database;
  3. run migrations and tests;
  4. delete the database after the pipeline finishes.

Example:

spgctl db create --tenant ci --name test-$CI_PIPELINE_ID --size L1
# ... migrations / tests ...
spgctl db delete --tenant ci --db test-$CI_PIPELINE_ID --force

5. Get a DSN without assembling the connection string manually

spgctl db dsn --tenant acme --db app

This is safer and more convenient than manually substituting pg_user, pg_password, the Gateway host, and the database name every time.