TLS and Certificates

SPG99 uses TLS on its external and key internal interaction points. For the user, the main rule is simple: connect with at least sslmode=require and do not rely on plaintext mode.

PostgreSQL connections through Gateway

Clients connect to Gateway — the single PostgreSQL entry point of the platform.

• Gateway accepts connections only over TLS.
• The minimum recommended mode is sslmode=require.
• For stricter validation, use verify-full with a correct CA chain.

Example DSN:

postgres://<pg_user>:<pg_password>@<gateway-host>:5432/<db-name>?sslmode=require

What happens inside Compute

Compute also works in a managed TLS model:

• the agent loads ready certificates from a secret or temporarily starts with self-signed certificates at an early startup stage;
• then, if needed, it obtains a signed certificate through the control plane;
• PostgreSQL is configured so that network access goes through hostssl.

This matters to the user because the database does not go through a stage of “started without TLS, then TLS was enabled.” Encryption is part of the normal startup scenario.

Password authentication

For client connections, a modern scheme is used:

• SCRAM-SHA-256

Therefore, in DSNs and applications use the normal tenant credentials pg_user / pg_password, not an API key.

Which sslmode to choose

• require — the minimum safe option: encryption is enabled, but without strict chain validation.
• verify-ca / verify-full — stricter modes for production environments that require certificate and hostname validation.

If you work in a self-hosted environment, make sure the clients have access to the correct CA chain in advance.

What is important to remember

• the API key is used only for the Control Plane API, Console, and CLI;
• only tenant PostgreSQL credentials belong in the DSN;
• plaintext connections to Gateway are not a normal scenario;
• if the client reports a TLS problem, first check sslmode, the CA chain, and the hostname, and only then the database itself.