What Can You Actually Run in 256 MB of RAM?

What 256 MB actually is

256 MB is not a rounding error — it is a real computer's worth of memory for the right job. The catch is that it is shared with the whole operating system, not handed to your app. A stripped-down Alpine container leaves you noticeably more of it than a full Debian one, which is the first decision worth making on a small box.

The $1 starter plan gives you 256 MB of RAM, one CPU core, 5 GB of disk and a 100 Mbps connection with unmetered data. That is a complete server for a workload that is idle most of the day and busy in short bursts — which describes more of what students and hobbyists actually build than you would expect.

Things that run comfortably

Event-driven and idle-cheap workloads do not care much about your RAM. A Telegram or Discord bot that wakes up when a message arrives, a small Python or Node API that answers occasional requests, a cron job that fetches and processes data every hour, a static site served straight off disk — all of these sit quietly and use memory only when something happens.

A development box is another good fit: a place to SSH into from anywhere, keep your notes and scripts, run `tmux`, use `git`, and try things without touching your laptop.

• A bot for Telegram, Discord or Slack with a couple of commands
• A static site or a small API behind a tunnel
• Scheduled jobs: scraping, reports, backups, reminders
• A SQLite-backed app — the database is a file, not a service
• A persistent SSH workspace with tmux and git

Things that will fight you

Some workloads treat 256 MB as a suggestion and then ignore it. A full database server with default settings will happily claim more memory than you have. Anything running on the JVM arrives with a sizeable baseline before your code does. Building a large project on the box — the install step, the compiler, the bundler — is often the most memory-hungry moment in its whole life.

You *can* squeeze some of these in: swap a database server for SQLite, use prebuilt binaries instead of compiling, pick Alpine over Debian. But notice what you are doing — spending your evening saving 20 MB. When that starts happening, the tier is the problem.

How to survive on 256 MB

Pick Alpine if you are comfortable with it: the base system is far smaller, which hands the difference to your app. Keep one service per container instead of three. Prefer static output and SQLite over long-running servers that cache everything.

Build somewhere else. Assemble your project on your laptop or in CI, then copy the finished artifact to the server — you get the same result and never pay the build's memory bill in production. Keep logs rotated, and restart the services you no longer need rather than leaving them resident forever.

When to move up, and how to know

The honest test is not a number, it is the direction of your time. If you are changing what you build to fit the box, you are on the right plan. If you are changing the box to fit what you build — removing features, rewriting in a leaner language, hunting for what to kill — you have outgrown it, and fighting on costs more than the difference in price.

The $2.99 basic plan doubles the memory to 512 MB and triples the disk to 15 GB, and it is the right home for a database-backed app, two services that need to run at once, or anything you want to build on the server itself. Same container, same key door, same 100 Mbps unmetered — just enough room to stop optimising.