Run Multiple Apps on One Server

Save money by running 5-10 apps on a single server. Here's how to optimize resource usage and get the most out of every credit.

One of the biggest advantages of Dublyo's Docker-based architecture is that each app runs in its own isolated container. This means you can safely run multiple applications on the same server without them interfering with each other, while sharing the underlying compute resources efficiently.

Tip: Most users can run 3-5 apps on a single Starter server without any issues. That's one monthly bill instead of five.

Server Capacity

How many apps you can run depends on your server size and the type of apps you're deploying. Here's a general guide to help you plan:

Server Size	RAM	Recommended Apps	Best For
Starter	4 GB	3-5 light apps	Personal projects, small stacks
Standard	8 GB	5-8 apps	Production workloads, mixed stacks
Performance	16 GB	8-15 apps	Full production environments

App Categories by Resource Usage

Not all apps are created equal. Understanding what each app needs helps you plan capacity:

Category	Typical RAM	Examples
Light	50-200 MB	Static sites, small APIs, link shorteners, status pages
Medium	200-500 MB	CMS platforms, automation tools (n8n), analytics (Umami, Plausible)
Heavy	500 MB - 2 GB+	Databases (PostgreSQL, MySQL), AI tools, large web applications

Tip: Check your actual resource usage via the Portainer dashboard on your server. Real-world usage often varies from these estimates depending on traffic and configuration.

Optimization Tips

Follow these best practices to maximize the number of apps you can run on a single server without sacrificing performance:

Choose Lightweight Templates

Prefer apps that use Alpine-based Docker images. These are significantly smaller and use less memory than their full-size counterparts. Many Dublyo templates are already optimized this way.

Share Databases When Possible

Instead of deploying a separate database for every app, deploy one PostgreSQL or MySQL instance and create multiple databases within it. This saves hundreds of megabytes of RAM per app.

Monitor Resource Usage via Portainer

Regularly check the Portainer dashboard to see how much CPU, memory, and disk each container is using. This helps you identify apps that are consuming more than expected and take action before issues arise.

Stop Unused Apps to Free Resources

If you have apps that you only use occasionally, stop their containers when not in use. This immediately frees up RAM and CPU for your other running applications. You can restart them at any time from the Portainer dashboard.

Tip: Sharing a single PostgreSQL instance across multiple apps is the single biggest optimization you can make. One PostgreSQL container uses ~200 MB — running five separate ones would cost 1 GB.

Example Setup

Here's a real-world example of running multiple apps on a single Starter server (4 GB RAM, 2 vCPU). This is a common setup for solo developers and small teams:

App	Purpose	RAM Usage
PostgreSQL	Shared database for all apps	~250 MB
n8n	Workflow automation	~350 MB
Umami	Privacy-friendly analytics	~200 MB
Static Website	Portfolio or landing page	~50 MB
System Overhead	Docker, Traefik, Portainer	~500 MB

Total usage: ~1.35 GB out of 4 GB available. That leaves over 2.5 GB of headroom for additional apps or traffic spikes. You could comfortably add 2-3 more lightweight apps to this setup.

Note: In this setup, n8n and Umami both connect to the shared PostgreSQL instance instead of running their own databases. This saves roughly 400 MB of RAM compared to running separate database containers.

When to Scale Up

Running multiple apps on one server works great until you hit resource limits. Watch for these signs that it's time to upgrade to a larger server or split your workload across multiple servers:

CPU Consistently Above 80%

If your server's CPU usage stays above 80% for extended periods, your apps will start competing for processing time and response times will increase.

RAM Usage Above 90%

When memory gets critically low, the system may start killing containers to free up RAM. This leads to unexpected downtime and potential data loss.

Slow Response Times

If your apps are taking noticeably longer to respond, resource contention is likely the cause. Check Portainer to see which containers are using the most resources.

Deployment Failures Due to Resources

If new deployments fail because there isn't enough memory or disk space to pull and run container images, your server has reached its capacity.

Tip: You can upgrade your server size from the Dublyo dashboard without losing data. Alternatively, create a second server and distribute your apps across both for better isolation and redundancy.

Need Help?

Can't find what you're looking for? Check the full documentation or reach out.

Full Documentation Contact Support