DEV Community: EQVPS

Windows 10 or Windows Server on a VPS? Why every host sells Server, and what you lose

EQVPS — Sun, 01 Nov 2026 13:00:02 +0000

"Windows 10 VPS" is one of the most common searches for a Windows server, and almost every host answers it with Windows Server. That isn't a trick. There are licensing reasons, and for most programs the difference is smaller than it sounds. Here is what changes, what doesn't, and the numbers from our own Windows Server 2022 VPS.

Why hosts don't sell Windows 10

Licensing. A Windows 10 or 11 licence is written for a computer you own. Running desktop Windows on rented, shared hardware is allowed under Microsoft's terms only with specific enterprise subscriptions, and only through hosting partners Microsoft has authorised for exactly that. Windows Server is licensed for servers in data centres. That's why nearly every VPS host, including us, offers Server.

Support. Windows 10 reached end of support on October 14, 2025. Paid consumer security updates (ESU) for home PCs run until October 12, 2027, but that programme covers your own PC, not a rented server. Windows Server 2022 gets security updates until October 14, 2031.

So "a Windows 10 VPS" today would be an out-of-support system under a licence that doesn't cover the use. Server 2022 is the honest version of the same request.

What's the same

More than people expect. Windows Server 2022 (build 20348) is built on the same core as Windows 10 and 11:

Desktop software installs and runs: .NET apps, trading terminals, bots, browsers, office tools. Our image is the Desktop Experience edition, a full desktop over RDP, not the command-line-only Server Core.
Edge is preinstalled, so you can download what you need straight away.
PowerShell, Task Scheduler and the usual admin tools are all there.

If your program runs on Windows 10, test it on Server first. It almost certainly works.

What's different

	Windows 10 / 11 (desktop)	Windows Server 2022
Licence on a rented VPS	Only via special enterprise programmes	Standard: server licence (BYOL)
Security updates	Ended Oct 14, 2025 (Win 10)	Until Oct 14, 2031
Simultaneous RDP sessions	1	2 for administration, no extra licences
Microsoft Store	Yes	No
Server roles (IIS, DNS, Hyper-V…)	No	Yes
RAM at idle on our VPS	—	under 1.3 GB

The practical differences:

No Microsoft Store. On our server the Store package isn't present at all. Apps distributed only through the Store won't install; the same app's normal installer usually will.
A few programs refuse a server edition. Some consumer software and game anti-cheat systems check the edition and stop. This is rare for anything you'd run on a VPS, but check if your app is in that category.
Two RDP sessions instead of one. Two people (or you plus a script session) can be logged in at once. Each user gets one session by default, so reconnecting picks up where you left off. More than two concurrent users is a different product: the Remote Desktop Services role with paid client licences.

How heavy is it really

We measured on our Windows Server 2022 VPS with nobody logged in:

RAM: 965 MB to 1.3 GB in use;
Disk: about 14 GB of the 50 GB system disk;
Processes: 88.

That's why our smallest Windows plan, Windows-Small (4 vCPU, 4 GB RAM, 50 GB, $11/mo on NAT), has plenty of room for a bot, a terminal or a small .NET service. If you need your own public IPv4 for inbound connections, Windows Small-IP is $28/mo.

Licence: bring your own

The image is Windows Server 2022 Standard, starting as Evaluation, and you activate it with your own key. That keeps the plan price at the price of the machine. How activation and edition switching work is in BYOL Windows Server on a VPS.

First things to do on a new Windows VPS

Connect over RDP.
Secure RDP: NLA, lockout, an IP allowlist.
If your program must run around the clock, set it up in Task Scheduler so it survives reboots and crashes.
For scripting from Linux or CI, install OpenSSH.

All four Windows plans are on the Windows VPS page. Payment is in USDT, USDC or ETH on Base, Ethereum or Polygon, and no ID is needed.

FAQ

Can I get a Windows 10 or Windows 11 VPS?

Not from us, and not legitimately from most hosts. Microsoft's licence terms allow desktop Windows on rented, shared servers only under specific enterprise subscriptions, through hosting partners Microsoft has authorised for that. Hosts outside that programme offer Windows Server, which is licensed for servers.

Will my Windows 10 program run on Windows Server 2022?

Very likely. Server 2022 is built on the same core as Windows 10 and 11, so ordinary desktop software, .NET apps, trading terminals and bots install and run as usual. The exceptions are apps that ship only through the Microsoft Store and a few programs that refuse to install on a server edition.

How many people can use RDP at once?

Two at the same time, for administration, with no extra licences. Desktop Windows allows one. More than two simultaneous users needs the Remote Desktop Services role plus RDS client access licences, which is a separate purchase.

Is Windows Server 2022 still supported?

Yes. Mainstream support ended on October 13, 2026, which stops new features, but security updates continue until October 14, 2031. Windows 10 itself left support on October 14, 2025.

Is Windows Server heavier than Windows 10?

No. With nobody logged in our Windows Server 2022 VPS used under 1.3 GB of RAM and about 14 GB of disk. A 4 GB plan leaves plenty for your programs.

This article was created with the help of AI.

How much disk space does a VPS need? We measured what actually fills it

EQVPS — Sat, 31 Oct 2026 13:00:02 +0000

Plan pages list RAM first, but a full disk takes a server down just as surely. With "No space left on device", databases stop writing and sites stop answering, however much memory is free. Disk use isn't hard to predict once you know what grows. We booted fresh servers from our own images and measured each of the usual suspects.

What a fresh server uses

Measured right after the first boot:

System	Disk used
Alpine Linux 3.21	153 MB
Debian 12	1.2 GB
Ubuntu 24.04	2.7 GB
Windows Server 2022	14.0 GB

On Linux, almost all of a 15 GB Nano is yours from day one. Windows takes more than a quarter of its 50 GB plan before you install anything, and as you'll see below, updates take more.

Part of Ubuntu's 2.7 GB was easy to win back. 440 MB was the package cache from first-boot updates, and three kernels were installed where one is in use. Two commands brought it to 2.16 GB:

sudo apt clean
sudo apt autoremove --purge

Docker: images add up fast

Installing Docker itself added about 300 MB. The images are what count. We pulled eight common ones, one after another, and measured how much the disk grew each time:

Image	Disk added
`nginx:alpine`	91 MB
`nginx:latest`	232 MB
`postgres:16`	501 MB
`python:3.12-slim`	59 MB
`node:22`	1,564 MB
`mariadb:11`	437 MB
`wordpress:latest`	960 MB
`redis:7-alpine`	55 MB
Total	3.9 GB

Images that share a base reuse its layers, which is why python:3.12-slim added only 59 MB after nginx:latest and postgres:16 had already brought in the same Debian base. Alpine-based images are several times smaller than the full ones. node:22 alone is 1.5 GB, so build with node:22-slim or node:22-alpine when you can.

Images pile up when you update: each docker compose pull leaves the old version behind. On our test server one command cleared all of them:

docker system df
docker system prune -a

It reported 4.1 GB reclaimed. prune -a removes every image no container is using, so run it when your stack is up. Volumes are left alone unless you add --volumes.

Logs: the one that fills a disk overnight

Docker keeps everything a container prints, with no size limit by default. We started a container that printed one short line in a loop, the kind of output a health check or debug mode produces. After 30 seconds its log file was 6 MB. At that rate it would write about 17 GB a day, more than a whole Micro plan's disk.

Set a limit for all new containers in /etc/docker/daemon.json:

{
  "log-driver": "local",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Then sudo systemctl restart docker and recreate your containers (docker compose up -d --force-recreate). Existing containers keep the settings they were created with. With the limit, the same test container's log was 4 MB after 30 seconds and can never pass 30 MB.

The system journal is already capped: on our 25 GB Ubuntu server, journald limits itself to 2.3 GB, a tenth of the filesystem. It was using 15 MB.

Windows: updates need room

Our Windows Server 2022 image dated from 2022, so we brought it up to date. Used space went from 12.6 GB to 20.8 GB while the first cumulative update installed, and reached 24.5 GB after the second. Windows keeps the old version of every system file an update replaces. Cleaning those out brought it back to 14.6 GB, and a fresh server from the updated image now starts at 14 GB. Keep at least 10 GB free for the next update. The Windows update guide shows the cleanup commands.

What to choose

What you run	Disk that's comfortable	Plan
A bot, a VPN, a small static site	15 GB	Nano, $3/mo
A Docker stack with a few images	25 GB	Micro, $5/mo
WordPress with a database and uploads, several stacks	35 GB	Small, $8/mo
Bigger databases, many images, local backups	45 GB	Medium, $12/mo
Windows Server 2022	50–60 GB	Windows-Small, $11/mo

Two rules make any of these last longer: cap container logs before you deploy, and copy backups off the server instead of keeping them on its disk. If a server is already full, our guide to freeing up disk space works through it step by step. For the memory side of sizing, see how much RAM a VPS needs. All plans are on the VPS page, and payment is in USDT, USDC or ETH on Base, Ethereum or Polygon.

FAQ

Is 15 GB enough for a VPS?

For a bot, a VPN or a small site, yes. A fresh Ubuntu 24.04 server uses 2.7 GB of it and Alpine only 153 MB. It gets tight once you add Docker: eight common images took 3.9 GB on our test server. With Docker, start at 25 GB.

How much disk does Windows Server need?

A fresh server from our Windows Server 2022 image uses 14 GB. Updates need room on top of that: while our image caught up on four years of them it grew to 24.5 GB, and a cleanup brought it back to 14.6 GB. That's why our Windows plans start at 50 GB, which leaves about 35 GB for your programs and files.

What fills a VPS disk most often?

Container logs with no limit, unused Docker images, the package cache, old kernels, and backups that are kept on the same disk. The first is the fastest: one chatty test container wrote 6 MB of logs in 30 seconds.

Can I add more disk later?

Yes, by moving to a bigger plan. Each step up the Linux plans adds 10 GB of disk and more RAM. Before you upgrade, see whether a cleanup is enough: on our test server it freed 4.1 GB of Docker images in one command.

How do I see what is using my disk?

Run df -h / for the total and sudo du -xh --max-depth=1 / | sort -h for the biggest folders. If you use Docker, docker system df shows how much its images, containers and volumes take.

This article was created with the help of AI.

Linux or Windows VPS: which one do you actually need?

EQVPS — Fri, 30 Oct 2026 09:43:38 +0000

Picking an operating system feels like a detail you can sort out later. On a VPS it decides three things at once: what you pay, how much of the RAM is left for your own work, and how you look after the server every day. Here's the short version, then the numbers behind it. We measured them on fresh servers from our own images.

The short answer

Choose Windows when the job needs a program that only exists for Windows: a Windows-only trading terminal, a desktop app your business already runs, an old .NET Framework service, automation that clicks through Windows software. Windows also suits people who want to manage the server like a desktop PC and never open a terminal.

Choose Linux for almost everything else: websites, Docker, databases, VPNs, Telegram and Discord bots, trading bots written in Python, AI agents and game servers. Most of the software in those categories is written for Linux first.

If you aren't sure, it's probably Linux.

What each one uses before you start

We booted fresh servers from our images and measured them about a minute and a half after boot, with nobody logged in:

System	RAM used at idle	Disk used	Processes
Alpine Linux 3.21	55 MB	153 MB	about 70
Debian 12	213 MB	1.2 GB	81
Ubuntu 24.04	313 MB	2.7 GB	102
Windows Server 2022	965 MB to 1.3 GB	about 14 GB	88

Before your own software starts, Windows uses at least three times as much memory as Ubuntu and about twenty times as much as Alpine. That's why our smallest Windows plan has 4 GB of RAM, while the smallest Linux plan gets by on 1 GB. On disk, Windows takes about 14 of the 50 GB on its plan. Ubuntu takes under 3 GB.

What it costs

Prices for our plans, per month:

	Linux	Windows
Cheapest	Nano: 2 vCPU, 1 GB, 15 GB, $3	Windows-Small: 4 vCPU, 4 GB, 50 GB, $11
4 vCPU, 4 GB, NAT	Small: $8	Windows-Small: $11
4 vCPU, 4 GB, own IPv4	Small-IP: $16	Windows Small-IP: $28
6 vCPU, 6 GB, NAT	Medium: $12	Windows-Medium: $19

At the same size, Windows costs $3 to $7 more on NAT and $12 more with its own IPv4. The bigger gap is at the bottom of the range. A small bot or website that runs happily on a $3 Linux server needs at least the $11 Windows plan, because Windows alone uses about 1 GB.

There's also the licence. Our Windows image is Windows Server 2022 that you activate with your own key (how BYOL works). Linux has no licence to buy.

How you look after it

Linux is managed over SSH, in text. Configuration lives in files, software comes from a package manager, and every step can go in a script. That's also why automation tools and AI agents find Linux servers easier to drive. Our setup guides for Ubuntu, Debian, Rocky Linux and Alpine take about ten minutes.

Windows is managed over Remote Desktop: a full desktop, the usual GUI tools, and PowerShell when you want to script. Two people can be connected at the same time without extra licences (how to add a second user). For scripting from another machine, OpenSSH is built in too. The first thing to do on any Windows server is lock down RDP.

Three common mix-ups

"I need Windows to use Remote Desktop." You don't. A Linux server can run a desktop that you open with the same Remote Desktop app. With XFCE and xrdp, one session added about 360 MB of RAM on our Ubuntu test server.

"Trading bots need Windows." Most don't. Freqtrade, Hummingbot and nearly every bot written in Python or Node.js run natively on Linux. Windows is only needed when the terminal itself is a Windows program.

"I want Windows 10, not Server." Desktop Windows on rented servers is a licensing problem, and Windows 10 is out of support. Server 2022 runs the same programs. The details are in Windows 10 vs Windows Server on a VPS.

Our pick

A website, Docker stack, database or bot: Linux. Pick Ubuntu 24.04 if you follow tutorials, Debian 12 for less overhead, and Alpine for the leanest Docker host.
Software that exists only for Windows: Windows Server 2022, starting with Windows-Small.
Not sure: start on Linux. Nano costs $3 a month, so finding out is cheap.

Choose at the start, though. The Windows image runs only on the Windows plans, so going from Linux to Windows later means a new plan and moving your data. All Linux plans are in VPS plans and all four Windows plans are on the Windows VPS page. Payment is in USDT, USDC or ETH on Base, Ethereum or Polygon, and no ID is needed.

FAQ

Is a Windows VPS more expensive than Linux?

Yes, because Windows needs more of the machine. Our cheapest Linux plan is Nano at $3 a month with 1 GB of RAM; the cheapest Windows plan is Windows-Small at $11 a month with 4 GB. With the same 4 GB and 4 vCPU, Linux Small costs $8. On top of that, Windows needs a licence: you activate our image with your own key.

Can I get a graphical desktop on a Linux VPS?

Yes. XFCE with xrdp gives you a desktop you open with the normal Remote Desktop app. On our test server one session added about 360 MB of RAM, so a 2 GB plan handles it. You only need Windows if the software inside the desktop is Windows software.

Can I switch from Linux to Windows later?

Not by reinstalling the same plan. The Windows image runs only on the Windows plans, and the Linux plans don't include it. Moving means ordering a Windows plan and copying your data across. Choosing the right one at the start saves you that move.

Do trading bots need Windows?

Most don't. Freqtrade, Hummingbot and nearly every bot written in Python or Node.js run natively on Linux. Windows is for terminals and tools that only exist as Windows programs.

Which Linux distribution should I pick?

Ubuntu 24.04 if you follow online tutorials, because most are written for it. Debian 12 if you want the same tools with less overhead. Alpine if you want the smallest possible system, for example as a Docker host. Rocky Linux or AlmaLinux if you work with Red Hat-style systems.

This article was created with the help of AI.

You can now pay for a VPS with Solana

EQVPS — Fri, 28 Aug 2026 22:50:23 +0000

We added Solana to checkout this week. If you hold USDC, USDT or PYUSD on Solana — or you're sitting on some SOL — you can now pay for a server straight from there, no detour through another chain.

It's a small change on the surface and a genuinely useful one in practice, so here's the why.

The reason is boring, which is the point

A lot of people already keep their stablecoins on Solana. Until now, paying us meant moving those funds to Base, Ethereum or Polygon first — an extra hop, an extra fee, an extra chance to fat-finger a network. That friction lands right at the payment step, which is exactly where you don't want it. Now the answer is just "pay from where your money is."

That's the whole pitch. No new economics, no tokenomics, no reason to overthink it. One more rail so fewer people have to move funds across chains before they can buy a $5 box.

What Solana is good at here

For a small payment the fee is the entire story, and Solana is hard to beat on it:

Fees are fractions of a cent — well under a penny per transfer. On a $3–5 order that's a rounding error instead of a tax.
Confirmation in seconds. Solana produces a block roughly every 400 ms; you send, and it's usually settled before you've switched tabs.
USDC, USDT, PYUSD or SOL — stablecoins if you want a fixed amount, SOL if that's what you're holding.

One honest wrinkle worth knowing up front: Solana charges its network fee in SOL, even when you're sending USDC. It's a fraction of a cent, but a wallet with only USDC can't move it — keep about ten cents of SOL around and you'll never think about it again. We wrote up the full payment steps if you want the click-by-click version.

Who this is actually for

If your crypto lives on Ethereum, keep paying on Base — nothing here changes for you. This is for the people whose default chain is Solana: traders and bot runners who settle there, folks who bought SOL and never moved it, anyone in the Solana ecosystem who'd rather not shuffle funds across chains to pay a hosting bill. For them the checkout just got one step shorter.

And to be clear — Solana being fast and cheap doesn't make us a different host. Same servers in Germany and Finland, same email-only signup, same root in about a minute. We just stopped making Solana users take the long way to the payment page.

Want to try it? Pick a plan and choose Solana at checkout — USDC, USDT, PYUSD or SOL, no KYC either way. If you're running actual Solana workloads on the box, not just paying from it, we went deeper on that in VPS for Solana developers.

Running Hummingbot on a VPS: 24/7 market-making without KYC

EQVPS — Tue, 25 Aug 2026 14:14:46 +0000

A market-making bot is not a "set it and forget it" script. Hummingbot sits on live WebSocket connections to the exchange, watches the order book tick by tick, and places and cancels orders every few seconds to keep a spread around the mid price. Close the laptop, drop the Wi-Fi, let the machine sleep for an OS update — and you've either got stale orders resting on the book at prices the market has already left, or a bot that quietly stopped quoting. Neither is where you want to be with money on an exchange.

So Hummingbot belongs on a server. That part isn't controversial. The useful question is what kind of server, and how not to overpay for it.

What Hummingbot actually does to a machine

It's lighter than people expect, and heavier in one specific place.

The core loop — hold connections, read the book, quote a spread — barely touches the CPU. A single pure-market-making strategy on one exchange is happy in 1–2 GB of RAM and idles most of a core. If that's all you're doing, our Micro plan ($5/mo) is genuinely enough, and I'd rather tell you that than sell you something bigger.

Memory is where it grows, and it grows for concrete reasons:

More markets. Each strategy instance and each connector holds its own state. Run three or four bots across two exchanges and you're comfortably into 3–4 GB.
The dashboard. Hummingbot's newer setup runs the bot, a dashboard, and a database as separate containers. That stack wants more headroom than the bare CLI bot.
Gateway for DEX trading. If you're arbitraging or making markets on on-chain DEXes, the Gateway container is a second Node service sitting next to the main one. Not huge, but not free.

That's why the honest recommendation is: start on Micro if you're running one strategy, and move to Small ($8/mo, 4 vCPU, 4 GB) the moment you add a second bot, the dashboard, or Gateway. Small is the plan most people who run Hummingbot seriously settle on.

Disk matters less than for a backtesting-heavy Freqtrade setup, but it still writes trade history and logs constantly. NVMe (ours is RAID1, ~800 MB/s reads) keeps that off the critical path. If you're coming from Freqtrade, our Freqtrade on a VPS write-up covers the backtesting-memory side in more detail — Hummingbot leans the other way, toward live connections rather than heavy backtests.

Latency: useful honesty

You'll see "low latency" on every trading-VPS page, including ours, so here's the real version. A server physically close to the exchange's matching engine reaches it faster than a home connection routed halfway across a continent — that's real and it matters for quoting tight spreads and for cross-exchange arbitrage where you're racing a price gap. Our servers are in Europe (Germany and Finland), which is close to where a lot of the big matching engines actually live.

What it is not is co-located high-frequency trading. If your strategy only works when you're inside the same datacenter as the exchange, shaving microseconds, a shared $8 VPS won't get you there and no honest host would claim otherwise. For everything short of that — normal market-making, spread capture, cross-exchange arb on a human-plus-seconds timescale — a nearby VPS is exactly the right amount of infrastructure.

The part that's actually our angle

Your exchange already knows who you are; it did its KYC when you opened the account. The machine that holds your API keys and runs your strategy is a different question. There's no reason the infrastructure under a trading operation has to be tied to your identity too, and plenty of people running bots would rather it wasn't — a server rented with an email and paid in stablecoin is one less place your name is written down.

That's what we do. Sign up with an email, pay in USDC or USDT (Base, Ethereum or Polygon), get root in about a minute. No card, no documents. One caveat worth stating plainly: if you're on the cheapest plans, pay in a stablecoin, not BTC — Bitcoin network fees can eat an ugly chunk of a small order, so it's the wrong rail for a $5 box.

On the keys themselves: make them trade-only, withdrawals off, and if your exchange lets you whitelist an IP, put a dedicated IP on the plan so your API keys are bound to one fixed address. The bot is only as exposed as the server it runs on, so lock the server down like it's holding money — because effectively it is.

Bottom line

Hummingbot needs a machine that never sleeps and never drops its connection to the exchange — that's the whole reason a VPS exists for this. Size it to what you're actually running: Micro for one strategy, Small once the dashboard, Gateway, or a second bot show up. Pay in crypto if you'd rather not attach your name to the infrastructure. And don't buy latency you can't use — a nearby European server is the right call; a co-lo fantasy on a $8 plan isn't.

If you want the broader picture on running any trading bot with us, the VPS for crypto trading bots page covers plan sizing and the no-KYC setup across bots, not just Hummingbot.

Locked out of your VPS by ufw? Get back in without a reinstall

EQVPS — Sat, 22 Aug 2026 13:33:05 +0000

There's a rite of passage for anyone new to running their own server: you decide to set up a firewall, you type a few ufw commands, you hit enable — and your terminal goes silent. SSH is gone. You didn't crash anything, you didn't get hacked. You just locked the door with yourself outside.

It happens to good sysadmins too. It happened to one of our customers last week, which is why I'm writing this down. The good news: it's completely recoverable in under a minute, and you do not need to reinstall or lose a single file. Here's how.

A VPS sealed behind a firewall wall, with a glowing console window as the way back in

What actually went wrong

ufw (Uncomplicated Firewall) defaults to deny all incoming. The moment you run ufw enable, anything you didn't explicitly allow is dropped — including the SSH session you're sitting in. If you forgot to ufw allow your SSH port first, you've cut your own connection the instant the rule takes effect.

That's the classic version. There are two other flavours that catch people:

You allowed the wrong port. Typo, or you allowed the service port (say 8080) and forgot 22.
You allowed 22 but then set a deny rule higher in the list that shadows it. ufw is order-sensitive.

Either way the server itself is fine — running, disk intact, your app still humming behind the wall. It's purely a network-access problem. Which is exactly why the fix is easy.

The wrong move: reinstalling

The first instinct is often "just reset the server and start over." Don't — not for this. A reinstall wipes everything to get back a working SSH, when the thing blocking SSH is one firewall command you can undo in ten seconds. You'd be burning down the house because you locked the front door.

Reinstall is the right call when you want a clean slate. For a ufw lockout, it's overkill.

The right move: the web console

Every VPS worth its salt gives you an out-of-band console — a way into the machine that doesn't ride over SSH or even the network stack. On EQVPS it's the Console button on your server's page. It's a serial console: text-only, connected straight to the VM the way a monitor and keyboard would be. A firewall rule has no power over it, because it isn't network traffic.

The Console button on the EQVPS server management page

Click it, log in with your root credentials (or reveal the password in the panel if you don't have it handy), and you're on the box — firewall or no firewall.

Now undo the damage. Fastest path:

sudo ufw disable

That turns the firewall off and keeps your rules, so you can re-enable it later once you've fixed the mistake. SSH comes straight back.

If you'd rather not drop the firewall entirely, just open the port you missed:

sudo ufw allow 22
sudo ufw status numbered

The status numbered view is worth a look — it shows the rule order, which is where the "I allowed 22 but it still blocks" cases hide. If a deny sits above your allow, delete it with sudo ufw delete <number>.

The NAT gotcha most guides miss

If you're on a NAT plan, there's a trap here. You SSH in on a high port — something like 20266 — so the natural instinct is ufw allow 20266. That does nothing.

On NAT, that external port is forwarded to port 22 inside the VM. ufw runs inside the VM and only ever sees 22. So the rule you actually need is:

sudo ufw allow 22

Allow 20266 and you'll stare at a still-broken connection wondering why. Allow 22 and you're in. Same idea for any service: allow the port the process listens on inside the box, not the forwarded one you connect to from outside.

How to never do this again

The fix takes a minute, but not needing it is nicer. Two habits:

Allow your SSH port before you enable. In this order, always:

sudo ufw allow 22
sudo ufw enable

Do it backwards and you're back in the console.

Keep a second session open while you change firewall rules. Log in twice. Make your changes in one window; if SSH dies, the other window is still alive to fix it. Old trick, saves you every time.

And if you're setting up a fresh box, our new-VPS security checklist covers ufw the right way round, alongside SSH keys and the handful of other things that actually matter in the first ten minutes.

The takeaway

A ufw lockout looks scary and is almost nothing. The server never left; you just need a door that a firewall can't slam — the web console — and one command. Keep ufw disable and the console in your back pocket, allow your port before you enable next time, and you'll never sweat this one again.

Dedicated IP or NAT VPS: which one your project actually needs

EQVPS — Tue, 11 Aug 2026 16:21:26 +0000

You rent a VPS, install Nginx, open your browser to the server's address — and nothing loads. Or you set up a mail server and every message bounces. Nine times out of ten the box is fine; the problem is that you're on a NAT plan and the thing you're running needs to be reached from the outside.

This is the one networking choice that trips people up when they buy a server, so let's make it simple. There's exactly one question that decides it, and then a lot of examples so you can place your own project.

The one question

Does anything on the internet need to start a connection to your server?

No → a NAT VPS is enough. Cheaper, same CPU, same disk, same speed.
Yes → you need a dedicated IP.

That's the whole decision. Everything below is just applying it.

What "NAT" actually means here

On a NAT plan your server shares one public IPv4 with other servers and sits behind network address translation. In plain terms:

Outbound is unrestricted. Your server can reach anything — pull from GitHub, call the OpenAI or Anthropic API, connect to Telegram, scrape a site, hit a database elsewhere. All of that starts from your box, so NAT never gets in the way.
Inbound is not yours. You don't own a port on the public address, so you can't just open 443 to the world and expect traffic. SSH is forwarded to you on a specific high port (we show you the exact host:port), and that's the inbound you get.

For a huge share of what people actually run on a small server, that's completely fine. A bot that talks to Telegram, an AI agent making API calls, a scraper, a cron job that pushes data somewhere, a CI runner that pulls jobs — none of these need the world to connect in. They reach out. NAT is built for exactly that, and it's why the NAT line starts at $3/mo instead of $8.

What a dedicated IP gives you

A dedicated-IP plan hands you your own public IPv4, with every port open. Now the outside world can start a connection to you, which is the whole point for a certain class of software:

Websites. A browser has to connect in on 80/443. No public IP, no site.
Mail servers. Inbound 25 to receive, plus you need control of reverse DNS (PTR) so other servers trust you. That requires an IP that's yours — here's how to set the PTR.
A personal VPN. WireGuard listens on a UDP port your client connects to — see VPS for a personal VPN.
A proxy server. Same idea: your client connects in to the proxy port. VPS for a proxy server.
Game servers, reverse proxies, webhooks, self-hosted apps you open to the internet — anything where "someone connects to my server" is the feature.

You also get reputation you control: the IP is used by you alone, so you're never sharing a blocklist entry with a stranger who spammed from the same address yesterday.

Where people get it wrong

A few honest corrections, because these come up constantly:

"I need a public IP for my Telegram bot." Usually no. In the default long-polling mode the bot dials out to Telegram and gets updates back over that connection. NAT is fine. You only need an inbound port if you deliberately switch to webhook mode — and for most bots, long-polling is simpler anyway.

"A dedicated IP is more private." Careful — it's the reverse. A shared NAT address hides you in a crowd; a dedicated IP is yours alone. Dedicated is better for reliability and for anything that must be reachable, worse for blending in. Pick by function.

"I'll get the IP just in case." Don't. Start on NAT, and if a project genuinely needs inbound later, order a dedicated-IP plan for it then. Paying $8–20 for an IP you never accept a connection on is money lit on fire.

Quick placement table

If you're still unsure, find your thing here:

NAT ($3–12/mo): Telegram/Discord bots, AI agents, trading bots, web scrapers, CI runners, cron jobs, anything that only calls out. See AI-agent use cases.
Dedicated IP ($8–20/mo): websites, mail, VPN, proxies, game servers, reverse proxies, public APIs, webhooks, anything the internet connects to. Start with Nano-IP ($8) for light single-service boxes, or Small-IP ($16) when you want room for a couple of services at once.

The honest bottom line

Ask the one question — does anything need to connect in? — and the answer picks the plan. If you're building agents and bots that reach out to APIs, stay on NAT and keep the $5 a month. If you're putting something on the internet for other people or machines to reach, get the dedicated IP; nothing else will work. Buying the wrong one isn't the end of the world (you can always spin up the right plan), but getting it right the first time saves you an afternoon of wondering why your site won't load.

Pay in USDC or USDT, email to sign up, no card and no ID either way. See the plans.

FAQ

What's the difference between a NAT VPS and a dedicated IP VPS?

A dedicated IP VPS gives you your own public IPv4 address with every port open — anything on the internet can reach it. A NAT VPS shares an outbound IP and forwards only SSH; it can reach out to the internet freely, but nothing can connect in on an arbitrary port. Outbound work is identical; the difference is whether the outside world can start a connection to you.

Do I need a dedicated IP for a Telegram or Discord bot?

No. Those bots hold an outbound connection to Telegram/Discord and receive updates over it — nothing connects in to the bot. A NAT plan is enough and cheaper. You only need a dedicated IP if you switch a Telegram bot to webhook mode, which requires an inbound HTTPS port.

Can I start on NAT and move to a dedicated IP later?

Yes — pick NAT if you're unsure. Most people who think they need a public IP don't, and the cheaper plan does the job. If a project later needs to accept inbound connections, you order a dedicated-IP plan for it then. Don't pay for an IP 'just in case'.

Why is SSH on a weird port on the NAT plans?

On NAT there's no public IP to own port 22, so your SSH is forwarded from a high port on the shared address (the panel shows the exact host:port). It's normal and it works fine — just point your SSH client at the port we give you instead of 22.

Is a dedicated IP more private?

It's the opposite trade-off. A dedicated IP is yours alone — great for reputation and reliability, but your traffic doesn't blend into a crowd. NAT shares an outbound address with other servers, which hides you more but is useless for anything that must be reached from outside. Choose by what the server does, not by a vague sense of privacy.

VPS for a Proxy Server (SOCKS5 / HTTP, your own IP)

EQVPS — Tue, 11 Aug 2026 16:20:05 +0000

A proxy is just a machine that makes requests on your behalf, so the other side sees the proxy's IP instead of yours. Rent a VPS with a dedicated IP, run a proxy daemon on it, and you have a fixed exit address that's yours alone — no monthly per-GB metering, no shared pool, no one else's abuse landing on your IP.

The catch is that a proxy only works if clients can connect to it. That's inbound traffic on a port, which is exactly what a NAT plan won't give you. So this is a dedicated-IP job from the start.

First, is this the proxy you actually want?

Be honest with yourself about the use case, because "proxy" covers two very different needs:

A fixed exit IP you control — this is what a self-hosted proxy is great at. You want a stable outbound address to put on an API allowlist, a private route for your own traffic, a way to test how your app looks from a German IP, or a clean IP you're not sharing with strangers. One static datacenter IP is a feature here, not a limit.

A rotating residential pool for scraping thousands of pages without getting blocked — this is not it. You get one datacenter IP. Some targets block datacenter ranges outright, and there's no rotation. If your job is high-volume scraping behind rotation, a single VPS proxy will get rate-limited fast, and we'd rather tell you now than take $16 for the wrong thing.

If the first one is you, read on.

What you need

A dedicated-IP plan. The proxy listens on a port your clients dial in to; NAT plans don't forward arbitrary ports. Small-IP ($16/mo — 4 vCPU, 4 GB RAM, your own public IPv4) handles real traffic and several clients comfortably. A single personal proxy is fine on Nano-IP ($8/mo).
Unmetered traffic, which every plan here has — a proxy that bills you per GB is a proxy you stop using.
Ubuntu 24.04 and five minutes.

The setup: 3proxy (SOCKS5 + HTTP, one daemon)

3proxy is tiny, does both SOCKS5 and HTTP, and has clean auth. Install it, then write a minimal config:

apt update && apt install -y 3proxy

Create /etc/3proxy/3proxy.cfg:

# resolve names, keep a small log
nserver 1.1.1.1
nscache 65536
log /var/log/3proxy/3proxy.log D
rotate 7

# ONE user — change these
users proxyuser:CL:a-long-random-password

# require that login for every connection
auth strong

# SOCKS5 on 1080, HTTP on 3128
socks -p1080
proxy -p3128

Start it:

mkdir -p /var/log/3proxy
systemctl enable --now 3proxy

Now point your client at your.server.ip:1080 (SOCKS5) or :3128 (HTTP) with that username and password. curl is the quickest test:

curl -x socks5://proxyuser:PASSWORD@YOUR.SERVER.IP:1080 https://ifconfig.me

If it prints your server's IP, you're routing through your own proxy.

Lock it down — this part is not optional

An open proxy on a public IP is found by scanners within hours and turned into someone else's spam relay. Two rules:

Auth on, always. The auth strong line above means no login, no connection. Keep it.
Firewall the ports to the IPs that actually use them. If it's just you:

ufw allow 22/tcp
ufw allow from YOUR.HOME.IP to any port 1080 proto tcp
ufw allow from YOUR.HOME.IP to any port 3128 proto tcp
ufw --force enable

If your clients roam and you can't pin an IP, at least keep auth strong and a long password, and watch the log. Abuse coming out of your server is on you — no-KYC means we don't ask who you are, not that anything goes.

Where this beats a commercial proxy

You control the box, so there's no third party logging which sites you route through it. The IP is static and yours, which is the whole point for an allowlist or a stable outbound route. And you pay for it in crypto with an email address — a proxy tied to your real name and card isn't much of a private route.

The trade-off, again, honestly: it's one IP, and it's a datacenter IP. Perfect as a fixed exit you own; wrong as a rotating scraping pool. If that's the exit you want, Small-IP at $16/mo is the sweet spot — or Nano-IP at $8 for a single light personal proxy.

Related: a personal VPN if you want to tunnel all your traffic instead of per-app, and bypassing censorship if a plain proxy gets fingerprinted where you are.

FAQ

Which plan do I need for a proxy?

A dedicated-IP plan, because a proxy has to accept inbound connections on its port — NAT plans don't forward arbitrary ports. Small-IP ($16/mo — 4 vCPU, 4 GB RAM, your own public IPv4) is the comfortable pick when you'll push real traffic or a few users. A single light personal proxy runs fine on Nano-IP ($8/mo).

Is a self-hosted proxy the same as buying residential proxies?

No, and it's important. Your server's IP is a datacenter address, static and yours alone. That's perfect for a fixed exit you control — API allowlists, a stable outbound IP, a private route. It is not a rotating residential pool: some sites block datacenter ranges, and you get one IP, not thousands. For large-scale scraping behind rotation, this isn't the tool.

SOCKS5 or HTTP — which should I run?

SOCKS5 is more general: it forwards any TCP (and UDP) traffic, so it works for more than browsers. HTTP proxies are simpler and fine if you only need web traffic. 3proxy, which we use below, does both from one config, so you don't really have to choose.

Will people be able to abuse my open proxy?

Only if you leave it open. Always require a username and password, and firewall the port. An unauthenticated proxy on a public IP gets found and abused within hours — and abuse from your server is your responsibility. The setup below turns auth on from the start.

Do you ask for ID?

No. Email to register, USDC or USDT to pay. A proxy you rent with your real name and card isn't really a private route — so we don't ask for either.

Run all your self-hosted services behind one IP with a reverse proxy

EQVPS — Mon, 10 Aug 2026 11:26:22 +0000

There's a point in every self-hosting habit where you stop wanting a server per thing. You've got an app, its database, maybe n8n for automations, a status dashboard, a small API — and running each on its own tiny VPS means five IPs, five bills, five machines to patch. It's tidier, and cheaper, to put them on one box behind one IP.
The trick that makes this work is a reverse proxy. Caddy, nginx or Traefik sits on the public ports 80/443 and routes by hostname: app.you.com goes to your app, n8n.you.com goes to n8n, db-admin.you.com to your admin panel. Every service listens only on localhost; the proxy is the single public door, and it hands each subdomain its own HTTPS certificate automatically.

The plan for this

Medium-IP ($20/mo) is the natural fit: 6 vCPU, 6 GB RAM, 45 GB NVMe, a dedicated IPv4 with every port open. That's room for a handful of small services plus their databases without them fighting for resources.
Two honest boundaries:

If you're really running just one app plus a database, you don't need Medium — Small-IP ($16) does it.
If the services are memory-hungry — a big database, a large vector store, in-memory processing — you'll hit the RAM ceiling fast, and that's where a high-memory Pro plan makes more sense than stacking on a 6 GB box. ## Setup shape bash # Ubuntu 24.04, Medium-IP — Docker + Compose, Caddy as the front door curl -fsSL https://get.docker.com | sh # docker-compose.yml: your services on localhost, Caddy routing by subdomain # Caddy auto-issues HTTPS for each hostname you point at the IP docker compose up -d

Point your subdomains' A records at the one IP, list them in the Caddyfile, and each service comes up on its own clean HTTPS URL. Add reverse DNS from the dashboard if any of them send mail.

Why here

One dedicated IP you fully control, everything behind it, paid as a single flat crypto bill with no KYC. It's the homelab-on-a-VPS pattern: your stack, your machine, one predictable monthly number. When one box stops being enough, you split the heaviest service onto its own — but most people run comfortably on one for a long time. Medium-IP is where that starts.

Self-hosting email: the two things that actually decide deliverability

EQVPS — Mon, 10 Aug 2026 11:23:53 +0000

Most guides about self-hosting email skip the part that actually decides whether it works, and it isn't the software. You can set up Postfix in an afternoon. Whether your mail lands in inboxes or vanishes into spam folders comes down to two things: a dedicated IP and correct reverse DNS. Everything else is detail.
That's why email is the one workload where a NAT plan is a non-starter. Receiving mail means a server the world can reach on port 25 — you need a public IP of your own. And you need that IP's reputation to be yours, not shared with whatever a hundred other users are doing. A dedicated IP gives you both.

What matters, in order

A dedicated IPv4 — so you can listen on port 25 and own the IP's reputation.
Reverse DNS (PTR) that matches your hostname — receiving servers reject mail without it. On our dedicated-IP plans you set this yourself in the dashboard.
SPF, DKIM, DMARC records — the DNS trio that proves your mail is really from you. Get these right and you're in inboxes; skip them and you're in spam.
A warm IP — send gently at first. A brand-new IP blasting volume looks like a spammer. We wrote the full walkthrough in the blog — this page is the short version of why the plan matters. ## The plan Small-IP ($16/mo) — 4 vCPU, 4 GB RAM, 35 GB NVMe, a dedicated IPv4, port 25 open, and reverse DNS you control. That's enough for a personal or small-team server: Mailcow or Mailu if you want a full stack with a web UI, or a lean Postfix + Dovecot if you like it minimal. Several domains and heavier volume? Medium-IP ($20/mo). ## Who this is honestly for Self-hosted mail is more work than a hosted inbox, and it rewards patience with DNS and IP warm-up. What you get in return: your mail data on a server you control, a flat price paid in crypto with no KYC, and nobody scanning your messages. If you're running email for privacy or independence, that trade is the whole point. If you just want a mailbox that works out of the box, a hosted provider is the easier road — and that's a fair choice too. Ready to run your own? Small-IP is where to start, then follow the setup guide.

Why your website won't load on a cheap VPS (and the fix)

EQVPS — Mon, 10 Aug 2026 11:17:18 +0000

The thing that trips people up hosting a website on a cheap VPS is the network setup. They grab the cheapest plan, deploy nginx, point a domain at it — and nothing loads. Because the cheapest plan is behind NAT, and a site behind NAT can't be reached from the outside on port 443.

A website is the opposite of a bot. A bot makes outbound calls and never needs an inbound port. A website lives on inbound ports 80 and 443 — the whole point is that strangers connect to it. That requires a public IP of your own, which is exactly what a dedicated-IP plan gives you and a NAT plan doesn't.

What you actually need

For a normal site — a CMS, a landing page with a build step, a small app plus a database — Small-IP ($16/mo) is the comfortable fit: 4 vCPU, 4 GB RAM, 35 GB NVMe, and a dedicated IPv4 with every port open. Point your domain's A record at the IP, run nginx or Caddy, and Let's Encrypt handles HTTPS on its own.

Running several sites, or expecting real traffic? Medium-IP ($20/mo) gives you 6 vCPU / 6 GB and more disk — enough to co-locate a few services behind the one IP.

If your "site" is really just an outbound worker with no public front — a scraper, a bot, an API client — then you don't need any of this; a NAT plan from $3 is the honest answer. Dedicated IP is for things the world connects to.

Setup, briefly

On Ubuntu 24.04 (Small-IP), point yourdomain.com A record to your IP first, then:
apt update && apt install -y nginx certbot python3-certbot-nginx
certbot --nginx -d yourdomain.com

Full root, so WordPress, a Node/Next app, a Go binary, a static bundle — whatever your stack is, it runs. Reverse DNS you can set yourself from the dashboard, which matters if you'll also send email from the box.

Why here specifically

Two reasons people pick a no-KYC crypto host for a site instead of a mainstream one: they'd rather not tie the server to a card and an identity, and they want a flat monthly price paid in crypto with no surprises. It's not the cheapest per-gigabyte hosting on earth — it's a real public server you fully control, rented privately. If that's what you're after, Small-IP is where most sites start: https://eqvps.com/en/products/small-ip

Self-hosted RAG at scale: how much RAM a vector index really eats

EQVPS — Sun, 09 Aug 2026 11:45:51 +0000

Every RAG tutorial runs on a laptop with a few hundred documents, and it feels effortless. Then you point it at a real corpus — a company's docs, years of tickets, a knowledge base — and suddenly memory is the whole conversation.

RAG doesn't scale by CPU. It scales by RAM.

Why the index wants memory

Retrieval works by turning every chunk of text into an embedding — a vector, a few hundred to a couple thousand numbers long. Search means comparing your query vector against all of them, fast. "Fast" is the operative word: for low latency the index needs to live in RAM. On disk it works, but every query pays a penalty, and low-latency retrieval was the point of self-hosting in the first place.

So the memory bill scales with two things: how many chunks you have, and how wide each vector is.

Real numbers, roughly

Measure your own — dimension and index type move this a lot — but as a starting feel:

A few hundred thousand embeddings — comfortable in 2–4 GB. A personal knowledge base, a single product's docs.
Low millions — with the app, the model client, and the OS around it, plan for 16–32 GB. This is a serious company knowledge base or a multi-source RAG.
Tens of millions, or high-dimension vectors — now you're at 48–80 GB, and past that across several boxes. Large document estates, multi-tenant retrieval, or you're keeping several indexes hot at once.

A multi-agent system that also holds a big index stacks both costs on the same box — that's how a 32 GB plan turns into a 64 GB one quietly.

The engine choice, briefly

If you already run Postgres, pgvector is the least-effort option — it's an extension, not a new service to babysit. When you have millions of vectors and want fast filtered search, a dedicated engine like Qdrant or Weaviate earns the separate process. Don't over-engineer it on day one; run what you already operate and split it out when search actually slows.

Why bother self-hosting

Two reasons people actually do this, and neither is "to save a few dollars":

Privacy. Embeddings aren't abstract — they encode the text they came from. Your docs, your customers' content, your internal notes, turned into vectors and shipped to a third party's servers. Self-hosting keeps that on a machine you control. If the data is sensitive enough that you're also paying in crypto with no KYC, a managed vector cloud undoes the whole point.

Flat cost. Managed vector services bill by vectors stored and queries run. A VPS is one monthly number and you can hammer it as hard as you like. At scale, predictable beats metered.

What this means for sizing

Start by measuring your corpus, not by guessing. Get your embedding count and dimension, load a sample, watch the resident memory, extrapolate. Then pick a plan with headroom for the index plus everything around it — the app, the model client, room to grow.

For anything past a couple million vectors held privately, the Pro line runs 32 to 80 GB with a dedicated IP and nightly backups, which matters when the index is the product and losing it hurts.