Temporary database access has sharp boundaries.

SSH forwarding, MySQL authentication, and deployment each require a separate fresh server-verified Turnstile action. Successful connection stages issue short-lived, one-use proofs bound to the relevant fields without embedding raw credentials.

The SSH flow requests only the exact forwarding channel. It does not open a shell, command, PTY, or file-transfer subsystem. The current host verification is trust on first use, not an operator-pinned host key.

Connection values are placed in an instance-specific Kubernetes Secret and supplied only to containers that need them. Passwords, passphrases, and private keys are not placed in URLs, Kubernetes labels or annotations, ConfigMaps, browser storage, API responses, or application logs.

Kubernetes Secrets are encoded, not inherently encrypted. The hosting environment must enable encryption at rest, restrict cluster and backup access, and audit privileged operations. mysql.odmin.biz cannot prove those cluster-wide controls to a visitor.

An ordinary public instance is bound server-side to the server and database credentials verified during provisioning. Logout and relogin, arbitrary servers, alternate credentials, custom connections, and connection switching are disabled in the product backend or its server-side guard, not merely hidden in the interface.

A random instance URL and its management page are bearer capabilities: anyone who learns one may use its authority. Keep them out of search queries, chat transcripts, public issues, screenshots, analytics, and shared bookmarks.

Public informational pages are crawlable. Admin, API, and bearer-management paths are omitted from the sitemap, disallowed in robots.txt, and served with no-index headers or metadata. These crawler hints reduce accidental discovery but are not an authentication mechanism.

Each launch creates managed namespaced Kubernetes objects with a random hostname, no Pod service-account token, bounded compute limits, ClusterIP routing, and ephemeral workspace storage. Shared instances explicitly reserve no CPU or memory; only a short-lived server entitlement can opt a public launch into a bounded CPU reservation. The service never creates persistent volumes.

Ordinary public workloads and credentials are scheduled for permanent deletion 60–75 minutes after creation. Use the private management page to delete sooner. Automatic expiry is a backstop, not a guarantee of immediate revocation.

The bearer URL is not user authentication; SSH uses trust on first use; public preflight replay tracking assumes one control-plane replica; infrastructure and destination systems can record network or database activity; and no system can promise complete confidentiality or availability.

Do not use the free service when you require a formal service commitment, durable workspace, regulated-data assurance, multi-user identity, or a pre-pinned SSH host key. See the Privacy Policy and Terms of Use for the full service statements.

Contact the operator through the public profile at github.com/hitrov. Do not put a password, private key, passphrase, bearer instance URL, or live exploit detail into a public issue. Revoke exposed credentials and delete the affected instance first.