Skip to content

plan / nitro

Nitro: same cores, more memory

Four vCPUs like Turbo, but 12 GB of RAM and 120 GB of disk. Built for workloads that run out of memory long before they run out of CPU.

$15/mo USDor $150/yr

Deploy Nitro in London
vcpu
4
memory
12 GB
nvme disk
120 GB
port
1 Gbps
traffic
unmetered
ipv4
1 dedicated

The memory-bound middle

A surprising number of workloads hit a wall at 8 GB while four cores sit half idle. Java and Kotlin services with generous heaps. Redis holding a working set that is just too big. A search index that wants its segments in the page cache. A Rails or Django app with enough worker processes to keep up, each of them a few hundred megabytes. For all of those, more cores do nothing and more memory does everything.

Nitro exists for exactly that gap. It costs $2 more than Turbo and gives you 50% more RAM and 50% more disk. Per gigabyte of memory it is one of the better-value sizes on the price list.

Sizing a JVM on 12 GB

The mistake to avoid is setting -Xmx to nearly all of RAM. The heap is not the whole JVM: metaspace, code cache, thread stacks and direct buffers live outside it, and the kernel still needs page cache.

SliceSuggested
Heap (-Xms = -Xmx)6.5 GB
Metaspace, code cache, threads~1 GB
Direct buffers (Netty etc.)512 MB, capped
OS and sidecars~1 GB
Page cache~3 GB
JAVA_OPTS="-Xms6500m -Xmx6500m -XX:MaxDirectMemorySize=512m \
  -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ExitOnOutOfMemoryError"

Setting -Xms equal to -Xmx means the heap is committed at start, so you find out immediately if the plan is too small rather than at 2 a.m. under load. ExitOnOutOfMemoryError lets systemd restart a wedged process instead of leaving it half alive.

A cache that fits

If Redis is the reason you are here, give it a hard ceiling and an eviction policy, then let the rest of the box breathe:

# /etc/redis/redis.conf
maxmemory 7gb
maxmemory-policy allkeys-lru
save ""
appendonly no

Disabling persistence is right for a pure cache; it avoids fork-time memory spikes during snapshots. If Redis is your source of truth, keep persistence on and lower maxmemory to about half of RAM so a background save has room to copy pages.

Why 120 GB matters here

Memory-heavy services tend to be data-heavy too. Search indexes, Kafka-style logs, local artefact caches and database data directories all grow. The extra 40 GB over Turbo is often what lets you keep a week of logs or a full local index instead of trimming aggressively. On RHEL-family images such as Rocky Linux 9, check where space is going with:

du -xh --max-depth=2 /var | sort -h | tail -15

Choosing between neighbours

  • CPU is fine, memory is fine, disk is fine: you may be on the wrong side of the line. Turbo saves $2.
  • Memory is fine but four cores are pinned: go to Warp for six vCPUs and 16 GB.
  • One large in-memory data set needs far more than 12 GB: skip ahead to Hyper and its 32 GB.

The portal's CPU graph will tell you quickly which side of the box you are pushing against. Give it a week of real traffic before deciding.

Price

Nitro is $15 a month or $150 for a year. Checkout charges in US dollars; a card in another currency is converted by your issuer. No setup fee, unmetered traffic on a 1 Gbps port, and one dedicated IPv4.

Questions

Why would I pick Nitro over Warp?

Warp adds two cores and 4 GB more RAM for $7 extra. If your CPU graphs are calm and only memory is tight, Nitro gives you the memory without paying for cores you will not use.

How big should my JVM heap be on Nitro?

A common starting point is 50 to 60 percent of RAM for a single JVM, so around 6 to 7 GB, leaving the rest for metaspace, thread stacks, the OS and page cache. Measure and adjust.

Can I run OpenSearch or Elasticsearch on Nitro?

A single small node for logs or site search is reasonable. Give it a fixed heap of about 4 to 6 GB, leave the rest for the filesystem cache, and keep shard counts low.