How to run multiple apps on one VPS (and size it)

Yes, you can run several apps on one VPS. The limit is memory first, then disk, then how much shared failure you can accept. Put each app in its own container, put a reverse proxy in front on ports 80 and 443, give each domain its own certificate, and size the server for the apps running at once plus your largest build. On Aria Cloud a server runs up to five apps by default, and one aria.yaml holds up to 12 services and 6 databases. This guide covers the architecture, a sizing method with worked numbers, the failures to expect and when to add a second server.

What architecture works?

Keep it plain.

• One container per app, or per service. Containers give each app its own files, dependencies and restart policy.
• A reverse proxy on ports 80 and 443. It routes each domain to the right app and handles HTTPS. The official Next.js self-hosting guide recommends a reverse proxy such as nginx in front of the Node server, to deal with malformed requests, slow connections, payload limits and rate limiting.
• Apps listening on the loopback address only. Nothing but the proxy is reachable from outside.
• A default-deny firewall. Open 80 and 443, and SSH from addresses you trust.

On a raw VPS, an example per app looks like this:

docker run -d --name shop --restart unless-stopped \
  -p 127.0.0.1:3001:3000 -m 768m --cpus 1 shop:latest

shop.example.com {
  reverse_proxy 127.0.0.1:3001
}

The first block starts an app limited to 768 MB of memory and one CPU, reachable only on the machine. The second is a Caddy site block that sends a domain to it. Caddy obtains the certificate for you. Repeat for each app.

How do you size the server?

Do not average. Add the memory each app uses while running, add the largest single build once (builds run one at a time, so you do not add them together), add the operating system and proxy, then add spare. Aria’s own method follows these steps, with 20 percent spare and never less than 512 MB.

Here is a worked example from Aria’s sizing tool, estimateServer, for three small apps. These are estimates from typical memory use. They are not measurements, and your own apps will differ.

Item	Memory
Server base (Ubuntu, Docker, proxy)	416 MB
App 1: Next.js web service and Postgres	896 MB
App 2: API, worker and Postgres	1,280 MB
App 3: a static marketing site	32 MB
Running total	2,624 MB
Largest build (the Next.js app)	2,048 MB
Spare (20 percent)	935 MB
Total need	5,607 MB

That is 5.5 GB, so a 4 GB Starter server is short and an 8 GB Developer server fits with about 2.5 GB spare. Add two more apps, an API with Postgres and a second Next.js app with Postgres, and the need becomes 7,757 MB. That still fits Developer, with only 435 MB spare. At that point you are close to the edge, and Pro (12 GB) is the comfortable choice.

Two things this table teaches. Databases are expensive: each Postgres in this estimate takes 512 MB. And one build can dominate the total, because the estimate for a Next.js build is 2,048 MB while the app itself runs in a fraction of that.

Should the apps share one Postgres or have one each?

	One shared Postgres	One Postgres per app
Memory	Lower: one instance	Higher: about 512 MB each in Aria’s estimate
Isolation	A bad query in one app slows the rest	Each app is separate
Backups	One dump holds everything	One dump per app, restored on its own
Migrations	One app’s migration can lock another’s tables	Independent
Credentials	Shared unless you create a role per app	One set per app

On a raw VPS, a shared Postgres with a separate database and role per app is a common middle path. PostgreSQL’s pg_dump dumps one database at a time and does not include roles, so back up roles with pg_dumpall --globals-only too. On Aria each app declares its own databases in its own aria.yaml, which is the per-app model.

What goes wrong, and what fixes it?

Failure	Why it happens	The fix
A build starves production	Builds use more memory than the app does	Build one app at a time and size for the largest build. Aria does this and tells you that another app’s deploy waits while one builds
One app eats all the memory	A leak or a spike takes the machine’s RAM	Set a memory limit per container. Without -m, Docker warns the host itself can run out of memory
A kernel kill takes out a database	The out-of-memory killer picks a process	Give the database a limit and spare room, and keep an eye on restarts
Logs fill the disk	Every app logs to the same disk	Rotate logs and watch disk use
Shared secrets leak	Apps read one .env	Give each app its own variables
A port clash	Two apps want 3000	Map each to a different loopback port
A certificate expires	The renewal is not working	Use a proxy that renews automatically, and check it

Nobody should treat this table as exhaustive. The point is that most failures come from sharing one resource, so isolate the resource.

How should deploys work?

Each app gets its own pipeline, and a deploy of one should not restart the others. On Aria, a push redeploys only the services the commit touched, and rolling back returns to the last good version. Whatever you use, never deploy two builds at once on a small server.

How do you back up several apps?

One backup per app, not one for the server. A server backup restores everything or nothing; a per-app backup lets you restore the app that broke. On Aria, nightly backups cover each app’s Postgres databases, Supabase and volumes. They are encrypted and stored off the server, and kept 30 days by default (how backups work). Redis is a cache and is not restored.

When should you split onto two servers?

Add a second server when any of these is true:

• Builds delay deploys, because they run one at a time.
• Spare memory at your busiest time falls below about a fifth.
• One app has a different risk, such as customer data that must be separate.
• You need an app in another region.
• You are near the limit of apps your platform allows. On Aria that is five by default.

How does this work on Aria?

One server, several apps, no per-app charge. Each app has its own aria.yaml, and Aria checks that the new app fits before it launches, using the same method as the table above. Prices start at £9 a month ex VAT, and you pay per server, not per app (billing). A server runs up to five apps by default, and one aria.yaml holds up to 12 services and 6 databases (see all limits). A dedicated server is the step up. The quickstart takes you from sign-up to a running app, and the aria.yaml reference covers every field.

Websites count as apps too, so one server can run several sites, static sites and front ends included. You work through aria.yaml, Aria AI, the command line and your coding agent: Aria AI writes each app’s aria.yaml, and a coding agent outside Aria does the same over MCP. What the server covers is on managed VPS for developers.

FAQ

How many apps can a VPS run?

As many as fit in memory, disk and CPU, up to whatever your platform allows. Size for the running memory plus the largest build plus spare. On Aria, the default is five apps per server.

How much RAM do I need for five small apps?

It depends on the apps. In Aria’s estimate, the five small apps described above, with four Postgres databases, need 7,757 MB, so an 8 GB server fits with little spare. Measure your own apps before you rely on any figure.

Can several apps share one domain?

Yes. A reverse proxy can route by hostname or by path. Different subdomains are simpler to run and to certify.

Is it safe to run several apps on one server?

It is as safe as the weakest app on it. A compromise or a leak in one app can affect the others, because they share a machine. Containers, per-app credentials and memory limits reduce the risk. They do not remove it.

Do I need Docker?

No, but it makes isolation and limits much easier. You can run apps as systemd services under separate users instead. On Aria, you do not need to write Docker setup, and Aria AI (or your coding agent) writes aria.yaml.

Run your side projects on one flat-price server. See pricing, read about flat pricing, or get started.