Privacy policy
Private inputs need an honest boundary.
This policy explains what the mysql.odmin.biz launcher processes when it tests a connection and creates a temporary database-client instance.
Who operates this service
mysql.odmin.biz is part of odmin.biz. For privacy questions, access or deletion requests, and other contact, use the public operator profile at github.com/hitrov.
Data you submit
The launcher processes the selected client, MySQL hostname or IP address, port, username, password, and optional database name. If you enable SSH, it also processes the SSH username, host, port, private key, and optional key passphrase.
Submit credentials only for systems you own or are authorized to use. Prefer a dedicated, least-privilege database account and a restricted forwarding-only SSH account. The selected open-source client can perform any operation allowed by the database account you provide.
Connection checks
Before deployment, the server uses the submitted details for a bounded SSH forwarding test when selected and a MySQL authentication and ping test. Each stage uses a separate fresh Turnstile verification. A successful check creates a signed, one-use proof that expires after five minutes and contains a keyed binding rather than the raw credentials.
The SSH test opens only the requested forwarding channel; it does not request a shell, command, PTY, or file-transfer session. The current SSH implementation uses trust on first use rather than a preconfigured host-key pin.
Instance storage and deletion
Once provisioned, connection details are stored in an instance-specific Kubernetes Secret and supplied only to the containers that need them. The application does not put credentials in the generated URL, Kubernetes labels or annotations, ConfigMaps, admin API responses, browser storage, or application logs.
An explicitly enabled administrator-created unrestricted instance may store up to five additional SSH usernames, private keys, and passphrases in a second read-only Kubernetes Secret. Only the tunnel supervisor receives that Secret; the unrestricted tool receives the verified loopback routes and cannot read the keys. The database username, password, and optional database name are used only for preflight and final add-time verification and are not retained. The paired ConfigMap contains only destinations, entry kinds, generated IDs, loopback ports, generations, and timestamps. Both objects are deleted with the instance.
On any private restricted phpMyAdmin/Adminer, DbGate, CloudBeaver, or MySQL Shell GUI instance, an administrator may enable permanent profile management. The original connection is undeletable and counts toward a five-profile total. Added profiles are verified and stored in a dedicated Kubernetes Secret so the selected tool can reconnect to them; its ConfigMap contains only non-secret profile and routing metadata. Optional SSH keys remain in the separate supervisor-only Secret. Added profile credentials are removed when that profile or the whole instance is deleted.
Credentials remain available to the workload while its instance exists. Ordinary public instances and their Secrets are automatically deleted between 60 and 75 minutes after creation with no cancellation path. Public-created instances cannot become demos. Administrator-launched instances and their demos have no automatic expiry. The operator may still delete any instance and its resources earlier and without notice. The bearer management page also lets you recreate the Pod or delete your private instance and credentials at any time. Recreation terminates sessions and permanently clears current ephemeral Pod storage. Once an administrator publishes an instance as a public demo, its management page and management status are available only to the authenticated administrator, who can recreate or delete it. DbGate, CloudBeaver, and MySQL Shell GUI workspace storage is ephemeral and is also lost when a Pod is replaced or deleted. The service provides no backup or recovery.
Kubernetes Secrets are encoded but are not inherently encrypted. Cluster-level encryption, access control, audit data, and infrastructure backups are controlled by the hosting environment and may have separate retention.
Browser and URL handling
Passwords, private-key contents, passphrases, and preflight proofs remain only in the current form or component memory until submitted or cleared. The launcher does not write them to local storage or session storage. Your browser or password manager may still retain values under its own settings.
A URL fragment may prefill only reviewed non-sensitive connection fields and is removed immediately after parsing. Passwords, passphrases, private keys, proofs, and Turnstile tokens are ignored when supplied in a URL.
Bearer URL and tool sessions
The random instance URL is a bearer capability, not a user account or identity check. Anyone who learns it may access the selected client until the instance is deleted. Keep it private, close the browser session when finished, and use the bearer management page to delete the instance promptly. The selected database client may set necessary session cookies on its unique subdomain.
The same random ID authorizes a management page with health information, Pod recreation, and whole-instance deletion. For an explicitly enabled unrestricted instance, it also authorizes adding or deleting managed database routes. For an enabled private restricted instance, it authorizes adding or deleting verified permanent profiles. Both operations require the applicable Turnstile and connection checks. Do not share either URL.
An administrator can publish a dedicated ready admin-created instance as a public demo. Public demos intentionally lose bearer-URL secrecy and must use only a non-sensitive, read-only sample dataset. A public-created instance is never eligible for demo promotion. The demo management URL remains unchanged but requires administrator authentication. Do not enter private data into a public demo.
Request and infrastructure data
Loading the site and using an instance necessarily sends ordinary network metadata such as IP address, requested path, time, and browser headers to the delivery, ingress, and hosting infrastructure. The application does not add product analytics or intentionally log submitted connection secrets. Infrastructure, database, and SSH operators may keep their own security, access, authentication, audit, or query logs.
Service administrators can view the secret instance URL and non-secret deployment metadata and can delete or reconfigure managed workloads. The admin API does not read or return instance Secrets, but personnel with privileged cluster access may be able to access them as part of infrastructure operation.
Search visibility
Public home, tool-guide, privacy, security, and terms pages may appear in search engines. The operator may use Google Search Console or Bing Webmaster Tools to receive search-result information such as query, page, country, device, impressions, clicks, and average position. Those providers derive the reports from their own search services; mysql.odmin.biz embeds no analytics script, advertising tag, or search-console cookie and sends no launcher form value to them.
A public link to the related odmin.biz MySQL explorer makes no request until you click it. The destination then receives ordinary browser request metadata under its own Privacy Policy. The link contains no connection field or launcher capability.
Admin, API, and bearer-management paths are excluded from the sitemap and carry crawler restrictions. Those restrictions reduce accidental indexing but do not make a URL private. Never put a database host, username, credential, key, token, proof, or bearer instance URL into a search query.
Cloudflare Turnstile
The launcher loads Cloudflare Turnstile to distinguish legitimate requests from automated abuse. The browser runs Cloudflare code, and the server sends the one-time token and the trusted client IP when available to Cloudflare for verification. Cloudflare says Turnstile processes signals including client IP address, TLS fingerprint, user-agent header, site key, and associated origin. See Cloudflare's Turnstile Privacy Addendum.
Purpose, sharing, and rights
The data above is used only to validate requests, test the connection you selected, create and operate the requested instance, protect the service, manage capacity, and comply with legal obligations. It is shared only with the infrastructure and anti-abuse providers needed for those purposes, the destination systems you selected, or authorities when legally required. It is not sold or used for advertising.
Where data-protection law applies, processing is based on providing the service you requested and the operator's legitimate interests in security and reliable operation. Applicable access, correction, deletion, restriction, objection, and complaint rights are not limited by this policy. Because the service has no accounts, include enough non-secret context for the operator to identify the relevant record; never send a password or private key in a contact request.
Changes
This policy may change as the service or its legal obligations change. The date at the top identifies the current version. Material changes apply to later use of the service and do not reduce rights that applicable law makes mandatory.