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. Environments are stored in the platform database and persist across sessions and restarts; a fresh install is seeded with Development, Staging, and Production, which you can rename or remove. Names are unique. Deletion is blocked while any connection or script still 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, add, rename, and delete. Groupings are stored in the platform database, so one with no members still persists. Renaming cascades: every connection that belonged to the old name is updated in the same transaction, so membership is never orphaned. Deletion is blocked while any connection still belongs. Opening a grouping lists its connections as buttons, click one to see that connection's details and test it without leaving the page.

One database type per grouping and per environment. A grouping is deployed as a unit and a script is sent to every target in an environment, so both are limited to a single dialect. The first connection sets the type; connections of any other dialect are then greyed out with the reason, both when assigning to a grouping and when adding to an environment, and a grouping whose dialect clashes cannot be added to an environment. Simcha DB Studio does not translate a script between dialects, the script text is sent to each target as written, so a mixed environment would deploy Oracle syntax to a MySQL target and fail there.

A grouping that already mixes types, created before this rule, or by bulk import, is flagged on its card and in its detail with the types it holds, and cannot be assigned to an environment until it is split. Removing the connections that do not belong is always allowed, so a mixed grouping can be corrected in place.

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. Each connection card carries its engine's brand mark, so the fleet is scannable at a glance.

Bulk Upload

Import many connections at once with Bulk Upload on the Connections page: choose or paste a CSV or JSON file (a CSV template is downloadable from the dialog). Columns are name, type, host, port, database, username, password, environment, groupings, ssl; only name and type are required, and multiple groupings are separated with ;. Rows are validated in the browser for an instant preview and again server-side per dialect. Each row succeeds or fails independently, one bad row never blocks the rest, and every skipped row is reported with its reason. Reachability is not required at import time, so hosts the server cannot reach yet still import; use Test on each afterwards. Passwords are encrypted at rest exactly as with a single create.

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.