Connections overview

How Cocobox stores credentials, how connections move between users, and what isolation guarantees you can rely on.

Last updated

A connection is a configured pathway from Cocobox to one of your databases. It carries:

  • Coordinates — host, port, dialect, default database/schema.
  • Credentials — encrypted username + password (or key file), private to the workspace.
  • Network policy — direct, SSH-tunneled, or via SSL with a custom CA.
  • Access policy — who in the workspace can use it and at what role.
  • Audit trail — every connect, query, and share.

Each connection is independent. You can have one to staging Postgres, another to prod MySQL, and a third to a read-replica MariaDB — they don’t share credentials, they don’t share access lists, and they don’t share quota.

Encryption

Credentials are encrypted with AES-256-GCM using a key derived from your account. The derivation runs entirely server-side; even the engineering team cannot read the cleartext from a database dump or a memory snapshot. See Security for the full model.

Connection lifecycle

  1. Create — fill the form, test the connection, save. The credential is encrypted before it touches storage.
  2. Use — Cocobox opens a per-user, per-connection session pool. Pool size scales with concurrency, capped per workspace plan.
  3. Share — grant other users a role on the connection. Sharing is reversible in one click.
  4. Rotate — update the password without recreating the connection. Open sessions are drained and re-established.
  5. Revoke — delete the connection. Cleartext credential is not recoverable.

Roles

RoleCan readCan writeCan change creds
read✅ (SELECT only)❌❌
run✅ (only saved snippets reviewed by an editor)✅ (per snippet)❌
edit✅✅❌
admin✅✅✅

A guest with read access cannot run INSERT / UPDATE / DELETE / DDL, even if they paste it into the editor — Cocobox’s SQL gate rejects it server-side before the query reaches your database.

Read on