The moment you start a new server, bots can (and will) discover and scan it. Most of the attacks are lazy: the bots are looking for password logins and default admin accounts.
Do these two things to protect yourself:
→ SSH keys instead of passwords. A bot can guess a password. It cannot brute-force a key.
→ A normal user with sudo instead of root for everything. One compromised session shouldn't hand over the whole machine.
Keep your system up to date to prevent bugs from being exploited, run a firewall, and let fail2ban ban the repeat knockers.
Full 6-step walkthrough with every command: https://www.doprax.com/tutorial/how-to-secure-a-new-linux-server-in-6-steps
Do these two things to protect yourself:
→ SSH keys instead of passwords. A bot can guess a password. It cannot brute-force a key.
→ A normal user with sudo instead of root for everything. One compromised session shouldn't hand over the whole machine.
Keep your system up to date to prevent bugs from being exploited, run a firewall, and let fail2ban ban the repeat knockers.
Full 6-step walkthrough with every command: https://www.doprax.com/tutorial/how-to-secure-a-new-linux-server-in-6-steps
5 Commands to Check a New VPS
You just got SSH access to a new server. Before you install anything, spend two minutes confirming you got the configuration you need:
1. Check the OS image you actually got (cat /etc/os-release)
2. Confirm the specs (nproc, free -h; df -h)
3. Look at your IP addresses (ip -4 addr show; ip -6 addr show)
4. See what is already listening (ss -tulpn)
5. Test disk write speed (dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=dsync; rm /tmp/test)
Full tutorial here: https://www.doprax.com/tutorial/5-commands-to-check-a-new-vps
You just got SSH access to a new server. Before you install anything, spend two minutes confirming you got the configuration you need:
1. Check the OS image you actually got (cat /etc/os-release)
2. Confirm the specs (nproc, free -h; df -h)
3. Look at your IP addresses (ip -4 addr show; ip -6 addr show)
4. See what is already listening (ss -tulpn)
5. Test disk write speed (dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=dsync; rm /tmp/test)
Full tutorial here: https://www.doprax.com/tutorial/5-commands-to-check-a-new-vps
Shared vCPU vs Dedicated vCPU
Two VPS plans can both say 4 vCPU and cost very different amounts. One word (shared/dedicated) on the pricing page explains why.
Shared: Your vCPUs sit on physical cores that other customers also use. When the host is quiet you get close to a full core. When several machines get busy at once, your process waits. Cheap, and fine for most workloads.
Dedicated: The cores are reserved for your VM only. Same clock speed as a shared core, so it is not faster. It stays the same speed when the host gets busy. Usually costs two to three times more.
Full post with the sysbench test and which workloads need which plan: https://www.doprax.com/tutorial/shared-vcpu-vs-dedicated-vcpu-explained
Two VPS plans can both say 4 vCPU and cost very different amounts. One word (shared/dedicated) on the pricing page explains why.
Shared: Your vCPUs sit on physical cores that other customers also use. When the host is quiet you get close to a full core. When several machines get busy at once, your process waits. Cheap, and fine for most workloads.
Dedicated: The cores are reserved for your VM only. Same clock speed as a shared core, so it is not faster. It stays the same speed when the host gets busy. Usually costs two to three times more.
Full post with the sysbench test and which workloads need which plan: https://www.doprax.com/tutorial/shared-vcpu-vs-dedicated-vcpu-explained
OVH is increasing prices starting in October. Just like with Hetzner’s earlier price increase, the reason are rising RAM prices. Whether (and to what extent) it will affect your Doprax costs will depend on the instances you're using. We will soon follow up with more information.
Full blog post: https://www.doprax.com/blog/ovhcloud-is-raising-prices-up-to-87-percent
Full blog post: https://www.doprax.com/blog/ovhcloud-is-raising-prices-up-to-87-percent
Two exciting news:
1. You can now resize ProVM if you need more RAM, storage, or CPU. To resize your VM, click on the “Resize” tab, and pick your desired configuration.
2. You can add up to 5 new IPs to your VM! To add a new IP, navigate to the “Network” tab, and click “Add IP”.
1. You can now resize ProVM if you need more RAM, storage, or CPU. To resize your VM, click on the “Resize” tab, and pick your desired configuration.
2. You can add up to 5 new IPs to your VM! To add a new IP, navigate to the “Network” tab, and click “Add IP”.
VPN apps collect data about their users. That’s because in addition to offering a tunnel, they also have an account system. That system belongs to the VPN provider, and it can store all kinds of data about you.
You can remove that risk entirely by self-hosting your VPN.
Read more in our blog: https://www.doprax.com/blog/the-data-your-vpn-app-collects-can-become-a-liability
You can remove that risk entirely by self-hosting your VPN.
Read more in our blog: https://www.doprax.com/blog/the-data-your-vpn-app-collects-can-become-a-liability
We’ve reactivated the “pay by card” payment method!
You can now pay with credit card, Google Pay, or Apple Pay. Check out your dashboard’s “add credit” tab: https://www.doprax.com/v/billing-new/top-up/
You can now pay with credit card, Google Pay, or Apple Pay. Check out your dashboard’s “add credit” tab: https://www.doprax.com/v/billing-new/top-up/
As we mentioned previously, ProVM now supports up to 5 additional IPs per VM, which means separate services, isolated clients, and blue-green deploys all fit on one machine. Fewer VMs to patch, same separation where it counts.
What you can do with additional IPs, full blog post:
https://www.doprax.com/blog/five-ips-one-vm-a-lot-of-room-to-move
What you can do with additional IPs, full blog post:
https://www.doprax.com/blog/five-ips-one-vm-a-lot-of-room-to-move
When the network is unstable, your service or app will sometimes be offline or unavailable.
Five fixes to keep your app online, each with the exact command:
→ Cut external calls, self-host what you can
→ Cache the rest, serve the last good response when upstream dies
→ Short timeouts, not "wait forever"
→ Retry with backoff
→ TCP keepalives + auto-reconnect
~20 min, any Ubuntu VM.
Full tutorial: https://www.doprax.com/tutorial/keep-your-app-reachable-unstable-network
Five fixes to keep your app online, each with the exact command:
→ Cut external calls, self-host what you can
→ Cache the rest, serve the last good response when upstream dies
→ Short timeouts, not "wait forever"
→ Retry with backoff
→ TCP keepalives + auto-reconnect
~20 min, any Ubuntu VM.
Full tutorial: https://www.doprax.com/tutorial/keep-your-app-reachable-unstable-network
Not sure which port to run your service on?
Quick answer, with the reasons:
→ Use 443 (HTTPS). It works from almost every network.
→ Use TCP, not UDP. TCP resends lost data on a bad connection; UDP drops it.
→ Need UDP or an unusual port? Pick a region where all ports are open.
→ Test before you trust it: nc -zv YOUR_SERVER_IP 443
A running service on a blocked port looks exactly like a dead one. Here's how to tell them apart:
https://www.doprax.com/docs/which-ports-protocols-survive-bad-network
Quick answer, with the reasons:
→ Use 443 (HTTPS). It works from almost every network.
→ Use TCP, not UDP. TCP resends lost data on a bad connection; UDP drops it.
→ Need UDP or an unusual port? Pick a region where all ports are open.
→ Test before you trust it: nc -zv YOUR_SERVER_IP 443
A running service on a blocked port looks exactly like a dead one. Here's how to tell them apart:
https://www.doprax.com/docs/which-ports-protocols-survive-bad-network
IPv4 addresses are limited, so providers reuse them. If a past owner sent spam, attacked other servers, or ran an open proxy, the address was added to blocklists. When the IP moves to you, that record often moves with it. This is called a dirty IP.
A dirty IP can:
→ send your email to spam
→ get your API calls and webhooks blocked
→ stop visitors on some corporate networks from reaching your site
The good news: you can check an IP in two minutes, and you can fix most cases. The best time to check is right after you create a server, before you deploy anything.
In the full post: how IPs get dirty, how to check yours, and five steps to take if you have one.
Read it here: https://www.doprax.com/blog/what-is-a-dirty-ip
A dirty IP can:
→ send your email to spam
→ get your API calls and webhooks blocked
→ stop visitors on some corporate networks from reaching your site
The good news: you can check an IP in two minutes, and you can fix most cases. The best time to check is right after you create a server, before you deploy anything.
In the full post: how IPs get dirty, how to check yours, and five steps to take if you have one.
Read it here: https://www.doprax.com/blog/what-is-a-dirty-ip