Upgrading a No-KYC VPS: How to Scale Up Without Downtime (or Losing Privacy)

Short answer: on a no-KYC, crypto-paid VPS you scale up one of two ways — an in-place resize to a bigger plan (ask the provider whether it's offered on your node), or the always-available path: deploy a second VPS on the larger plan, sync your data, flip DNS, and let the old one expire. The second method takes an hour or two of work and costs a few euros of overlap, and it gives you near-zero downtime plus a working rollback. That's why starting on a €3.99/mo plan is a low-risk decision rather than a trap.

This matters more on an anonymous host than on a mainstream one, because there's no card on file to auto-upgrade and no support rep who'll do the migration for you. The good news is the process is entirely in your hands, and it's genuinely predictable once you know the order of operations.

First: are you actually out of capacity?

Plenty of "I need a bigger VPS" moments are really misconfiguration. Check before you pay.

RAM. Run free -m and look at available, not free — Linux uses spare RAM as cache by design. Then check for kills: dmesg -T | grep -i -E "oom|killed process" or journalctl -k | grep -i oom. Repeated OOM kills under normal traffic mean you're genuinely short. A single kill during a one-off import usually doesn't. If a database and a PHP or Node process are fighting over 1 GB, tuning buffers and worker counts often buys you months — the specifics are in the guide on low-RAM VPS tuning with swap, zram and the OOM killer.

Disk. df -h / and df -i / (inodes can run out before bytes do). Then find the real consumer: du -xh --max-depth=1 / | sort -h. On a 25 GB NVMe plan, the culprit is frequently logs, Docker image layers (docker system df), or local backups that should live off-site anyway.

CPU. uptime load averages relative to your vCPU count, plus top — watch the st (steal) figure. High steal means contention on the host, not your workload; high user/system time means you need more cores. The difference matters, and the steal time and I/O tests guide walks through how to tell them apart.

Bandwidth. Install vnstat and look at monthly totals. A VPN exit for a household or a media-heavy site can outgrow 1 TB long before it outgrows 1 GB of RAM — bandwidth, not CPU, is often the real reason to move up a tier.

If three of those four are comfortable and one is pinned, fix the one. If two or more are pinned at your normal peak, upgrade.

Picking the next tier up

On IronBalkans the ladder is straightforward, and every tier includes the same fundamentals — real KVM virtualization with dedicated vCPU, RAM and NVMe, DDoS protection, one dedicated IPv4 and a /64 IPv6 block:

• Iron 1 — €3.99/mo · 1 vCPU, 1 GB RAM, 25 GB NVMe, 1 TB transfer
• Iron 2 — €7.99/mo · 2 vCPU, 4 GB RAM, 60 GB NVMe, 4 TB
• Iron 3 — €14.99/mo · 4 vCPU, 8 GB RAM, 120 GB NVMe, 8 TB
• Iron 4 — €29.99/mo · 8 vCPU, 16 GB RAM, 240 GB NVMe, 16 TB

The jump from Iron 1 to Iron 2 is the big one in practical terms — RAM quadruples, which is usually what kills a 1 GB server. Beyond that, be honest about which resource you're actually buying: if you need 8 TB of transfer but only 2 GB of RAM, you're still paying for Iron 3's cores, so it's worth checking whether a second small server handles the bandwidth-heavy job instead. The plan sizing guide maps tiers to workloads in more detail.

One thing a no-KYC host with flat monthly pricing removes from the equation: there's no promotional rate that doubles at renewal, and no metered overage bill if you misjudge. You pay the listed monthly price in crypto, and that's the number. If you've been burned by first-year pricing elsewhere, this is the part worth checking before you commit — and IronBalkans accounts need no email, name or ID to open, so testing the next tier up doesn't mean handing over more personal data than you already haven't handed over.

Path A: in-place resize

Some providers can grow a KVM instance's RAM, vCPU and disk on the existing node. When it's available it's the simplest option: a reboot, maybe a filesystem grow (growpart plus resize2fs or xfs_growfs), and you keep your IP address, TLS certificates, SSH host keys and DNS exactly as they were.

Two caveats. First, availability depends on free capacity where your VM lives, so it isn't guaranteed — ask through the provider's contact channels (Telegram or SimpleX in IronBalkans' case) before you plan around it. Second, resizes usually only go up cleanly; shrinking a disk is messy or impossible. If you're unsure whether you'll stay at the bigger size, Path B gives you a cleaner exit.

Either way: take a backup first. A resize that touches the partition table is exactly when you want a restore-tested off-site copy sitting somewhere else.

Path B: deploy, sync, cut over (always works)

This is the method to default to, because it never depends on node capacity and it keeps the old server running as a rollback until you're satisfied.

1. Back up and verify a restore. Not "run a backup" — actually restore the database dump somewhere and confirm it loads. If you don't have a repeatable job, set one up now with restic or Borg; you'll use it during the move anyway.
2. Lower DNS TTL first. Drop records to 300 seconds at least a day ahead. This single step is the difference between a 5-minute cutover and users hitting the old IP for hours.
3. Deploy the larger plan. Deployment finishes in under a minute after payment confirms, so there's no waiting on provisioning. Choose the same distro and major version as the old server unless you deliberately want a distro change — doing both at once doubles the number of things that can break.
4. Rebuild, then sync. Install packages and configuration first, then move data with rsync -aHAX --delete over SSH. Run it twice: once early to move the bulk, once at cutover for the delta. Dump and import databases at cutover, not before.
5. Test with the real hostname before DNS moves. Add an entry in your local /etc/hosts pointing your domain at the new IP and exercise logins, uploads, cron jobs and mail paths. Issue TLS certificates on the new box ahead of time — HTTP-01 validation needs DNS already pointing at it, so DNS-01 validation is easier here, or accept a short certificate gap.
6. Cut over. Put the app in maintenance mode or stop writes, run the final sync and database dump, update DNS, watch logs on both servers. Keep the old VPS alive for a few days in case something only surfaces under real traffic.

The full checklist — including firewall rules, cron duplication risks and decommissioning — is in the minimal-downtime VPS migration guide. The same procedure applies whether you're moving between providers or between plans at the same one.

What the upgrade costs when you pay in crypto

There's no card on file, so nothing auto-charges and nothing auto-upgrades. In practice that means you pay for the new plan when you deploy it, and simply don't renew the old one at the end of its month — how monthly crypto renewals work covers the timing, grace periods and exchange-rate mechanics.

Budget for a short overlap. Running Iron 1 and Iron 2 side by side for a few days of testing is cheap insurance, and it's the reason this path has a rollback at all. If exact proration or credit handling matters to you, ask before you pay rather than assuming — that's a fair question to put to any crypto-only host, and a provider that answers it plainly is telling you something useful.

Privacy side effects of scaling up

A new VPS means a new IPv4 address, which has real consequences:

• Mail reputation resets. If you self-host email, a fresh IP needs rDNS/PTR set and warm-up time. Check the new IP against blacklists before committing to it.
• Old IP references linger. DNS history services, hardcoded config, monitoring endpoints and firewall allowlists on other machines all remember the old address. Grep your configs.
• Don't re-link identity during the move. Transferring data through a third-party cloud drive tied to your name, or paying from an exchange withdrawal straight into the payment address, can undo opsec you already paid for. Keep the migration inside channels you control — SSH between the two servers directly, or your own off-site backup repo.

Staying with the same provider and the same anonymous account ID is the low-friction option here: your recovery key, payment method and account history don't change, and only the server behind them does.

Common mistakes

• Upgrading instead of debugging. A memory leak follows you to a bigger plan; it just takes longer to fall over.
• Skipping the TTL change. The most common cause of "my migration took all day."
• Deleting the old server immediately. Keep it until you've seen a full business cycle — nightly cron, weekly report, monthly invoice run — on the new one.
• Changing distro, web server and plan in one move. When something breaks you won't know which change caused it.
• Forgetting the firewall. A fresh install means your nftables or ufw ruleset, fail2ban config and SSH hardening don't exist yet. Don't expose the new box with default settings while you test.

Pros and cons of each path

In-place resize: keeps your IP, certs and DNS; minimal work; but depends on node capacity, needs a reboot, and is hard to reverse.

Deploy and migrate: always available, gives you a clean build and a tested rollback, forces you to verify backups; but costs an overlap period, a new IP, and a couple of hours of attention.

For a hobby site, the resize is nicer. For anything you'd be upset to lose, the migration path is the professional choice — and the backup and restore drill it forces you through has value on its own.

FAQ

Can I move down a plan later? Downgrading is harder than upgrading, mainly because disk has to shrink. Plan it as a migration to a smaller instance, not a resize.

Will I keep my IP address? With an in-place resize, yes. With a new deployment, no — you get a new dedicated IPv4 and a new /64 IPv6 block.

How long is the actual downtime? With low TTLs, a pre-tested new server and a final delta sync, the write-freeze window is typically a few minutes. DNS stragglers resolve within the TTL.

Do I need to create a new account for the second VPS? No. One anonymous account can hold multiple servers, which is also how people split a VPN exit from a public website.

What if I'm not sure which tier I need? Start a tier below where you think you'll land and measure for a month with vnstat and basic monitoring. Flat monthly pricing with no contract makes an upgrade a smaller decision than over-buying.

Get started

If you've already diagnosed the bottleneck and know which tier you need, the move is an afternoon's work with a safety net. Compare the specs at each tier on the IronBalkans pricing page, or open an anonymous account — no email, name or ID — and deploy the larger plan in under 60 seconds once your Monero, Bitcoin or Litecoin payment confirms.