Connecting

Once an instance reaches running, its Connection panel holds everything you need: host, port, database name, user, password, and a ready-to-copy connection URI. When our support team works in your account in a support session, the panel shows everything but the password.

Public and private instances

You choose the reachability when you create the instance, and can change it later from its Network tab:

• Public — the instance is reachable over the internet on your workspace's shared IP address, at a port of its own. Dedicated IP addresses, on the engine's native port, are not offered yet. The edge terminates the connection and opens a new one into your private network, so nothing else on the platform is exposed alongside it.
• Private — no public address, no public port. Only workloads on the same workspace network can reach it.

The examples below write the host as a sample name for readability. The address and port your instance actually answers on are the ones in its Connection panel — copy them from there.

A public instance is reachable from your laptop, your CI, and your app with no VPN or tunnel to set up.

TLS

Most engines come up with TLS on and a certificate installed: PostgreSQL and MySQL carry sslmode=require / ssl-mode=REQUIRED, Valkey uses the rediss:// scheme, RabbitMQ uses amqps://, and FerretDB and Qdrant expose TLS-only endpoints.

The certificate is currently self-signed — a platform-issued certificate for every instance hostname is on the roadmap. Until then, do not switch verification off to get past it (tlsAllowInvalidCertificates, curl -k, --insecure): an unverified connection is encrypted against a passive eavesdropper but not against anyone who can sit between you and the instance and present their own certificate. Pin the instance's certificate instead. Fetch it once, from a network you trust, and keep the file with your application's configuration:

openssl s_client -connect docs-c3d4.db.sahabti.app:40018 -servername docs-c3d4.db.sahabti.app </dev/null 2>/dev/null | openssl x509 -out docs-c3d4.pem
openssl x509 -in docs-c3d4.pem -noout -fingerprint -sha256   # note it; it should never change unexpectedly

A pinned self-signed certificate is verified exactly like a CA-signed one — the client only accepts that one certificate. The FerretDB and Qdrant examples below pass the pinned file.

MariaDB and Memcached are the exceptions: both come up without TLS. Both ask for a user and password (Memcached over SASL), but the connection itself is not encrypted: your data crosses it in clear text, and so does Memcached's password. Create them as private instances and reach them from workloads on the same workspace network — the network isolation is what keeps that traffic private, not anything in the engine. The create form starts both as Private, and the console warns you before either one is made public. A public MariaDB or Memcached would send that traffic across the internet.

Per engine

Copy the exact values from the Connection panel; the commands below show the shape.

PostgreSQL

psql "host=orders-c3d4.db.sahabti.app port=40012 dbname=orders user=orders sslmode=require"

MySQL

mysql -h orders-c3d4.db.sahabti.app -P 40013 -u orders -p --ssl-mode=REQUIRED orders

MariaDB — no TLS; private instances only. Connect from inside the workspace network to the private address on its Connection panel; a web app can also use its internal name, such as orders.acme.internal for an instance orders in the workspace acme.

mariadb -h 10.81.0.12 -P 3306 -u orders -p orders

FerretDB — MongoDB-wire, TLS on. tlsCAFile pins the certificate you fetched above.

mongosh "mongodb://app:[email protected]:40018/?tls=true&tlsCAFile=docs-c3d4.pem"

Qdrant — REST/gRPC over TLS. --cacert pins the certificate; verification stays on.

curl --cacert search-c3d4.pem https://search-c3d4.db.sahabti.app:40019/collections

Valkey

valkey-cli -h cache-c3d4.db.sahabti.app -p 40015 -a "$PASSWORD" --tls

Memcached — the user app and the password on the Connection panel, over SASL; no TLS. Private instances only, reached like MariaDB: at its private address, or by its internal name from a web app. SASL runs over Memcached's binary protocol, so turn that on in your client along with the user and password; the panel's connection string carries them in a memcached:// URL. memcstat, from the libmemcached tools, checks the login:

memcstat --servers=10.81.0.13:11211 --binary --username=app --password="$PASSWORD"

RabbitMQ — TLS on; plaintext AMQP is disabled.

amqps://app:[email protected]:40017

Credentials

For SQL engines you can set the database name, user, and password at create time, and for Valkey and Memcached the password; leave the password blank and one is generated. Passwords are shown on the Connection panel to owners, admins and developers; a viewer sees the address, port and user, with the password replaced by ******** — that's what roles are for. A game server's RCON password follows the same rule.

Rotating the primary credential from the dashboard isn't available yet. Change it inside the engine (ALTER USER, SET PASSWORD) and keep your own copy; the panel still shows the value the instance was provisioned with.

On PostgreSQL, MySQL and MariaDB you can avoid the problem: give each application and teammate their own account from the instance's Database users tab, and drop it when you're done instead of rotating one shared password. See Database tools.

Backups

PostgreSQL, MySQL and MariaDB instances, and game servers, can be backed up and restored from the dashboard, and the three SQL engines can export a dump you download — see Backups. The engines' own tools work against an instance's endpoint too:

pg_dump "host=orders-c3d4.db.sahabti.app port=40012 dbname=orders user=orders sslmode=require" > orders.sql

Deleting an instance is permanent, and a restore reads the source instance, so take a backup before you do.

Next steps

• Database tools — browse and query without a client
• Backups — backups, restores, export and import
• API tokens — read connection details from a script instead of the dashboard