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.

Public and private instances

You choose the reachability when you create the instance:

• Public — the instance is reachable over the internet at an address and port of its own. Pick how it's reached: a dedicated IP — its own floating address on the engine's native port — or a shared IP that rides the workspace's ingress address on a per-instance port. Dedicated is a paid-plan option; the Free plan uses a shared IP. Either way 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: MariaDB comes up without TLS, Memcached without TLS and without authentication. Create them as private instances and reach them from workloads on the same workspace network — the network isolation is the control that protects them, not anything in the engine. A public MariaDB would send credentials and data in clear text; a public Memcached would be open to anyone who finds the port.

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, reached by their internal name from inside the workspace network.

mariadb -h orders.acme.internal -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 — no authentication and no TLS; private instances only, reached by their internal name from inside the workspace network.

nc cache.acme.internal 11211

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; leave the password blank and one is generated. Passwords are shown on the Connection panel, so anyone with access to the workspace can read them — that's what roles are for.

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 and MySQL 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 instances can be backed up and restored from the dashboard — see Backups. Every other engine still has its public endpoint, so its own tooling works against it in the meantime:

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 — on-demand backup and restore for PostgreSQL
• API tokens — read connection details from a script instead of the dashboard