Self-Hosting Your Business Stack: Server Sizes and Real Costs

A single $48-a-month VPS can run a complete business software stack: support inbox, CRM, scheduling, analytics, email marketing and surveys. The catch is that each of those tools has its own idea of how much memory it needs, and the documented minimums add up faster than most guides admit. This post adds them up using the requirements each project publishes, works through two realistic server sizes for a small company, and prices the whole thing against the SaaS bill it replaces.

The six tools are Chatwoot for customer support, Twenty for CRM, Cal.com for scheduling, Plausible Community Edition for web analytics, Listmonk for newsletters and campaigns, and Formbricks for surveys. All six are open source, all six deploy with Docker, and all six keep their data in Postgres (Plausible adds ClickHouse). Together they replace Intercom or Zendesk, HubSpot, Calendly, Google Analytics, Mailchimp and Typeform. If you want the license-cost comparison first, we covered it in the real cost of replacing SaaS with an open source stack. This post answers the next question: what hardware do you actually rent?

What each tool asks of a server

Vendor marketing pages rarely publish honest minimums, so these numbers come from the projects' own documentation. Where two official sources disagree, both are shown.

Chatwoot is the heavyweight. Its system requirements page recommends 4 CPU cores and 4 GB of RAM as a minimum, sized for up to 10,000 conversations a day, and 8 cores with 8 GB for 20,000 conversations a day. It also tells you to add at least 1 GB of swap so upgrades do not run the machine out of memory. Chatwoot's own deployment page is more conservative: 4+ cores, 8 GB of RAM minimum with 16 GB recommended, and 60 GB of SSD. Plan around 4 to 8 GB for Chatwoot alone, depending on how busy your support inbox is.

Twenty is modest but not tiny. The Twenty docs state a 2 GB RAM minimum. Its Docker Compose file runs four services: the app server, a background worker, Postgres and Redis. Budget 2 GB and it behaves.

Cal.com is light at runtime, heavy at build time. The installation docs describe "pretty minimal hardware requirements" and note that the intensive part is building the software; once running, it is relatively lightweight. It needs Node.js 18, PostgreSQL and a few cron jobs for reminders. The build step is what kills small servers, not steady-state traffic.

Plausible CE adds a second database. The Community Edition runs the app plus Postgres plus ClickHouse, the columnar store that holds event data. Plausible does not publish a RAM minimum on its self-hosting page, but ClickHouse is not free in memory terms; budgeting 1.5 GB for the pair is realistic at small-traffic volumes. The same page carries an unusually honest warning: self-hosting is a real commitment, and you own upgrades, capacity, uptime, backups, security and bot filtering. We compared the privacy and cost trade-offs against the default in Plausible vs Google Analytics.

Listmonk is the lightest of the six. It is a single Go binary plus Postgres 12 or higher, per its installation docs. A few hundred MB of RAM is plenty. The thing it actually needs from outside is an SMTP relay to send mail. At newsletter scale it is also where the SaaS savings get dramatic; see Listmonk vs Mailchimp at 25,000 subscribers.

Formbricks is more services than you expect. The current Docker Compose baseline, per the Formbricks docs, is six pieces: the web app, Postgres, Valkey (a Redis fork), Formbricks Hub, Cube for analytics, and a SpiceDB instance for authorization. The docs publish no RAM figure, so budget conservatively, around 1.5 GB, and verify with docker stats after a week.

The honest arithmetic

Add the documented minimums and realistic estimates for a small company at moderate volume:

• Chatwoot: 4 GB (documented minimum, up to 10,000 conversations a day)
• Twenty: 2 GB (documented minimum)
• Cal.com: about 1 GB at runtime
• Plausible plus ClickHouse: about 1.5 GB
• Formbricks: about 1.5 GB
• Listmonk: about 0.3 GB
• Linux, Docker, and a reverse proxy: about 1 GB
• Swap: 1 to 2 GB on disk, not RAM

That totals roughly 11 to 12 GB of working memory. This is the number most "run your whole stack on a $6 VPS" tutorials quietly ignore. An 8 GB server fits only if you trim: run Chatwoot lean, accept swap pressure, or drop a tool. A 16 GB server fits everything with headroom for build steps and traffic spikes.

Worked example: two server sizes for a 20-person company

Take a 20-person B2B services firm. Around 3,000 support conversations a month, five salespeople living in the CRM, 20,000 newsletter subscribers, modest website traffic, a few surveys a quarter.

Option A, the floor: a DigitalOcean Basic droplet with 8 GB of RAM, 4 vCPUs and 160 GB of SSD costs $48 a month. Everything runs, but you are operating near the ceiling. Cal.com's yarn build, a Twenty migration and a Chatwoot upgrade landing on the same afternoon can push you into swap. Fine if someone watches the graphs.

Option B, comfortable: the 16 GB / 8 vCPU / 320 GB Basic droplet at $96 a month. Every tool runs at its documented minimum with room left over. Builds and upgrades stop being events you schedule around.

For context, the SaaS bill this replaces: a realistic Intercom setup for ten agents runs $400 to $600 a month once seats and usage add up, and Zendesk lands around $550 a month at $55 per agent on the Suite Team plan billed annually. That is one tool, for half your team. The entire self-hosted stack on the comfortable server costs less than a fifth of the helpdesk alone. We broke down the individual comparisons in Chatwoot vs Intercom for a 20-seat support team and Twenty CRM vs HubSpot for a 20-person sales team.

The full monthly cost breakdown

The droplet is not the whole bill. Here is the honest all-in version, using Option B:

• Server: $96 a month (16 GB / 8 vCPU Basic droplet)
• Backups: $19.20 a month. DigitalOcean charges 20% of droplet cost for weekly backups, 30% for daily
• Domain: about $1.50 a month ($15 to $20 a year), one domain with subdomains per tool
• Transactional and bulk email: a few dollars a month through an SMTP relay such as Amazon SES; Listmonk and Chatwoot both need one
• Monitoring: $0. Uptime Kuma self-hosts on the same box, or use a hosted free tier

Total: about $118 a month, roughly $1,400 a year. Option A lands near $59 a month, about $710 a year. Either way, the infrastructure is cheap. What is not free is the operations work: updates, backup verification, security patches, and the occasional broken upgrade. That is the trade, and it is a real one. Plausible's own documentation warns that when a security fix ships, your instance is only protected once you apply it yourself.

A sane order to stand it up

If you do this yourself, this sequence avoids the common failures:

1. Provision the server. Ubuntu 24.04 LTS on the 16 GB plan, in the region closest to your team or required by your data-residency obligations.
2. Harden it first. SSH keys only, disable password login, enable ufw with ports 22, 80 and 443 open, install fail2ban. Twenty minutes here prevents most incidents.
3. Install Docker and Docker Compose. Every tool in this stack ships a Compose file; you will run six of them.
4. Put a reverse proxy in front. Caddy or Traefik with automatic HTTPS, one subdomain per tool: chat., crm., cal., stats., mail., surveys.
5. Deploy lightest first. Listmonk, then Plausible, then Cal.com, then Twenty, then Chatwoot, then Formbricks. Starting light validates your proxy, DNS and email relay before the heavy tools depend on them.
6. Set up backups before real data arrives. Provider snapshots plus nightly pg_dump of each database to object storage off the box. Test one restore.
7. Add swap. At least 1 GB. Chatwoot's documentation calls this out specifically because upgrades can exhaust RAM mid-deploy.

Common mistakes when sizing a self-hosted stack

Sizing to the cheapest droplet. A $6 VPS runs Listmonk or Plausible alone. It does not run six applications, four Postgres instances, two Redis-compatible stores and ClickHouse. The failure mode is not a clean error; it is the OOM killer silently murdering your support inbox at 2 a.m.

Building on the production box without swap or headroom. Cal.com's build and Twenty's migrations are the memory peaks, not steady traffic. Build on the box with swap configured, or build elsewhere and deploy images.

Publishing database and cache ports. Formbricks' documentation describes exactly this incident class: older Compose templates exposed Valkey on 0.0.0.0:6379 with no password, which let anyone who could reach the port read live sessions and take over accounts. Keep Postgres and Redis on the internal Docker network. Nothing outside the proxy should be reachable.

Treating docker compose up as the finish line. Installation is hour one. Backups you have never restored, upgrades you have never scheduled, and disk usage you have never graphed are how self-hosting stories turn into cautionary tales.

Upgrading everything at once. Six tools means six release cadences. Plausible CE ships twice a year; others ship weekly. Snapshot first, upgrade one tool, verify, move on.

When one server is the wrong answer

Honesty matters here, because sometimes it is:

• Your support volume exceeds roughly 10,000 conversations a day. Chatwoot's own docs tell you to scale horizontally past that point, which means multiple app servers, external Postgres and Redis, and a load balancer. That is infrastructure engineering, not a weekend project.
• You are a bank, insurer, or otherwise regulated. A single VPS with nightly dumps does not meet high-availability, audit and governance expectations. This is where private, properly governed deployments earn their cost.
• Nobody owns the maintenance. If the honest answer to "who applies security updates this month" is no one, pay for SaaS or for someone to run the stack. An unmaintained self-hosted system is worse than an expensive SaaS subscription.
• A specific SaaS feature is load-bearing. Plausible CE, for example, does not include funnels, user journeys, SSO or ecommerce revenue goals; those stay in the paid cloud version. Check feature parity per tool before you migrate, not after.

Frequently asked questions

Can six applications really share one VPS? Yes, at small-company volumes, because none of them is constantly busy. Support, CRM, scheduling and surveys are bursty workloads that idle most of the day. The constraint is memory, not CPU, which is why the sizing math above focuses on RAM.

How much RAM does Chatwoot need? Chatwoot's requirements page says 4 GB with 4 cores handles up to 10,000 conversations a day, while its product deployment page recommends 8 GB minimum for production. Treat 4 GB as the floor for a quiet inbox and 8 GB as the safe target.

Is a $6 server enough to start with? For one light tool, yes: Listmonk or a low-traffic Plausible instance will run on 1 GB. For the full stack, no. Start at 8 GB if budget is hard-capped, 16 GB if you want to stop thinking about it.

Do I need Kubernetes for this? No. Docker Compose on a single VM is the documented path for all six tools and is far easier to back up, monitor and reason about. Kubernetes enters the picture when you scale Chatwoot horizontally or need high availability across machines.

How do backups work on one server? Two layers: the provider's snapshot or backup service (DigitalOcean charges 20% of droplet cost for weekly) for whole-machine recovery, plus nightly pg_dump of each database copied to storage outside the provider. The second layer is what saves you from provider-level and account-level failures.

Does self-hosting help with GDPR and data residency? It gives you full control over where data physically sits, because you pick the datacenter region and no third party processes your customer data. That removes a whole class of transfer-mechanism questions. It does not remove your obligations as a data controller: you still need policies, access controls and breach procedures. Plausible's self-hosting page makes the same point about its own cloud versus CE.

Where to go from here

If the arithmetic in this post makes sense but the operations section reads like a second job, that is exactly the gap our managed open-source stack service fills: we deploy Twenty, Chatwoot, Cal.com, Plausible, Listmonk and Formbricks on infrastructure sized for your volume, then run the updates, backups and monitoring so your team just uses the tools. You keep the cost structure of self-hosting and the data control that comes with it, without carrying the pager yourself.

Related reading

• How to Self-Host Twenty CRM: Setup, Backups, Updates and Costs