Infrastructure connection settings
Current enrolled Golf instance administrators can manage versioned connection profiles at Your account → Admin portal → Infrastructure (/admin/settings/infrastructure). The portable Compose environment defaults to PostgreSQL and can use the local RustFS object service; Cloudflare is optional. Actual deployment defaults are shown separately from saved profiles, with redacted endpoint/TLS/backend metadata and provenance. An unknown native database endpoint is shown as unknown rather than guessed local.
Save and test a connection
The page separates Databases and Object storage, each with current deployment metadata and a named saved-profile table. Choose Add database profile, Add object-storage profile, or Edit on a saved profile to open the relevant editor. Forms remain closed until an explicit action; the connection type is fixed by the section. Database profiles identify the Golf or native database role and a PostgreSQL endpoint. Object profiles identify RustFS, S3 or R2-compatible storage with endpoint, bucket, region, prefix and path-style settings. Explicit HTTP opt-in is limited to deployments that intentionally require it; use TLS for remote services.
Enter credentials through the private editor and confirm your current Golf administrator password for writes. Inventory responses never include passwords, access keys, secret keys, session tokens, encrypted ciphertext or full credential-bearing DSNs. Secrets clear on submission, cancel, sign-out and page hiding. Saved profile changes append immutable versions under an observed-head check rather than overwriting old versions.
Test connection is bounded. PostgreSQL testing pings the configured database; it does not apply migrations, move data or change either live pool. Object testing probes bucket accessibility; passing this metadata-only probe is not proof of conditional write/read behavior. A lost response requires inspection, without automatic mutation retries.
Activate private CI source storage
Object-storage profiles have an explicit password-confirmed activation action. Activation verifies a controlled immutable write and hash-checked read, then changes the active pointer with version and active-revision checks. The Active saved storage inventory displays the actual historical active version, label, endpoint and bucket, even when a newer profile head exists. Active indicators identify the effective binding. Deployment fallback and latest saved profiles remain separate; a newer saved head is not silently active. The activation editor identifies the current and proposed named versions and warns about the change before password confirmation. Verify and activate source storage performs the write/read verification; a bucket-only test does not replace it. New source bundles use the selected version. Existing runs preserve their provider/profile/version/key/hash binding and continue to need historical connection credentials.
Database activation is not available from this page. Saved database profiles show Saved · cutover required, with Edit/Test actions and no Activate action. The workflow is Add → Save → Test → operator-led migration and cutover. Current Golf database metadata reflects startup configuration; native endpoint metadata is operator-reported, not verified by its presence. An S3-compatible deployment fallback is not proof of a specifically qualified provider. Neither Golf’s application pool nor the forge database is switched by profile save/test. Runtime default environment credentials remain distinct from encrypted saved profiles.
Credential lifecycle and current gates
Profile secrets use the application credential keyring’s separate authenticated domain and immutable profile/version binding. Key availability, rotation and retirement include historical connection versions, even after a different destination becomes active. Keep those keys and credentials needed by existing objects and backups; see credential keyring maintenance.
Real RustFS qualification covers conditional create, identical replay, replacement rejection, concurrent first-write behavior, hash/cap checks and restart persistence. The combined native pipeline drill verifies bound object-backed sources across Golf and RustFS restarts. These checks do not qualify actual R2/S3 provider operation, live database cutover, Cloudflare container scheduling, HA, broad disaster recovery or Kubernetes restore.