None. Local only. The block storage mounts are too heavy for 64MB — you're right, the kernel cache pressure kills it. I rsync to a Backblaze B2 bucket weekly from a bigger box, keep the slice lean.
Block storage on sub-256MB is a trap.
Member
Similar setup in Osaka but I use knot-resolver instead. Smaller memory footprint, same protocol support. Compiled with luajit disabled — saved another 8MB.
The real enemy is log rotation. Without journald you need something watching /var/log or it fills and oom-kills from the other direction.
Following.
I had a 128MB GreenCloudVPS in Singapore for shadowsocks. Worked until 2022 when their kernel moved to 5.15 and the wireguard module alone ate 12MB more. Couldn't downgrade. Migrated to HostHatch Tokyo, same price, still alive.
The kernel growth is the silent killer, not userland.
Member OP
This. I pin to 5.10 LTS on the BuyVM slice, custom kernel, no modules I don't load. 5MB saved vs. generic.
But BuyVM Luxembourg is the only location where they'll let you netboot your own kernel without IPMI fees. New York and Vegas both wanted $15/month for the privilege. Article 22 GDPR profiling concern? I asked. They said "technical limitation." I said "convenient."
Member
Frankfurt perspective: that location is underrated for EU latency. I route through DE-CIX to them, 8ms. But their DDoS filtering is Vegas-optimized. Had a 3Gbps UDP reflection hit the Luxembourg IP last year, took 45 seconds to trigger vs. 8 seconds on my Vegas test box.
Same $2 plan, different network personality. Worth knowing if you're using it for anything latency-sensitive under load.
In Milan I keep a 256MB HostHatch instance for MTR probes to our POPs. Could probably shrink it but why bother — the storage VPS pricing makes the compute almost free at that tier.
128MB feels like the 32MB servers I ran in 2005. Possible, but you're maintaining a museum piece.
Benchmarked this properly last month. 128MB HostHatch Zurich, single core:
sysbench memory run: 1,847 MiB/s
sysbench cpu run: 1,023 events/sec
boot time: 8.2s (systemd) vs 4.1s (OpenRC)The memory isn't the bottleneck. The scheduler is. One process wakes, everything else swaps. Throughput collapses under any parallelism.
Numbers over vibes: 128MB is viable for exactly one thread doing exactly one thing.
Confirmed. My 128MB node runs two things: bird2, and a shell script that curls a health endpoint. When both fire together? 12-second stall. I staggered the cron by 17 seconds, problem solved.
This is not engineering. This is astrology.
Same here. 128MB BuyVM Miami, OpenVPN not WireGuard. TCP-based so the kernel buffers hurt more. One user connecting = fine. Two = fine. Three = swap spiral, 90 seconds to recover.
I limit to two certificates and tell friends to pick shifts.