VPS with 1 GB RAM: what fits and how not to run out of memory
One gigabyte of RAM is the floor at which a modern Linux server still runs without a constant fight for resources. It is enough for one task, not for "everything at once": a bot, a small site without a heavy CMS, an internal service for a team. If you know in advance how much each process takes, a VPS with 1 GB RAM can run for months without reboots. If you install everything in sight, the first sign of trouble will be a crashed database.
What really fits in 1 GB
A clean system without a GUI takes 120–250 MB: least for Alpine and minimal Debian, more for Ubuntu with snapd and cloud agents. The rest is divided like this:
- A Python or Node.js bot: 50–200 MB per process. Two or three bots with SQLite fit comfortably; more in the VPS for a Telegram bot section.
- A static site or landing page on Nginx: tens of megabytes, leaving plenty of memory to spare.
- A corporate VPN for staff remote access to the office: WireGuard itself runs in the kernel and uses almost no memory, while a management panel adds 100–150 MB. See VPS for WireGuard.
- A PHP site with a small database: possible, but tight. MariaDB with a trimmed buffer takes 150–250 MB, leaving room for 3–5 PHP-FPM processes.
- Monitoring agents, a DNS server, a backup MX, cron jobs: the typical "utility" load for a server like this.
What won't fit: Docker with a database, cache and application together, Windows Server, Java applications with a heap over 256 MB, Minecraft, GitLab, Elasticsearch, and also front-end builds via npm or compiling large packages. For such tasks take a VPS with 2 GB RAM or more. The opposite happens too: for a single bot or a VPN for a couple of staff members a gigabyte is overkill, and a 512 MB plan will do just as well.
Swap and the OOM killer: insurance, not extra capacity
When processes run out of memory, the kernel starts the OOM killer and terminates the "heaviest" of them, usually the database or the application's interpreter. On 1 GB this most often happens during package updates, backups or traffic spikes.
- Create a 1–2 GB swap file:
fallocate -l 1G /swapfile,chmod 600,mkswap,swaponand a line in/etc/fstab. - Set
vm.swappiness=10so the kernel only uses swap when memory is genuinely short. - An alternative is zram: compressed swap right in memory. On a slow disk it works faster than an ordinary swap file.
- To find out which process the kernel killed, use
journalctl -k | grep -i "killed process".
Swap is no substitute for memory: if the server is constantly swapping, the site will take seconds to respond. That is a signal to move to a bigger plan, not to enlarge the swap file.
Guaranteed memory and container virtualisation
On KVM the whole gigabyte is allocated to the virtual machine, and the kernel inside sees exactly that. On OpenVZ and LXC, plans often list two figures: the guaranteed amount and burst, memory the container can borrow temporarily if it is free on the node. Burst is not promised to anyone: at peak hours the neighbours take it, and processes crash even though your monitoring showed headroom. Use only the guaranteed figure for planning. On top of that, in a container you can't create your own swap or change kernel parameters, which matters more on 1 GB than on bigger plans.
How to check memory after buying
free -h: look at the available column, which is the amount programs can get without evicting the cache. Near-zero free with a large available is normal.cat /proc/meminfo | head -5: on KVM, MemTotal is usually 50–100 MB below the advertised figure, because the kernel takes part of it. If the gap is hundreds of megabytes, ask support.systemd-detect-virt: shows kvm, openvz or lxc and confirms which virtualisation you actually have.ps aux --sort=-rss | head: a list of the most memory-hungry processes. Unneeded services such as snapd, cloud-init or ModemManager can be disabled after the first boot.
Cores and disk on 1 GB plans
Such a plan usually comes with one virtual core and a 10–25 GB disk. The CPU is enough for a bot or VPN, but check the disk: logs and the package cache quickly eat up 10 GB. If the choice is between 1 GB on NVMe and 1 GB on HDD, take NVMe, as the difference in responsiveness is noticeable when swap is active. And for a system with minimal memory use, consider a VPS with Alpine Linux: it boots in about 50 MB.