Environments & Repository Sources

This page covers the deployment-target model, environments, groupings, connection configuration, transport/security options, and the on-demand repository/storage sync integration.

Environments

Environments are user-defined deployment targets with no hardcoded taxonomy, model whatever your pipeline needs (Development, QA, Staging, Production, DR, UAT, Sandbox, Demo). Admins and release managers manage them from the dedicated Environments page: a sortable table of name, approval requirement (whether deploys to it require sign-off), and connection count, with add/delete. Deletion is blocked while any connection references the environment, reassign first.

Groupings

Groupings are logical clusters a connection can belong to, and unlike environment (one-to-one), a connection can be in multiple groupings. Model "all Postgres clusters", "tenant shard A", "us-east", etc., for set-wise deployment and reporting. Managed from the Groupings page (admin / release_manager) with usage counts and add/delete.

Connection Configuration

Each environment is backed by one or more connections. Add via Connections: pick dialect, supply host/port/database/credentials, optionally assign an environment and groupings, optionally mark Read-only, Test Connection for reachability, save. Connections persist through the shared /api/connections endpoint, so the IDE and Database DevOps see one list, saving once enables both interactive querying and unattended deployment.

Import from the IDE

The Manager and IDE keep independent connection lists. Import (beside Add Connection) lists IDE connections not already configured here and creates an independent copy; targets you already hold are never offered and re-imports are skipped, so import cannot duplicate. The reverse (DevOps → IDE) is available from the IDE sidebar.

Read-only Connections

Marking a connection Read-only makes the server refuse INSERT/UPDATE/DELETE/DDL and change-script runs before they reach the database, while leaving reads, EXPLAIN, and schema browsing available. The block is enforced application-side on top of the account's own grants, protecting even privileged logins; such connections carry a Read-only badge.

Environment Color-Coding

Each connection's environment renders as a risk-tiered badge, production red, staging amber, development/test green, everywhere an environment appears (Connections list, Environments page, execution history). Matching is case-insensitive and prefix-based ("Production", "prod", "PROD-eu" all tier alike).

Advanced: TLS, Timeouts & Credentials

The Advanced section tunes how a SQL-engine connection (PostgreSQL, MySQL/MariaDB, SQL Server) is opened and run; engines that don't use a setting ignore it.

• SSL/TLS mode, Disable, Require (encrypt, no cert verify), Verify CA / Verify full (verify chain against the system trust store). Existing connections retain prior behavior until changed.
• Connect timeout, seconds to wait when opening.
• Statement timeout, server-side cap per statement; blank for none. A strong rail for shared/production targets.
• TCP keep-alive, keeps idle sockets alive through firewalls/NAT.
• Save password, on by default; when off, the password is verified at save but never stored (re-entered per connect, not persisted). Leave on for targets that deploy change scripts unattended.

SSH Tunnel (Bastion / Jump Host)

Connect through an SSH tunnel reaches databases only accessible inside a private network. Supply bastion host/port, SSH username, and an SSH password or private key (PEM, optional passphrase); the Host/Port fields then resolve from the bastion's perspective (typically the database's private address). The tunnel serves both interactive querying and unattended execution and is torn down on disconnect. SSH credentials are encrypted at rest and masked in API responses, like database passwords.

Idle Auto-Disconnect (Operator)

CONNECTION_IDLE_DISCONNECT_MIN closes pooled connections (and any backing SSH tunnel) after N minutes idle; unset or 0 disables. Server-wide, not per-connection.

Connection Security

• Passwords encrypted at rest in the metadata database.
• TLS for all production/staging targets.
• Read-only where scripts must never write, app-enforced, atop account grants.
• Least-privilege, per-environment database users.

Deployment Pipelines

Development -> QA -> Staging -> Production -> DR

At each stage the release deploys to that environment's connections, the team validates, an optional approval gate guards promotion, and the same release (same scripts, versions, hashes) advances, no inter-stage modification.

Repository & Storage Sources

Sync migration scripts on demand from source control and object stores. Add from Connections → Add Connection → Repository & Storage Sources: pick source type, supply credentials, set Release Path, Ad-hoc Path, and File Pattern (default *.sql), test, save.

Source Control

Object Storage

Path & Pattern Model

Each source scopes two directories, Release Path (e.g. db/migrations/release) and Ad-hoc Path (e.g. db/migrations/adhoc), and a File Pattern glob (*.sql, V*.sql, *.migration.sql) selecting migration files within them.

On-Demand Sync

Sync is explicit: Scripts → Upload Scripts → Pull from Repository → choose source → Sync lists matching files → select a subset. Imports land in Draft with the filename as name. There is no background poll.

Failure Modes

• Auth failed, credential scope: GitHub needs repo; GitLab needs read_repository.
• No files, paths are relative to repo root (source control) or bucket root (storage); verify the pattern.
• Timeout, large-repo first sync; check connectivity from the server to the provider.
• Rate limiting, provider API caps on frequent sync; the error names the condition.