DEV Community: EQVPS

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 nodes 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 .

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.

Hosting local LLM inference privately: what a CPU VPS can and can't do

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

Let's be honest up front: if you want fast, cheap, high-quality generation, call an API. A CPU VPS will not beat a datacenter full of GPUs, and anyone telling you otherwise is selling something.

So why self-host inference at all? One reason, and it's a good one: the model on your server never sends your prompts anywhere.

What CPU inference actually looks like
You can run real models on CPU with enough RAM. A 7–8B model quantized to 4-bit works. A 13B works. You can even push a 30B-class model if you've got the memory. What you can't do is make it fast — output comes at a few tokens per second, not the instant stream an API gives you.

That's the honest trade. For interactive chat it's frustrating. For background work — summarizing documents overnight, classifying a queue, enriching data on a schedule — a few tokens per second is completely fine, and nobody's watching the clock.

The RAM math
The model has to sit in memory, quantized or not, plus overhead for context and the runtime:

7–8B, 4-bit — around 6–8 GB. Runs on a mid plan.
13B, 4-bit — roughly 10–16 GB.
30B-class, quantized — 24–48 GB, depending on quantization.
Bigger, or higher precision — you're into 64–80 GB fast — and past 80 GB no single Pro box fits, still CPU-slow.
This is why "run a local model" quietly becomes a high-memory question. The model is the memory footprint. Add a RAG index or agents on the same box and the numbers stack.

Ollama vs vLLM, briefly
Ollama is the easy door in — install, ollama run, done. It's the right tool for a private single-user setup where you just want the model available. vLLM is built for serving throughput: more setup, better under concurrent load, worth it when you're actually handling volume. Start with Ollama; reach for vLLM when you're serving real traffic.

Where private-first genuinely wins
The case for self-hosted inference isn't speed or cost — it's that some data can't leave. Legal documents. Medical records. Proprietary code. Anything where sending the prompt to a third-party API is off the table for policy or trust reasons. A slower model that runs entirely on your machine beats a fast one that logs everything you send it.

And if the data is that sensitive, the payment probably should be private too. Renting the box with crypto and no KYC keeps the whole chain — server, model, prompts, billing — off anyone's identity records. That's the actual pitch: not "cheaper inference," but "inference nobody else can see."

Bottom line
For speed and quality, use an API — no shame in it. Self-host when privacy is the requirement and slower is acceptable. Size for the model plus its context plus anything else sharing the box, and don't expect GPU speed from CPU.

When the model needs real memory, the Pro line runs 32 to 80 GB with a dedicated IP and nightly backups — enough to hold a serious quantized model with room for context around it.

Why a no-KYC high-memory VPS costs more than the $/GB math suggests

EQVPS — Sun, 09 Aug 2026 11:43:52 +0000

If you go looking for a 64 or 80 GB VPS and you land on our Pro line, the first thing you'll probably do is divide the price by the RAM. Then you'll open a mainstream host in another tab, do the same math, and think: these guys are charging a premium for the same gigabytes.

You're not wrong about the arithmetic. Let me tell you why the arithmetic is the wrong lens here.

The honest part first
Per gigabyte of RAM, a big commercial host is cheaper than us. Sometimes a lot cheaper. If your only requirement is "I need a box with a lot of memory and I don't care about anything else," you should go buy that box. I'm not going to pretend a Pro plan wins a pure $/GB race, because it doesn't, and you'd catch me lying inside five minutes.

So if that's you — go. Seriously. No hard feelings.

Still here? Then you probably have a second requirement, and it changes everything.

Try to actually buy it
Go and try to rent 80 GB of RAM without a credit card and without uploading an ID. Not "sign up and add a card you promise not to use" — actually pay with crypto, with nothing but an email, and get root.

You'll find that almost nobody sells that. The cheap per-GB hosts are cheap partly because they run you through payment rails and identity checks that filter out exactly the customers who want to pay in USDC and not say who they are. The moment you need real memory and no KYC, the field of options collapses to a handful — and the per-GB price stops being comparable, because you're no longer shopping for the same product.

That's the whole point. Pro isn't "expensive RAM." It's "RAM you can get on terms almost nobody offers."

What the price is actually for
When you pay for a Pro plan you're buying a bundle that normally doesn't come together:

High memory — 32 to 80 GB, enough to hold a real vector index in RAM or run a fleet of agents that share state.
No identity check — email and crypto, that's it.
A dedicated IPv4 with every port open, so you can actually host something that listens (an API, a model server, a VPN endpoint), not just make outbound calls.
Nightly auto-backups on the Pro line, so a 64 GB box full of your work isn't one bad command away from gone.
Agent-orderable — an AI agent can provision it over MCP or REST without a human in the loop.
Any one of those you can find somewhere. The combination, paid in crypto, is the rare thing.

Who this is genuinely for
A few workloads eat memory for real reasons, not because someone over-provisioned:

Self-hosted RAG at scale. Good vector search wants the index in RAM. A few hundred thousand embeddings fit in a couple of gigs; a few million, with the app and OS around them, and you're looking at 32–48 GB before you've done anything clever. Keep it on disk instead and search gets slow — the whole reason you self-hosted evaporates.

Multi-agent systems that hold state. A crew of agents that only fire off API calls is light. But give them shared memory, long histories, a working set they pass around, and the RAM curve bends up fast. This is where a single 64 GB box quietly replaces three smaller ones you'd otherwise be juggling.

Private inference and data work. Running a quantized model on CPU, or crunching a dataset that has to stay in memory, or co-locating several production services — memory-bound, all of it. And if the data is sensitive enough that you're paying in crypto to avoid a paper trail, a server you fully control is the point, not a nice-to-have.

When you should not buy Pro
Let me save you money. If KYC genuinely doesn't bother you and you just want cheap RAM — a mainstream host wins, take it. If your agents only call an LLM API and barely touch local memory, our own NAT and dedicated-IP plans from $3–20 are plenty; you don't need Pro. And if you need a GPU for real-time inference, no CPU-and-RAM box (ours or anyone's) is the answer.

Pro earns its price in exactly one situation: you need a lot of memory and you need to pay privately, with no card and no ID. When both are true, the per-GB comparison isn't just unfavorable to us — it's measuring the wrong thing, because the cheap option was never actually available to you.

That's the plan. If it fits, the Pro line starts at 32 GB; size up from there.

High-memory VPS for AI agents: when your fleet actually needs the RAM

EQVPS — Sun, 09 Aug 2026 11:42:24 +0000

The mistake I see most often with agent hosting is sizing for the wrong thing. Someone runs one agent, it uses 400 MB, and they conclude agents are cheap to host. Then they scale to a real crew and the box starts swapping at 3 a.m.

One agent is cheap. That's not the interesting case.

Where the memory actually goes
An agent that only fires off API calls to a model is light — it's mostly waiting on the network. You could run a dozen of those on a small plan and never notice.

The RAM disappears when agents start holding state. Conversation history that grows every turn. A working set several agents read and write. A vector store for long-term memory sitting in the same process. The moment your architecture stops being "call API, forget" and becomes "remember, coordinate, hand off," memory becomes the constraint, not CPU.

CrewAI, LangGraph, AutoGPT-style loops — they all trend this way as they get serious. The framework doesn't eat the RAM; the state does.

Rough sizing, honestly
I won't pretend there's a formula, because there isn't — it depends entirely on how much each agent keeps around. But a practical feel from running these:

Light, API-bound agents — you don't need Pro at all here; a NAT or dedicated-IP plan ($3–20) handles it. Pro earns its place once shared state pushes you past ~32 GB.
32 GB — the sweet spot for a real multi-agent system: 5–10 agents with shared memory plus a vector database that's actually useful. Most people land here.
64 GB — bigger fleets, longer histories, a memory index in the millions of vectors, or several services co-located. This is where one box replaces the three smaller ones you'd otherwise juggle.
80 GB — heavy, memory-bound work: large in-memory datasets, many concurrent agents, or agents plus local model inference on the same host.
Start below where you think you need to be. Watch htop for a day. Resize up when you see swap, not before — guessing high just wastes money.

The part that's hard to buy
Here's the thing that makes this awkward: renting 64 GB of RAM is easy. Renting 64 GB with crypto and no identity check is not. Most hosts that sell serious memory cheaply do it behind a card and a KYC form.

If your agent provisions its own server, or the workload touches data you'd rather not tie to a name, that combination — high memory, crypto, no KYC, and orderable by the agent itself over MCP — is the actual product. It's not cheaper per gigabyte, and I've written separately about why that comparison misleads. It's available on terms almost nobody offers.

So what do you do
If your agents are light and API-bound, don't overthink it — a small NAT or dedicated-IP plan is plenty, skip the whole high-memory question. If you're running a real fleet that holds state, size by what's actually in memory, start at 32 GB, and move up when the graph tells you to.

When you're there, the Pro line covers 32 to 80 GB with a dedicated IP and nightly backups. Pick the tier that matches your working set, not your ambitions.