---
title: How to run several side projects on one server
description: >-
  Run several side projects and databases on one server instead of paying per
  service. The general answer, what breaks when you consolidate, and how to size
  it.
date: '2026-09-02'
lastUpdated: '2026-09-02'
keywords:
  - run multiple side projects one server
  - self-host multiple projects
  - avoid per-project billing
  - one VPS multiple apps and databases
  - Coolify multiple projects
  - per-service pricing alternative
type: article
author: Ross Hill
locale: en_CA
site_name: MapleDeploy
slogan: Powerful hosting on Canadian soil
organization_url: 'https://mapledeploy.ca/'
logo: 'https://mapledeploy.ca//api/logo/lockup'
creator: MapleDeploy
publisher: MapleDeploy
founding_date: '2026-01-13'
email: hello@mapledeploy.ca
geo_region: CA-ON
geo_placename: Toronto
address_country: CA
area_served: Canada
application_category: DeveloperApplication
app_url: 'https://app.mapledeploy.ca'
llms_txt: 'https://mapledeploy.ca/llms.txt'
offers: >-
  Starter $45/mo, Pro $95/mo, Ultra $195/mo, Ultra 32 $395/mo, Ultra 64 $695/mo
  CAD
in_language: en-CA
canonical_url: 'https://mapledeploy.ca/blog/run-side-projects-one-server'
---

Put them all on one server behind a deployment platform, and run one Postgres instance with a separate database per project instead of one database service per project. That's the whole answer. The rest of this post is the arithmetic that makes it worth doing, and the constraints that make it worth doing carefully.

The problem you're solving is real. On per-service platforms, a web app plus a background worker plus a database is three separate line items. Five side projects built the same way is fifteen. Most of those projects get a handful of visitors a month. Paying full per-service rates on all of them is how a stack of hobby projects ends up costing more than rent.

## Why per-project billing adds up

A few concrete examples, because "it adds up" is easy to say and hard to picture.

On [Render](/compare/render), a Starter web service is $7 USD/month, a basic PostgreSQL database is $6 USD/month, and a background worker is another $7. One small project with a worker is already $20 USD/month before it has any traffic. Five projects built the same way, run separately, is $100 USD/month.

Heroku deserves a caveat here, because it has one tier that genuinely is not per-app. The Eco plan is $5 USD/month for [1000 dyno hours shared across all your Eco dynos](https://devcenter.heroku.com/articles/eco-dyno-hours), and Eco dynos sleep after 30 minutes of inactivity without consuming hours. If your side projects really do get no traffic, that is the cheapest option on this page. Once you want anything always on, you are into a Basic dyno at $7 USD/month plus an Essential-0 Postgres add-on at $5 USD/month, billed per app. [Our Heroku comparison](/compare/heroku) has the fuller breakdown.

On [Railway](/compare/railway), pricing is usage-based rather than per-app. Hobby is $5 USD/month including $5 of usage credit and Pro is $20 USD/month including $20, so usage is not additive until you spend the credit. Past it, the rates are roughly $20 USD per vCPU per month and $10 USD per GB of RAM per month. A database, a worker, and a web process each draw from that meter, so the bill is proportional to however many things you're running, not to how many servers they sit on.

Supabase bills per project, not per server: the Pro plan is $25 USD/month and includes compute credits for one project, and [each additional project starts at roughly $10 USD/month](https://supabase.com/pricing). It is the same per-unit shape as the others, just counted in projects instead of services.

None of these platforms are doing anything wrong. Per-service billing is honest and it scales down to zero for projects nobody visits. It's also expensive per project once you have more than one or two, because you're paying for isolation you don't need at hobby scale.

## The general answer: one server, one deployment platform in front of it

Rent one VPS. Install a deployment platform on it, something like [Coolify](/open-source-stack), Dokploy, or CapRover. Deploy each project as its own app or Docker Compose stack. Run one Postgres instance (or MySQL, or both) as a long-running service, and give each project its own database and user inside that instance instead of its own database container.

That's it. It's true whether you self-host that stack on any $10 VPS from any provider, or pay someone to run the server for you. The economics work the same way either way: you're paying for one machine's worth of resources instead of one bill per service.

The part that actually needs care is what happens after you consolidate.

## What breaks when you consolidate

**RAM is the binding constraint, not project count.** A dozen static sites and cron jobs cost almost nothing to run together. A dozen always-on Node or Python apps each holding their own connection pool and in-memory cache is a different story. Count what each project actually keeps resident in memory, not how many projects you have.

**One server is one failure domain.** If the VM goes down, every project on it goes down at the same time. That's a real tradeoff against per-service platforms, where one provider's outage in one region doesn't necessarily take out every service you run there. For side projects, most people accept this trade happily. For anything a client or a paying user depends on, it's worth naming explicitly rather than discovering it during an incident.

**Noisy neighbours become your own projects.** This is worth being precise about, because it's a different claim than the one hosting providers usually make. "No noisy neighbours" on a managed platform usually means no *other customer's* workload competes with yours. On your own consolidated server, your own projects are now each other's noisy neighbours. A runaway build, a memory leak, or an unbounded log file in project A can starve project B if nothing stops it. Docker resource limits (`mem_limit`, `cpus` in Compose, or your platform's equivalent) exist for exactly this and are worth setting once you have more than a couple of things running.

**Backups matter more when everything is in one place.** Losing one server used to mean losing one project's database. Now it means losing all of them at once. Database-level backups (a scheduled `pg_dump` to S3-compatible storage, or your platform's built-in backup tool) and a way to rebuild the host itself are both worth having before you need them, not after.

## Sizing it: what a small app plus a database actually costs

A useful way to size the box is to separate the fixed overhead from the per-project cost.

The fixed cost is the operating system, Docker, and the deployment platform itself, running before you deploy anything. On a freshly provisioned MapleDeploy server, that baseline typically runs 0.7 to 0.8 GB of RAM. Whatever platform you use, expect something in that range: it's the price of admission before your own apps get a share.

The per-project cost is smaller than people expect for low-traffic hobby projects. A small Node, Python, or Go API sitting mostly idle, with no meaningful traffic, usually holds well under a few hundred MB resident. A lightly used Postgres database serving one small project is typically similar, more if you raise `shared_buffers` or run heavier queries. So a "web app plus Postgres" pair for a low-traffic side project often fits comfortably in a few hundred MB total, and five or six of those together, plus the platform overhead, is a workload a 4 GB server can carry without drama. Traffic, background jobs, and anything holding a large cache in memory push those numbers up quickly, so treat this as a starting estimate to verify against your own project's actual memory usage under load, not a promise.

One instance, many databases works fine for this. You don't need a separate Postgres container per project. Create one Postgres service, then `CREATE DATABASE project_a;`, `CREATE DATABASE project_b;`, each with its own user and credentials. It's the standard way to run several small apps against one database engine, and it's a lot lighter than running a database container per project.

## Mapping that to a plan

Whatever platform runs the deployment side, you eventually need a server sized for the total, not the average. MapleDeploy's plans, all flat CAD per month with no per-project or per-service billing:

| Plan | RAM | vCPUs | Storage | Price (CAD) |
| --- | --- | --- | --- | --- |
| Starter | 4 GB | 2 | 35 GB | $45/mo |
| Pro | 8 GB | 4 | 70 GB | $95/mo |
| Ultra | 16 GB | 6 | 125 GB | $195/mo |
| Ultra 32 | 32 GB | 8 | 250 GB | $395/mo |
| Ultra 64 | 64 GB | 8 | 500 GB | $695/mo |

Starter and Pro include a 30-day free trial, so you can deploy your actual projects, watch real memory and CPU usage in the dashboard, and confirm the plan fits before paying for it. See [full pricing](/#pricing) for all tiers.

## Do I need a separate database service per project?

No. One Postgres or MySQL instance with a database and user per project is the normal way to do this, and it's considerably lighter on RAM than a database container per project. Keep credentials separate per project so a bug or a leaked key in one app doesn't expose another project's data.

## Signs you're pushing the server too hard

- Deploys start failing partway through a build, not because of your code but because the server ran out of memory mid-build.
- One project's traffic spike visibly slows down an unrelated project on the same box.
- Disk usage climbs steadily from accumulated Docker images, build cache, and old containers, not from your data growing.
- You're checking whether the server is still up more often than you're shipping features.

Any of those is a signal to set resource limits, move a project off, or size up, not to panic. It's normal maintenance for a shared box, the same way it would be for a shared database instance.

## If you'd rather not run the box yourself

The self-hosted version of this is genuinely a good deal for a lot of people. It's also ongoing work: OS patches, platform updates, firewall rules, and backups, indefinitely.

MapleDeploy runs managed Coolify on a dedicated VM in Toronto, and it's built around exactly this use case: one server, many apps and databases, one flat price. Each customer gets their own VM, not a shared container, so the "no noisy neighbours" part actually holds for cross-customer isolation. What you deploy on that VM, and how you divide its resources among your own projects, is still up to you.

If you're starting from scratch, our [guide to deploying your first app](/docs/deploy-your-first-app) walks through connecting a repo and getting it live, and the same server takes your second and third project the same way.

{% cta-section title="One server, as many projects as it fits" %}
30-day free trial on Starter and Pro. Flat CAD pricing, no per-project fees.
{% /cta-section %}