Verifiable claims.

The password is needed only to open the first SSH connection and install a service user. It is passed as SSH authentication for our connection — not as a script argument or environment variable. Our database has no field for it; it does not enter script-run environments and is not written to logs (connection errors contain only the address and port, never the password). In memory it is wiped (best-effort) after use — that is defense in depth, not a guarantee: Go may keep copies of the value on the heap until garbage collection.

Honest caveat: this remains the root password on your server. After installation we disable password and root login over SSH, but we do not change the password itself — change it yourself if you wish. 'We don't store it' is true; 'it stopped being a secret' is not.

PasswordAuthentication no, PermitRootLogin no, SSH moved to a non-standard port (12011 by default), fail2ban enabled (a one-hour ban after 5 failures), login by key only. The public key is strictly validated before use: newlines (protection against slipping extra keys into authorized_keys) and syntactically invalid keys are rejected.

Anti-lockout: port 22 is not closed until the kernel confirms (via ss) that the new SSH port is actually listening; the config is checked with sshd -t and the sudo rule with visudo -cf, both rolled back on error.

The panel works not with your password but with a separate key (ed25519) that it generates itself. The private part sits in the database encrypted with AES-256-GCM. The encryption key (KEK) is stored separately from the database — in a server environment variable — and in production it is mandatory (there is no insecure default: without a KEK the crypto subsystem simply won't start). The same encryption protects the heavy secrets in the database — the Marzban admin password/token/JWT, Reality keys, payment-provider keys, the proxy-credential cache, backup config.

Encryption doesn't just hide but authenticates the data (GCM auth tag): tampering with an encrypted field is detected on decryption and rejected. Every field is encrypted with a fresh random nonce; the KEK value never reaches the logs — only its short id.

About capability tokens: the /sub subscription token is a bearer secret. For lookup we store only its SHA-256, while the copy needed to re-display an already-issued link is kept as AES-GCM ciphertext. Older plaintext records are migrated to the new format, fail-closed, before the HTTP server starts. The payment-webhook URL identifier is stored in the clear but does not by itself authenticate an event: authenticity is verified separately by an HMAC signature.

The key is decrypted only on the server, in memory; ordinary APIs never return it. The only way to obtain it is a deliberate export function ('take your key'), protected by sign-in plus a one-time email code (the code is stored only as an HMAC hash, compared in constant time, 10-minute TTL, 5 attempts). So the key can be retrieved intentionally, but not 'leaked' through a normal request.

Before the server's state changes and before any background network operations, the fields holding the management key are zeroed synchronously. If the database does not confirm the clearing, the operation returns an error and can be retried. The deletion remains 'soft': the row and non-secret service data are preserved. This does not mean physical erasure of backups already created — their lifecycle is governed by the backup retention policy.

Audited partner routes authorize by partner_id, which the server derives from the signed login token — not from what the client sent in the path or body. Before returning or changing anything, the system re-checks that the requested server, cluster, inbound, route, VPN user or payment belongs to your account; the corresponding database queries are scoped by your partner_id, and the schema (composite unique keys plus composite foreign keys) rejects invalid cross-partner links. Isolation is layered: application, usecase re-check, a partner_id filter, and the schema.

Honest caveat: this is verified by a code audit across the request path, not by a public penetration test — so SR-16, like the rest, is open to refutation in the bug bounty.

To configure everything automatically (install Xray+Reality, apply config, read metrics) the panel holds full administrative access on the server (root-equivalent, via a service user with passwordless sudo). This is necessary for management, and we do NOT call it 'limited'.

What reduces the risk: secrets are passed to the server only via the process's stdin (not as command arguments — they aren't visible in the process list); after the initial install, every management connection verifies the server's pinned host key — a server swap 'in the middle' is rejected. What you control: access rests on a key you can revoke at any time — by deleting the server (the key is zeroed) or simply deleting the VPS at your host (then everything disappears).

The VPN accounts themselves (VLESS/Reality) are created and live in Marzban on your master server. Centrally we store only what is required to issue a subscription link: a random subscription token and an encrypted snapshot of proxy credentials (a cache; the source of truth is your Marzban). We have no traffic, IP, or user visit history.

An end user's email address is not stored with us: their account name is derived irreversibly and contains no address. The sign-in code email is sent by us, so the address passes through our send queue and is removed from it right after sending — to recognise a returning user, only an irreversible fingerprint remains, and the address cannot be recovered from it. The one case where an address does settle we name directly: at payment it arrives in the payment webhook and enters the payment log with a limited retention window.

We keep this service data only as long as needed and clear it automatically: email is removed from the send queue right after sending, a payment event body after processing, and events awaiting retry within a 90-day window. You can delete your account together with its associated data by contacting support (see risk 7 for details). We disclose this openly rather than hiding it behind vague wording.

The CreateYourVPN platform does not receive or store information about which sites you or your users visit. The metrics-ingest schema is closed: it physically has no fields for IPs, domains, or visits — only aggregates (unique online count, total bytes, CPU/RAM/load). Each node authenticates with an HMAC token bound to its own id and can write metrics only for itself. The on-node balancer (HAProxy) works as a TCP router by SNI and does not decrypt traffic. On the server itself, system journals are retained for no more than about an hour and are not forwarded to syslog.

Beyond the platform level, the servers do not keep a visit journal either: Xray access logging is force-disabled on every config push (the platform sets log.access to none), so the edge proxy does not record which addresses users connect to. This is enforced in code and rolled out to the fleet.

To understand how the site and panel are used we apply Google Analytics (the cookie banner warns about cookie and statistics collection; details are in the Privacy Policy). There are no other third-party trackers: no Sentry, PostHog, Mixpanel, or ad pixels (verified by searching both frontends). The backend has no third-party telemetry at all. The end-user storefront is not covered by analytics at all — no GA, no trackers (verifiable from its sources).

Caveat: GA receives your IP (on Google's side) and the addresses of the panel pages viewed; panel URLs contain only a cluster identifier, not an email.

Payment and all card data are handled on the provider's side (Tribute / Lemon Squeezy). We only receive a signed webhook (HMAC-SHA256, constant-time comparison, verified before the body is parsed and before any database write: without knowing the secret, an event fails verification). We do not receive the full card number (PAN) or CVV. Redelivery of the same webhook (provider retries) does not cause a double grant — events are deduplicated.

Caveat: the provider may include card metadata (brand and last 4 digits) and the payer's name and email in the webhook body. The original body is needed by the worker until processing completes; after successful processing it is deleted together with the email hint. Events awaiting retry or manual review keep the original body only until the end of the retention window (90 days without activity), after which the card metadata and the payer's email are wiped automatically. 'There is no full card number' is true, but that is a property of the providers (we don't filter the body ourselves); 'we see nothing about the card at all' is not.

Email (needed for sign-in), last sign-in time, interface mode; for billing — balance and Telegram (for top-ups). The partner's IP is not stored in the database, and we keep no click or action history in the panel (apart from a short access log on errors).

The firewall denies incoming by default. Open outward: 443 (VPN, Xray+Reality), SSH on a non-standard port (12011 by default), and — on the master server — the Marzban admin panel port, only for control-plane IPs. Port 80 is opened separately only in Let's Encrypt mode for HTTP-01. Port 22 is closed after SSH is moved.

The node's management ports are open only to the master server's IP, not outward (a failure of this binding aborts the install). If the firewall does not become active, installation fails. ICMP echo is limited only for IPv4; we do not promise the server is 'invisible', and IPv6 ICMP is preserved for IPv6 to work correctly.

Unattended upgrades install security package updates automatically. Caveat: automatic reboot is deliberately disabled (so an unverified kernel doesn't reboot on its own) — which means fixes requiring a reboot (kernel, sometimes OpenSSH) apply only after a manual or scheduled reboot. 'Auto-patching' is true for userland, not for what requires a reboot.

We do NOT claim the server is 'invisible' or 'can't be scanned'. Port 443 is open and answers a TCP connection like any web server. The property 'on an incorrect connection it looks like an ordinary unrelated website' is provided by the Reality protocol inside Xray — a separate component we don't turn into an absolute.

Partner sign-in is by a one-time 6-digit code sent to email. There is no account password. This does not apply to internal credentials of managed components, such as the generated Marzban admin password. Codes are generated by a cryptographic generator; only their HMAC hash is stored, and comparison is constant-time. The code is single-use: on success it is deleted immediately (no replay); after 5 wrong attempts it is quenched early. The issuance rate limit is counted per email, not per IP — it can't be bypassed by switching addresses.

The session token sits in an HttpOnly and Secure cookie (JS can't read it), verified on the backend (not only at the edge). Idle timeout and auto-logout on inactivity are implemented on the client, not on the server. The token is signed with HS256; on verification we strictly reject any other algorithm (including 'none') — the classic algorithm-swap attack does not pass. The storefront token and the partner-panel token are separated by audience: an end-user token technically cannot reach the partner API (and vice versa). A deleted partner is rejected even with a live token.

Signing out ends the session on the server, not only in the browser: the token it was presented with stops being accepted, so a copy captured beforehand is useless afterwards. In the panel only the session you signed out from is affected — your other devices stay signed in; in the cabinet, signing out ends every session of that account. Sessions opened before this change carry no revocation marker and simply run out on their own.

There are no tokens in browser local storage (only UI settings); no secrets or the API address make it into the client bundle. Only the server (Next.js) places the token in an HttpOnly cookie. The browser talks to the core only through the server (Server Actions): the frontend does not call the API directly from the browser, and CORS does not allow browser reads of API responses from other origins.

Clarification instead of a former absolute: the API domain itself is a public host — technically you can open it from a browser, but without a session it returns no authorized data.

CreateYourVPN's public hosts are served over HTTPS with HSTS (max-age two years, includeSubDomains). Every web frontend we host — the platform site, the partner panel and partner storefronts, whether on our subdomains or on a partner's own domain — and the API domain send the same set of security headers: a Content-Security-Policy (default-src 'none' on the API; on the frontends it forbids embedding in an iframe and pins base-uri and form-action), X-Content-Type-Options: nosniff, X-Frame-Options, and a locked-down Referrer-Policy (no-referrer on the API; strict-origin-when-cross-origin on the frontends, which also send a restrictive Permissions-Policy).

This is live in production on all of those hosts and independently checkable — with any HTTP header inspector or a service like SSL Labs.