Hosting Haven Logo
Hosting Haven
Grid Background

Security & Data Flow

Transparency about where data lives, who can access it, how we protect it, and how requests travel through our systems.

Where your data is stored

  • Billing data (Blesta)

    All data regarding account profiles, orders, invoices, payments, support tickets, and payment methods on our Blesta instance (billing.hostinghaven.us) is stored on hardware owned and maintained by Sparked Host LLC. Database and file backups are performed on a regular schedule (Daily), and regular security audits are performed Monthly.

  • Game server data (Nodes)

    Your server files and runtime data live on the node hosting your service. Nodes are mixed-use environments, meaning your data may reside on the same hardware as other customers' data. However, strict isolation measures are in place to protect your data. All plans are hosted on our ONST-01 node, owned and maintained by us, Hosting Haven.

  • Panel & control data (Pterodactyl)

    Server metadata, allocations, and user access are managed by our Pterodactyl panel (dashboard.hostinghaven.us), which is located on INF-01, owned and maintained by Crunchbits LLC (Synteq Digital).

  • Website & operational logs

    "Other than the server-side logs, we do not log any sensitive or questionable user data or activity that you (the client) cannot access."

How data is accessed

  • Staff

    Your gameserver files are only able to be accessed by our infrastructure developers (like 1 person), and your client data in the billing portal (Blesta) is limitedly accessible to support staff and higher ups to improve your support experience. Sensitive information like addresses, payment details, phone numbers, and other personal data is not accessible to staff without proper authorization.

  • Customers

    Access the billing portal (Blesta) and the game panel (Pterodactyl) are served over HTTPS with the help of CloudFlare. File access is via SFTP and the in-panel file manager/console, depending on your workflow.

How we keep it secure

  • Transport security

    All public endpoints enforce HTTPS/TLS. We use modern ciphers and HSTS where appropriate.

  • Edge protection

    Cloudflare provides DNS, CDN, WAF, and DDoS mitigation in front of some of our public services (Not including client servers).

  • Backups

    Routine backups of critical systems. Backup locations are access-controlled; encryption at rest is applied where supported.

Network Request Paths

This section is included to detail exactly where your network data travels during interactions with our services.

Billing Site

  1. Client connects over HTTPS to billing.hostinghaven.us (Blesta)
  2. Request travels over Cloudflare to origin server (Sparked Host).

Dashboard Site

  1. Client connects over HTTPS to dashboard.hostinghaven.us (Pterodactyl).
  2. Panel sends requests to Node via client's web browser - All traffic and requests are TLS encrypted.
  3. File transfers via the web interface use WSS directly to the node (Encrypted).
  4. SFTP transfers use a pure TCP connection to the node directly (Not encrypted).

Game traffic (Game servers)

  1. Player connects from their client directly to the server's IP:Port.
  2. TCP connections get sent from client, to the routing server (RackNerd), and forwarded to the node (ONST-01) 10k ports up with PROXY headers, and forwarded 10k ports down with the PROXY headers stripped and the origin IP replaced with the client's real IP.
  3. UDP connections get sent from client, to the routing server (RackNerd), and sent directly to the node without any processing.
  4. HTTP connections get sent from client, to the routing server (RackNerd), and sent directly to the node without any processing.
  5. HTTPS (WSS) connections get sent from client, to the routing server (RackNerd), and forwarded unencrypted via Wireguard to the node (ONST-01) 10k ports up with PROXY headers, and forwarded 10k ports down with the PROXY headers stripped and the origin IP replaced with the client's real IP as an HTTP request.
  6. We offer custom domains, which require the use of a single port across all of the custom domains. Here's how we do that.
  7. HTTPS (WSS) with custom domains (no specified port) are sent to the routing server, and the headers are scanned to determine the hostname (the domin the request was sent to). After the domain is determined, it's then matched up with our domain map, and internally sent unencrypted to the correct port on the node via wireguard.
  8. TCP (mc) requests with a custom domain (no specified port) are sent to the routing server, and a deep-packet inspection is done to determine the domain the client is connecting to, then also uses the domain map, and is internally sent to the correct port on the node via wireguard.

Data Flow Diagrams

Billing Site

ClientWeb Origin w/ TLS

Panel & Management

ClientPanel (HTTPS)Node (WSS)Node SFTP (TCP)

Game Traffic

ClientRouting ServerNode

See also: Privacy Policy, Service Level Agreement, Acknowledgements.

Have questions? Contact us. This page may be updated as our platform evolves.