Per-Stack Plan Selection¶
Muppy App Server templates are generic: they carry no built-in workload assumptions. Sizing is a workload concern — you pick CPU and RAM based on what your app actually does. This page is the reference for that choice.
Why two columns: Build and Run
Many apps need much more memory to build than to run. You can provision one App Server to build and run your app, or — more commonly in production — provision a Build server that compiles the app and a separate Run server that only executes the artifact. Pick each plan according to its actual role.
Add headroom for AI agents
If you run an AI coding agent (Claude Code, GitHub Copilot CLI, Cursor, Aider, …) on the server itself, add its footprint on top of the Build+Run numbers:
- Claude Code CLI: reserve ~4 GiB extra RAM (Node runtime + context cache + tool processes).
- Smaller agents (shell-based wrappers, language servers): +1–2 GiB.
Agents running on the developer's laptop don't count — only server-side agents consume server RAM.
Stack → CPU / RAM recommendations¶
Values are vCPU × RAM. Build and Run are independent roles — size each server for its actual job.
| Stack | Build — minimum | Build — recommended | Run — minimum | Run — recommended |
|---|---|---|---|---|
| Static site (plain HTML/CSS, Hugo, mkdocs) | 1 × 1 GiB | 1 × 1 GiB | 1 × 1 GiB | 1 × 1 GiB |
| Pure Python (stdlib only, no native deps) | 1 × 1 GiB | 2 × 2 GiB | 1 × 1 GiB | 1 × 2 GiB |
| Go (single-binary) | 2 × 2 GiB | 2 × 2 GiB | 1 × 1 GiB | 1 × 1 GiB |
| Node (Next.js, Vite, webpack bundle) | 2 × 2 GiB | 2 × 4 GiB | 1 × 1 GiB | 2 × 2 GiB |
| Python with native deps (pillow, numpy, psycopg2) | 2 × 2 GiB | 2 × 4 GiB | 1 × 1 GiB | 2 × 2 GiB |
| Ruby / Rails (bundle install, asset precompile) | 2 × 2 GiB | 2 × 4 GiB | 2 × 2 GiB | 2 × 2 GiB |
| Java / JVM (Gradle, Maven, Spring Boot, Quarkus) | 2 × 4 GiB | 2 × 4 GiB | 2 × 2 GiB | 2 × 4 GiB |
| .NET / MSBuild | 2 × 4 GiB | 2 × 4 GiB | 2 × 2 GiB | 2 × 4 GiB |
| Rust (release build) | 2 × 4 GiB | 4 × 8 GiB | 1 × 1 GiB | 2 × 2 GiB |
| C++ (CMake, large projects) | 2 × 4 GiB | 4 × 8 GiB | 1 × 1 GiB | 2 × 2 GiB |
Values in bold are the plan we most often see customers end up on after a first-round incident.
Why the build column is often bigger¶
Build-time memory is dominated by the toolchain's daemons and in-memory work, not by your source code size:
- Gradle / Maven / Kotlin compiler: JVM heap defaults to 512 MiB – 1 GiB per daemon; parallel compilation pushes the peak to 1.5 – 2 GiB. On a 1 GiB machine, the Linux OOM killer intervenes.
- Node bundlers (Next.js, webpack, Vite production build): V8 heap default is ~1.5 GiB; memory-intensive rewrites (tree-shaking, minification, source maps) sustain high usage for seconds to minutes.
- Python native deps:
pip installof a wheel is fine on 1 GiB, but a source install with C extensions (psycopg2, uwsgi, some ML libs) needs a working compiler and enough RAM for headers/templates — 2 GiB minimum. - Rust release build:
cargo build --releasecompiles with optimizations; per-crate peak memory can exceed 1 GiB for medium-sized workspaces. - C++ with templates: instantiation memory can be surprisingly large; 1 GiB is usually too tight.
Why the run column is often small¶
Most apps run in a fraction of their build memory:
- A compiled Go or Rust binary uses the RAM its code actually needs, often under 100 MiB.
- A Spring Boot JVM runs comfortably in 256 – 512 MiB after JIT warm-up.
- A Next.js production server needs less than its build did — typically 2 GiB suffices.
- Python/Ruby servers land anywhere from 50 MiB (tiny Flask) to several hundred MiB (Rails with multiple Puma workers).
If you size the run server too generously you pay for idle RAM. Size it to the actual runtime peak + headroom; scale up on evidence, not fear.
What to do when sizing was wrong¶
You usually notice two symptoms:
- Build server too small: OOM killer log in
mpy_setup.shoutput (killed, exit code 137, Gradle daemon "disappeared"). Resize to a larger plan (mgx_resize_server) and retry. - Run server too small: service restart storm, OOM in
journalctl, slow first request. Resize up.
A resize keeps the data. vCPU and RAM move both ways — raise them aggressively, lower them conservatively and with a real measurement in hand — while the disk only grows, since no provider can shrink a filesystem safely. The machine type is fixed when the server is created, and a resize stays on the same App Definition: a Build server and a Run server of different machine types are two servers, each created from its own plan (Server Plans).