Security at VeloxaHost

Every organization runs in a separate project, and every call the platform makes on your behalf is scoped to your organization. Your containers, firewall rules, volumes and images live there, separate from everyone else's, with tenant isolation enforced:

• Containers run unprivileged, and low-level container options are blocked. Nesting is on, so Docker can run inside your server.
• GPU, PCI, USB and raw device passthrough are blocked.
• Your plan's CPU, memory, disk and instance counts are set as limits on your project, so one customer cannot take another's share.
• Outbound mail on port 25 is blocked for new servers by a network rule inside your own project.

Internal API calls between the platform and its compute hosts use TLS with client certificates (mutual TLS).

• Passwords are stored as bcrypt hashes and must be at least 10 characters, with upper- and lower-case letters and a number.
• Two-factor sign-in uses any TOTP authenticator app. Each code is accepted only once, so a code read over your shoulder cannot be replayed.
• Turning on two-factor gives you 10 one-time recovery codes. They are shown once and stored hashed.
• Organization owners can require two-factor for every member. Until a member sets it up, the console sends them to the setup page and the API refuses their requests.
• After 10 failed sign-in attempts (wrong password or wrong code) the account is locked for 15 minutes, on top of per-address rate limits.
• Sign-up, password reset and the public abuse form have a Cloudflare Turnstile bot check. When it is on and Cloudflare cannot confirm the visitor, the form is refused.

• Session cookies are HttpOnly, SameSite=Lax and Secure.
• Every console form carries a CSRF token. API writes made with a browser session are checked too; requests signed with an API key need none.
• Changing or resetting your password, changing your email address, or turning two-factor on or off signs out every other session and remember-me cookie.
• The console sends HSTS, a Content Security Policy with a per-request nonce and no unsafe-eval, and refuses to be framed.

• A key is shown once, when you create it. We store only a SHA-256 hash of it.
• Scopes are read or write per resource type: instances, networks, firewalls, storage, DNS, monitoring and more. A customer key can never carry admin scope.
• Each key can be limited to a list of IP ranges (CIDR) and given an expiry of 30, 90 or 365 days.
• API requests are rate-limited per key, and responses report the limit in X-RateLimit headers.

Credentials the platform has to keep, such as its internal client key, mail and payment credentials, and the passwords generated for marketplace apps you deploy, are encrypted in the database. A copy of the database alone does not hand them over.

Changes to your account, team and resources are written to an audit log with the user, the action, the resource, the time, the source IP address and the browser's user agent. You can read recent entries in the console, download them as CSV for a date range, or export them as CSV or JSON from the API.

Take snapshots of a server when you need them or on a schedule, and set a backup schedule per server. Any backup can be restored to a new server or downloaded, so you can keep a copy of your own. Managed websites back up on the schedule you set per site.

Spam, phishing, malware or attacks coming from an address or domain we host are handled through the abuse form. It needs no account. We match the report to the customer it concerns, the reporter's email address is never shown to that customer, and you get a reference number for follow-up.

If you believe you have found a security vulnerability in VeloxaHost, tell us privately at [email protected] so we can fix it before it is used against our customers. Please include:

• a description of the issue and its impact
• the steps, requests or proof of concept that reproduce it
• the affected URLs, API endpoints or resources
• how we can reach you with follow-up questions

While testing, please:

• Use only accounts and resources you own. Do not access, change or delete other customers' data.
• No denial-of-service or load tests, spam, social engineering or physical attacks.
• Give us a reasonable time to fix the issue before you disclose it publicly.

The full policy is at console.veloxahost.com/security. Machine-readable contact details are published as security.txt on the console and on this site. Abuse coming from a server we host is not a platform vulnerability: use the abuse form for that.

How we handle personal data is in the privacy policy and the data processing summary. Our uptime target is in the SLA, and current incidents and maintenance are on the status page.