Skip to main content
The direct migration channel is available only when enabled for a managed v4 database. All routes require a scoped API key for that database. Responses have Cache-Control: no-store; metadata never includes a password. POST accepts only allowedAddresses (one or two exact public IPv4/IPv6 addresses), ttlMinutes (10–120), connectionLimit (1 or 2), statementTimeoutMs (60000–1800000) and lockTimeoutMs (1000–30000, less than the statement timeout). The server canonicalizes the IPs and verifies the current physical database OID, role-set generation and owner OID before it stores the request. The operator checks the global direct slot before native preparation. Pending reservations do not consume the direct-connection slot. An operator prepares and activates one lease at a time across the cluster in the first release. The active endpoint uses migrate.dbhost.app:5432 with sslmode=verify-full. The runtime connection continues to use PgBouncer. DELETE can return revoking while the operator removes only that lease’s HBA, host and cloud allowlist. A new request cannot bypass this reconciliation. A 404 FEATURE_NOT_AVAILABLE means the channel is not enabled; a 409 means the exact physical or provider state needs reconciliation before access opens. For tool setup and expiry behavior, see Direct database migrations.