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.

Partner API key secrets are stored irreversibly: the full key is shown only once, when it is issued, and the database keeps the SHA-256 of its secret part. Access and refresh tokens for connected AI are not stored in plaintext either; a connection is limited to the selected access level and can be revoked by the account owner.

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.

In panel routes, partner_id is derived from the signed session; in the Partner API, from a verified API key or AI OAuth connection. The owner identifier is not taken from the path, query parameters or request body. API keys are additionally limited by scope, expiry and plan; for a connected AI, the set of permissions is computed on every request from the level chosen by the owner.

Before returning or changing anything, the system re-checks that the server, cluster, inbound, route, VPN user or payment belongs to this account. Database queries are scoped by partner_id, and composite unique and foreign keys reject invalid cross-partner links. The authorization matrix in the tests requires an explicit IDOR scenario for every endpoint with a resource identifier.

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 all of its data yourself, in Advanced settings, by confirming with a code from your email (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). On OAuth consent pages, loading of analytics is forcibly disabled: the URL contains a short-lived identifier of the AI connection request, which must not be passed to a third party. There are no other third-party trackers: no Sentry, PostHog, Mixpanel, or ad pixels. The backend has no third-party telemetry, and end-user storefronts are not covered by analytics.

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 side of the connected provider (lava.top). We only receive a verified webhook event: its authenticity is established, by the method the specific provider supports, before the balance or access is changed. We do not receive the full card number (PAN) or CVV. Redelivery of the same event 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.

For the account we store the email, last sign-in time, interface mode and settings; for billing — balance and Telegram, if one is provided for top-ups. To protect the account, an active session contains its creation and last activity times, IP address and user agent. The history of successful and failed sign-in attempts, with the same technical attributes, is kept for 90 days.

There is no general click history for the panel. Separate, purpose-specific logs do exist: Partner API requests — no more than the latest 500 entries and about 25 hours; infrastructure events and diagnostic results — no more than 7 days; connected AI actions — kept together with the account. Before AI actions are recorded, passwords, tokens, keys and subscription links are removed, and users' emails are masked.

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 server admin password. Codes are generated by a cryptographic generator; only their HMAC hash is stored, and comparison is constant-time. On success the code is deleted immediately, and after 5 wrong attempts it is quenched early. The issuance rate limit is counted both per full address and per underlying mailbox: a change of IP, dots in a Gmail address and plus tags do not yield a separate limit.

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.

Every partner session has a stable server-side identifier that is preserved when the token is renewed. A normal sign-out revokes the entire current session, not just one issued token. The “Account sessions” section shows the device, IP address, sign-in time and last activity; any session can be ended individually. The “Sign out everywhere” action ends all sessions and disconnects connected AI services.

The sign-in history is kept for 90 days and shows successful sign-ins, wrong and expired codes, and exceeded attempt limits. If there are signs that an already exchanged token is being reused, the system treats the session as copied, ends all sessions and AI connections, and sends the owner a notification.

There are no session tokens in browser local storage, only interface settings. The token is placed in an HttpOnly cookie by the Next.js server layer; the browser does not receive the internal backend address and reaches the backend through Server Actions. CORS does not allow other origins to read API responses containing authorized data.

There are deliberate exceptions controlled by the owner themselves: exporting the private SSH key after a code from an email (SR-4), and a new Partner API key, whose full secret is shown in the browser once, at creation. After that it cannot be recovered from the database — only a hash remains there. The public API domain is reachable from the internet by design, but without a valid session, API key or OAuth token it returns no protected 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.

An AI app connects via OAuth and does not receive your panel's cookies. On the consent page you choose one of three levels: view only; view and configure; delete and grant access. Permissions are checked by the server on every call. Critical deletions require an additional one-time code from an email, and the whole connection can be revoked in the “Connected AI” section.

Every tool call is recorded in a log visible to the owner, together with its result and a safe copy of the arguments. Passwords, tokens, API keys, private keys and subscription links are stripped out before recording; users' emails are masked. The chosen AI app nevertheless remains a third-party service: data you have deliberately asked it to read or change is also processed under its provider's rules.