Security

How to report a vulnerability in HourlyVPS systems, what we commit to in return, and what happens to your data when you delete a server.

Last updated

Effective date: October 2, 2026 · Version 1.0

In plain English

  • Found a vulnerability in our website, portal or platform? Email [email protected]. Our /.well-known/security.txt file lists the same contact.
  • Test only against your own account and servers, leave other customers’ data alone, and give us time to fix before you publish.
  • We acknowledge reports within 2 business days and keep you informed until the issue is resolved.
  • Deleting a server cannot be undone: its disk is deleted, and neither you nor we can recover it.
  • Your server is unmanaged: keep it patched, use SSH keys and keep backups outside HourlyVPS.

1. Report a vulnerability

Email [email protected] with:

  • what you found and where: the URL, the API endpoint or the component;
  • the steps to reproduce it, with requests and responses where they help;
  • the impact as you understand it;
  • how we can reach you.

Plain text is best. Write in English or Turkish. If you need to send something sensitive, say so in your first email and we will agree on a secure way to exchange it.

Our security contact is also published in machine-readable form at /.well-known/security.txt, following RFC 9116.

2. What is in scope

In scope

  • hourlyvps.com;
  • portal.hourlyvps.com, the customer portal, and its API;
  • our virtualization platform: isolation between customer servers, the control-panel functions such as the console, reinstalls and snapshots, and network controls such as DDoS mitigation.

Out of scope

  • Servers run by our customers. To report abuse from, or a vulnerable service on, a customer’s server, use Report abuse.
  • Services run by other companies that we use, such as our CDN or payment processors. Report those to the company concerned.
  • Denial-of-service and load tests, spam, and social engineering of our staff or customers.
  • Physical attacks on data centers or offices.
  • Scanner output without a demonstrated impact, for example a missing header or a software version on its own.

3. Rules for research

  • Use only accounts and servers that you own. You can create a server, test against it and delete it; the usual charges apply.
  • Do not access, change or delete data that is not yours. If you reach another customer’s data by accident, stop, do not keep a copy, and tell us.
  • Do not degrade the service for others: no denial of service and no mass automated requests.
  • Do not keep access longer than you need to show the issue, and do not leave backdoors or persistent changes.
  • Give us reasonable time to fix the issue before you publish. We suggest 90 days and will agree a date with you.

Research that follows these rules counts as authorized testing under our Acceptable Use Policy, which otherwise requires written permission for security testing.

4. What we commit to

  • We acknowledge your report within 2 business days.
  • We tell you whether we can confirm the issue, and we keep you updated while we fix it.
  • We tell you when it is fixed and, if you want, name you on this page.
  • We will not take legal action against research done in good faith under this policy.

We do not run a paid bug bounty at the moment.

5. How we protect the service

  • The website and the customer portal use encrypted connections (TLS).
  • Passwords are stored as hashes, never in readable form.
  • Access to customer data is limited to the people who need it for their work, and access to our systems is logged.
  • Network-level attack protection, including always-on DDoS mitigation, covers every server. See Network and hardware.
  • Card numbers never reach our servers; they go to our payment processor.
  • We do not access the contents of your server except in the cases listed in section 11 of our Terms of Service.

No system is perfectly secure. If a breach affects your personal data and the law requires us to tell you or a regulator, we will, as our Privacy Policy states.

6. What happens to your data when you delete a server

Deleting a server is immediate and cannot be undone. At that moment we delete the server’s virtual disk, and neither you nor we can recover it afterward.

The storage it used returns to the platform’s free pool. A new server, yours or another customer’s, starts with an empty disk and cannot read what a previous server stored.

The server’s IP addresses also return to our pool and may later be assigned to another customer, so remove DNS records that still point to them.

If we suspend a server for non-payment and the account is not topped up, or we terminate a service, the same deletion happens 7 days later, as section 11 of the Terms of Service describes.

Some records about a server outlive it, such as billing records and the record of which account used which IP address and when. Section 8 of our Privacy Policy lists how long we keep each of them.

Snapshots are a rollback tool, not a backup. Before you delete a server, copy anything you still need to storage outside HourlyVPS.

If your own rules require it, encrypt sensitive data inside the server, or overwrite it yourself, before you delete the server.

7. Keeping your own server secure

HourlyVPS servers are unmanaged: you are root, and the operating system and everything on it are yours to secure.

  • Log in with SSH keys and turn off password logins where you can.
  • Install security updates promptly.
  • Open only the ports you need, and keep a firewall on.
  • Use a strong, unique password for your portal account, turn on two-factor authentication, and keep API keys secret.
  • Keep backups outside HourlyVPS. Snapshots are not backups.

If your server has been compromised, tell us in a ticket. We may need to isolate it to stop it from harming others, as our Acceptable Use Policy explains.

8. Changes

We update this page when our process changes. The version and effective date are at the top.

From the blog

Your side of server security: hardening a new server, and retiring it without leaving data or keys behind.

All blog posts