Skip to content

Choosing an App Definition

Every App Server is created from an App Definition — a reusable template that carries the OS, the build procedure, the exposed ports and the server plans. The App Server is a duplicate of that template, not a link to it: once created, it owns its own configuration and you can change it freely without affecting anyone else.

This page helps you pick the right one.

The two families

Family What it gives you Pick it when
Generic Ubuntu A clean Ubuntu LTS server, a database, a public HTTPS URL, and a browser IDE. Nothing else is installed. Your repository knows how to build itself. You describe setup and build in .muppy/mpy_setup.sh, and your processes in .muppy/services.yml.
Stack templates (Odoo 18 / 19, Muppy, Sunray) The same, plus the runtime pre-wired — dependencies, launcher, systemd units, database initialization. You are deploying that specific stack and want the plumbing done for you.

If you are deploying something that is not Odoo — Node.js, Python, Go, Rails, a static site — you want a generic template.

Generic Ubuntu templates

Template Ubuntu Status
ubuntu26-v3-generic-template 26.04 LTS Recommended for new App Servers
ubuntu24-v3-generic-template 24.04 LTS Supported — pick it when a dependency is not yet packaged for 26.04

Both are identical apart from the OS image. Both give you:

  • an Ubuntu LTS container with a muppy user and your repository cloned,
  • a PostgreSQL database,
  • a public HTTPS URL through Traefik,
  • code-server — the browser IDE — on every qualifier (dev, test, staging, production),
  • your build, driven by .muppy/mpy_setup.sh.

Which Ubuntu?

Start with 26.04 LTS. It is the current LTS and gets the longest support window.

Choose 24.04 when something you depend on is not yet available for 26.04 — a vendor .deb, a language runtime that has not published packages, a database client from a third-party apt repository. That is the whole decision; there is no other difference between the two templates.

The OS is fixed at creation

An App Server keeps the OS of the App Definition it was created from. There is no in-place distribution upgrade. To move an existing app to a newer Ubuntu, create a new App Server from the newer template and migrate your data to it.

What the generic template expects from your repository

The generic template installs nothing beyond the base OS — your repository describes the build. Two files, both under .muppy/:

File Role
mpy_setup.sh Installs system prerequisites (setup stage) and builds the app (build stage). See the mpy_setup.sh guide.
services.yml Declares the long-running processes Muppy turns into systemd units. See the services.yml guide.

Muppy creates a starter mpy_setup.sh for you from a default template — you edit it in the Setup Script tab of the App Server, or commit your own version to the repository.

Bind to $APP_HTTP_PORT

Traefik routes your public URL to port 8000 inside the container, surfaced as APP_HTTP_PORT in /etc/muppy.env. An HTTP service that hard-codes its own port (3000, 8080, an upstream default…) is unreachable through the public URL even though the process is running.

Sizing

ubuntu26-v3-generic-template ships five plans — three containers and two virtual machines:

Plan Machine vCPU RAM Disk
M LXC container 2 4 GB 40 GB
M+ LXC container 3 6 GB 40 GB
Unlimited LXC container no cap no cap pool default
M Virtual machine 2 4 GB 40 GB
M+ Virtual machine 3 6 GB 40 GB

M (LXC) is the default. Sizing is a workload question, not a template question — see Per-Stack Plan Selection for how to reason about it, and note that build peaks are often larger than steady-state run.

Container or virtual machine?

An LXC container shares the host kernel: it starts in seconds, uses less memory, and its CPU and RAM caps can be changed later without a rebuild. This is the right default.

A virtual machine runs its own kernel. Choose it when your workload needs one — loading kernel modules, nested virtualization, Docker-in-Docker with strict isolation, or a stricter security boundary between tenants. It costs more RAM and boots more slowly.

The Unlimited plan

Unlimited sets no CPU, RAM or disk cap at all: the container uses whatever the LXD host has available, and its root disk grows into the storage pool.

Use it when:

  • you don't yet know the workload's ceiling and want to measure before committing to a size;
  • the host is dedicated to this single App Server.

Avoid it on a shared host: with no cap, one runaway process can starve every other container on the machine. There is deliberately no Unlimited virtual machine — a VM is allocated fixed CPU and memory when it boots, so the notion does not apply.