DEV Community: EQVPS

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.

Run a CrewAI multi-agent crew on a VPS

EQVPS — Thu, 06 Aug 2026 17:31:49 +0000

Your CrewAI crew runs great on your laptop. The agents talk to each other, the researcher hands off to the writer, the whole thing hums — right up until you close the lid and it all stops. Or your wifi drops mid-task. Or you reboot and forget to restart it.

A crew that only runs while you're watching isn't automation. It's a demo. Moving it to a VPS is what turns it into something that actually works while you sleep.

Why a server, not your machine
The pitch is simple: a VPS is a computer that never closes its lid. It has a fixed IP, it doesn't sleep, and if the process dies it can bring itself back. For a multi-agent crew — which by design runs long, chatty, multi-step jobs — that's the difference between "it worked once" and "it's been running for three weeks."

There's a second reason that trips people up in a good way: you don't need a powerful machine. More on that next, because it's the question everyone asks first.

No, you don't need a GPU
This is the part people get wrong about hosting agents. CrewAI is an orchestrator. It decides which agent acts, in what order, with what context — and then it asks a language model to do the actual reasoning. That model almost always lives behind an API: you send a request to OpenAI or Anthropic, they run it on their GPUs, you get text back.

So your server does three things: run Python, hold the crew's state, and make HTTPS calls. None of that touches a GPU. A plain CPU VPS is exactly right. The only time that changes is if you also want to run the model locally — but that's a separate, heavier project, and most crews don't.

Practically: a 1–2 GB plan runs a small crew without breaking a sweat. Go to 4 GB if you're running several crews at once, holding big conversation histories in RAM, or bolting on a vector database for long-term agent memory.

The actual setup
Fresh Ubuntu box, root in about a minute after ordering. Here's the whole thing:

Python + venv

apt update && apt install -y python3-venv python3-pip
python3 -m venv ~/crew && source ~/crew/bin/activate

CrewAI

pip install crewai crewai-tools

your project

mkdir ~/mycrew && cd ~/mycrew

copy your crew.py and .env up here (scp / git clone)

Your .env holds the one secret that matters — the LLM API key:

OPENAI_API_KEY=sk-...

or ANTHROPIC_API_KEY, etc.

Then a normal python crew.py runs it. That's the manual version. It works, but it dies the moment your SSH session closes — which brings us to the actual point of a server.

Keep it alive with systemd
tmux is fine for a quick test. For anything real, use systemd — it restarts the crew if it crashes and brings it up on reboot. Drop this in /etc/systemd/system/mycrew.service:

[Unit]
Description=CrewAI crew
After=network-online.target

[Service]
WorkingDirectory=/root/mycrew
ExecStart=/root/crew/bin/python /root/mycrew/crew.py
Restart=always
RestartSec=5
EnvironmentFile=/root/mycrew/.env

[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now mycrew
journalctl -u mycrew -f # watch it work
Now the crew runs on boot, restarts on failure, and logs everywhere you can read them. Close your laptop — it doesn't care.

Paying for it
Signup is an email and a one-time code — no card, no ID. You fund a balance with USDC or USDT on Base, Ethereum or Polygon (Base is cheapest on fees), and orders draw from it. For a crew that mostly makes outbound API calls, the default NAT plan is fine and cheaper; pick a -ip plan only if the crew needs its own public IPv4 for inbound services.

One nice trick: EQVPS has an MCP server at mcp.eqvps.com/mcp. If provisioning is itself one of your crew's jobs, an agent with a funded balance can call order_vps and stand up a box on its own — no human at the checkout.

What's honest to say
You bring the LLM API keys. We host the crew, not the model. Your OpenAI/Anthropic bill is separate and, for a busy crew, usually the larger cost — the VPS is the cheap part.

It's CPU-only, one datacent``er in Germany. No local GPU inference, and latency is best if your users or APIs are Europe-adjacent. For a crew hitting US-hosted LLM APIs the extra hop is milliseconds — irrelevant next to model latency — but worth knowing.

Size for your memory, not your model. The thing that actually grows your RAM use is conversation history and any vector store you add, not the number of agents. Watch journalctl and htop for a day and resize if you need to.

The takeaway
A CrewAI crew belongs on something that doesn't sleep. The move is short: a CPU VPS, pip install crewai, a systemd unit, your API key in a .env. Ten minutes and your crew is running 24/7 instead of "whenever the laptop's open." Root in about a minute, pay in crypto, resize when the memory tells you to — and let the agents get on with it.

Run your own Bitcoin node on a VPS

EQVPS — Sun, 02 Aug 2026 17:16:14 +0000

Running your own node is the line between taking someone's word about the chain and verifying it yourself. Your node enforces every consensus rule independently, and your wallets can query your node instead of a public server that quietly logs all your addresses. The wall people hit: a full archival node wants 600 GB+ of disk and keeps growing. A pruned node steps around that — it still validates the entire chain, then discards the old blocks it no longer needs, landing around 10–15 GB. That fits a small VPS. Here's the honest how, and what pruning costs you.

What a node actually gives you
Independent validation. You enforce the rules yourself. Nothing invalid gets past your node because it believed a stranger.
Privacy for your own queries. Your wallet asks your node, not a public explorer that sees every address you look up.
A base for the rest. A node is the foundation other things sit on later — Lightning, explorers, your own apps.
Pruned vs full — the honest core
During the initial sync, your node downloads and verifies the entire chain. That's roughly 600 GB of bandwidth, once. Pruning changes only what happens after: it keeps recent blocks and drops the old ones, so final disk stays small.

What you give up is real: a pruned node can't serve historical blocks to other peers, and it can't rescan arbitrary old wallet history. So if you'll import an old wallet with early transactions, you need full history — a full node on a big disk, not a pruned one. For simply validating and running current wallets, pruned is exactly right.

What you need
Disk: ~15–20 GB for a pruned node — a small box is fine.
RAM: 2–4 GB. More dbcache speeds the initial sync; you can lower it afterward.
Bandwidth: real throughput for the one-time full download.
A reachable IP: to accept inbound peers on port 8333 and actually help the network, you want a public IP with 8333 open — a dedicated-IP plan. On NAT you get one SSH port and can't open 8333.
The setup
Install bitcoind, then a minimal bitcoin.conf:

prune=10000 # keep ~10 GB of recent blocks
dbcache=2048 # faster initial sync; lower it later
listen=1 # accept inbound peers
Run it under systemd so it restarts on crash and comes back after a reboot, and open port 8333 so peers can reach you. Then let it sync — this is the long part, hours to a day or two, because it's verifying the whole chain from genesis.

Lock it down
Keys-only SSH, firewall to 8333 and your SSH port. (The ten-minute checklist.)
Never expose the RPC port to the internet. Bind it to localhost and reach it over an SSH tunnel or only from apps on the same box. An open RPC is an open door.
The honest limits
The first sync is long and bandwidth-heavy. That's inherent — validating the chain from scratch isn't a step you can configure away.
A pruned node can't serve old blocks or rescan old history. Need those? That's a full node and a big disk.
Monero is a fair question, and the honest answer is scope. Its chain is larger — a couple hundred GB, and even pruned around 90 GB — so it wants a bigger disk than our small plans carry. That's a full-node story for a different kind of box, and we'd rather say so than pretend it fits.
You maintain it: updates, disk, the occasional peer hiccup. A node is a small commitment, not a fire-and-forget.
Paying for it
Sign up with an email and pay in USDC or USDT — no card, no ID. A fitting way to pay for running your own corner of Bitcoin.

How I Built an MCP Server That Lets AI Agents Rent VPS

EQVPS — Sun, 02 Aug 2026 15:51:26 +0000

I built an MCP server that lets AI agents autonomously rent VPS servers — no human, no KYC, no card. Here's how.

The Problem
AI agents need always-on infrastructure to run 24/7. But today, provisioning a VPS requires:

A credit card
KYC verification
A human to click through signup flows
That's not infrastructure for autonomous agents. It's infrastructure for humans.

The Solution: EQVPS MCP Server
EQVPS is a crypto-native VPS host with an MCP server that exposes the full server lifecycle as tools:

claude mcp add --transport http eqvps https://mcp.eqvps.com/mcp
Once connected, an agent can:

list_plans — browse available VPS plans
register_account — create an account with just an email
topup_balance — generate a crypto payment invoice
order_vps — spin up a server in ~60 seconds
power_vps — start, stop, reboot
get_vps_status — get IP, SSH credentials, metrics
cancel_service — tear down when done
How It Works
The MCP server maps 16 tools to REST API endpoints. Authentication uses Bearer tokens — agents get their own token via register_account. Humans sign in with email OTP; agents use the API flow.

Payments go through USDC, USDT on Base, Ethereum, or Tron. No KYC. No bank account.

Why This Matters
This is a pattern I call infrastructure-as-tool. When an MCP server exposes infrastructure provisioning, agents can:

Self-provision — spin up workers on demand
Self-heal — if a server crashes, order a new one
Self-scale — monitor usage and provision more capacity
Imagine an agent that monitors a queue, spins up a VPS when traffic spikes, processes work, and tears down the server when done. All without a human in the loop.

Getting Started
Deploy a VPS (Ubuntu 24.04, 2–4 GB RAM) — paid in crypto, no KYC
Install Docker and launch your agent framework
Lock down access with SSH keys and tunneling
Connect the EQVPS MCP server so your agent can scale itself
Full documentation: eqvps.com/docs MCP server source: github.com/Poiuyhje/eqvps-mcp

What's Next
Add more regions and OS options
Build a Terraform provider for EQVPS
Integrate with more agent frameworks (CrewAI, AutoGen, LangGraph)
Open-source the MCP SDK so anyone can build infrastructure MCP servers
If you're building AI agents that need infrastructure, this is the stack. No gatekeepers, no KYC, no credit cards. Just crypto and code.