Running ~28 Apps on One Self-Hosted Server with Coolify: The wizzy.help Ops Dashboard

Why We Self-Host Multiple Apps Instead of Paying Per App

Running an engineering studio involves maintaining an expanding fleet of digital assets: production client projects, staging environments, internal automation bots, database instances, and lean proof-of-concept MVPs. When deploying across mainstream Platform-as-a-Service (PaaS) providers such as Heroku, Render, or Vercel, operational overhead scales linearly with resource count rather than actual compute consumption.

The PaaS Subscription Bottleneck

Managed platforms simplify the initial git push, but their pricing tiers penalize architectures composed of multiple lightweight services:

• Per-seat and per-project billing: Staging environments and low-traffic internal utilities incur minimum monthly baselines ($7 to $25+ per container or database), regardless of actual memory usage.
• Subscription sprawl: Juggling dozens of disparate cloud dashboards, isolated environment secrets, and separate billing invoices introduces operational friction.
• Artificial resource boundaries: A lightweight webhook forwarder or background cron service consumes minimal CPU, yet commercial PaaS offerings charge for dedicated allocations that sit underutilized.

When structuring client delivery—such as launching a production website starting from $500 or a web app MVP from $2,500—imposing hundreds of dollars in recurring third-party PaaS subscriptions for idle containers is commercially impractical.

Decoupling Compute from App Counts with Coolify

Self-hosting with Coolify fundamentally shifts infrastructure economics. Instead of paying per application, costs decouple from deployment volume and attach directly to the underlying hardware capacity:

This article provides a technical retrospective of how we run approximately 28 production applications, microservices, and databases on a single 62 GB RAM server using Coolify, managed by our internal dashboard, wizzy.help.

The Production Setup: ~28 Apps on a 62 GB RAM Server with Coolify

Our core production environment runs on a single dedicated server provisioned with 62 GB of RAM, hosting roughly 28 applications simultaneously. Instead of maintaining fragmented virtual machines for individual projects, Coolify operates as the orchestrator directly on top of the host's Docker Engine.

Dynamic Routing and Traefik Architecture

Coolify handles container discovery and ingress routing automatically through Traefik, as detailed in Coolify's architecture concepts. Whenever a new application, service, or branch deployment starts, Coolify assigns Docker network labels to the container.

Traefik listens to the Docker daemon socket, detects these labels, automatically provisions Let's Encrypt SSL/TLS certificates, and maps incoming requests from external domains to the respective private container ports. This eliminates the need to write custom Nginx configuration blocks or trigger manual web server reloads when deploying new software.

Baseline Control Plane Overhead

Coolify’s management engine maintains a low operational footprint. According to self-hosting benchmarks, such as LocaltoNet's analysis, the idle footprint of Coolify's core engine sits at approximately 800 MB of RAM. Our day-to-day operations align with this baseline. Because the control plane demands minimal capacity, over 61 GB of memory remains fully accessible for production workloads, database buffering, and active processes.

Resource Allocation and Workload Isolation

The server runs a variety of client applications and studio portfolio projects, including Postlyy, our Telegram Channels directory, the Mothers Mini App, and The Payment Layer.

To prevent cross-app interference and resource contention, workloads are segregated across isolated Docker networks and bounded execution environments:

This containerized topology ensures that heavy database reads or background queue spikes in one project cannot interrupt traffic or exhaust memory on neighboring applications.

wizzy.help: A Unified Internal Dashboard for Resources and Databases

The Operational Challenge in Standard Coolify

Coolify isolates resources into separate projects, environments, and server views. While this model maintains clean logical boundaries, it creates operational friction when managing ~28 applications on a single physical host. In standard operations, checking system status requires opening individual project pages, drilling down into separate service cards, and inspecting individual containers one at a time.

During an operational incident, this layout slows down root-cause analysis. Standard Coolify lacks an aggregate view that simultaneously reports the real-time health of every web frontend, backend worker, standalone container, and database across the entire machine.

Architecture of wizzy.help

To solve aggregate visibility, we created wizzy.help, an internal operations dashboard running directly on the host (repository located at /home/user/coolify-ops). The system is built with zero third-party npm dependencies to keep runtime memory consumption negligible and eliminate supply-chain overhead:

• Native HTTP server (node:http): Serves the administration interface and internal API endpoints without third-party web frameworks.
• Native HTTP client (fetch): Queries the local Coolify API directly from the Node.js runtime.
• No external runtime packages: Ensures long-term maintenance stability and minimal attack surface.

Security is enforced at the network and application layers. The dashboard is password-protected and accessible only internally, with no public link published. All communication with the Coolify REST API occurs strictly server-side: the Coolify API token is loaded via host environment variables and never exposed to client browser environments. The browser UI communicates solely with sanitized internal endpoints that return operational metadata.

Visual Health Mapping and Status Aggregation

The dashboard consolidates infrastructure monitoring into folded project cards, summarizing every service's operational state without requiring manual navigation across multiple screens:

Each project card can be expanded to reveal granular resource details, including direct deploy triggers and database backup records, giving operations teams complete visibility over the 28-app cluster from a single view.

Real-Time Monitoring and Telegram Bot Automation

Operating dozens of standalone services on a single host requires notifications that surface downtime before users report it. Instead of forcing engineers to keep a browser tab open, wizzy.help bridges production events directly into communication channels through a dedicated Telegram ops bot.

Automated Polling and Incident Triggers

The internal daemon executes automated health checks every 120 seconds by default. It polls container states via the Coolify API and queries HTTP endpoints across the entire fleet. When an anomaly occurs, the bot dispatches an immediate incident alert.

Alerts fire on four specific failure states:

• Container outages and recoveries: Instant notifications when a container goes down or successfully recovers.
• HTTP health check failures: Non-200 status codes, timeouts, or DNS resolution issues.
• Deployment aborts: Failed builds, bad exit codes, or unapplied configuration updates.
• SSL certificate limits: Warnings when an automated certificate renewal stalls and nears its expiration boundary.

In addition to incident alerts, the bot delivers a daily morning summary reporting overall fleet health, backup execution status, and resource stability across all ~28 apps.

Operational Command Interface and Host Metrics

The Telegram bot also serves as an operational interface for direct management:

• /status — Returns the real-time operational state of every active application, database, and service.
• /deploy <name> — Triggers an immediate build and deployment cycle for the specified application.
• /id — Displays the current Telegram chat identifier to verify permissions against access control lists.

Alongside application checks, a lightweight host agent running on the server pushes CPU, RAM, and disk utilization metrics back to the dashboard. This allows the team to monitor memory headroom across the 62 GB server and catch runaway disk usage before it impacts running containers.

Don't want to run servers yourself? WEB3 Build Studio hosts and maintains what it builds — from $49/month for a website (/blog/what-a-website-costs).

Deployment Control and Detecting Unreleased Git Commits

When managing roughly 28 applications across separate codebases, tracking what is currently running versus what has been merged into main branches becomes a challenge. In a multi-repo studio, relying on manual memory inevitably causes drift: a developer merges a bug fix or feature branch, but the running container continues serving an older image because nobody triggered a build in the infrastructure UI.

Automated Commit Comparison

To close this gap, wizzy.help continuously inspects deployment states across the entire server. Built in Node.js using native fetch routines without external dependencies, the dashboard periodically queries the GitHub API to retrieve the latest commit SHA for each repository's tracked branch. It then evaluates that hash against the active commit SHA reported by the Coolify API.

If a repository contains merged commits that have not been deployed, wizzy.help highlights the service with an amber "update available" indicator. This gives the team instant visibility across all ~28 projects without needing to inspect individual GitHub pull requests or Coolify configuration views.

Selective Automation and Release Controls

Not every workload benefits from automatic deployments on push. We configure release behavior per application using dedicated toggles:

• Auto-Deploy Enabled: Non-critical background workers, staging services, and internal webhooks pull and rebuild as soon as code reaches the repository.
• Manual Single-Click Releases: Production-critical customer portals, payment-handling services, and database-linked applications remain on manual release controls to prevent unexpected disruptions during peak operational hours.

Triggering an update does not require navigating Coolify's nested project, environment, and resource trees. An engineer can trigger a release with a single click directly on the application card in wizzy.help, or remotely through our Telegram bot via the /deploy <name> command. Both methods dispatch requests to the Coolify API purely server-side, ensuring credentials never touch the browser.

This disciplined release workflow maintains reliable deployment hygiene across complex pipelines, including our automated crypto media platform, where content processing scripts and public-facing containers must remain strictly synchronized.

Database Protection: Coolify Automated Daily Backups

Running dozens of distinct applications on a single 62 GB RAM host concentrates operational risk in the persistence layer. A corruption event or configuration error in one application's data store must never cascade into another. To keep the blast radius contained, our stack isolates workloads across independent PostgreSQL containers rather than pooling projects into a shared, monolithic database instance. Each container requires dedicated, verifiable dumps.

Automated Execution and Decoupled Storage

Coolify handles native scheduled daily backups across every independent database running on the server. Retaining these dumps solely on the primary host filesystem, however, invalidates disaster recovery planning: if the primary storage volume corrupts or fails, both active databases and backup files disappear simultaneously. Coolify's backup automation is configured to decouple dump archives from local host storage, streaming database archives off-host to external S3-compatible storage targets upon completion.

Health Visibility Inside wizzy.help

Automated background jobs frequently fail silently—interrupted by timeouts, schema locks, or exhausted disk buffers. Finding an empty or failed dump during a disaster recovery restore is catastrophic. To ensure integrity, the wizzy.help internal dashboard pulls real-time backup metrics directly through the Coolify API for each database:

• Timestamp Verification: Tracks the exact time of the last completed run to verify the daily schedule executed.
• Archive Size Tracking: Displays precise archive sizes to immediately detect anomalous, truncated, or zero-byte dumps.
• Execution Flags: Displays explicit status indicators (🟢 or 🔴) based on task exit codes.

Treating backup verification as an active operational metric ensures that zero-byte dumps and job interruptions are flagged instantly, keeping database recovery reliable across all running projects.

Consolidated Domain Email: Self-Hosting Stalwart with JMAP

Managing separate paid SaaS email accounts for dozens of project domains creates unnecessary administrative friction and recurring seat costs. When running ~28 distinct web apps, portfolio projects, and internal tools on a single server, each domain requires operational addresses for automated alerts, transactional verifications, vendor accounts, and inbound inquiries. Paying per-user or per-domain subscription fees across every individual domain rapidly multiplies overhead for low-volume administrative communication.

Centralized Routing with Stalwart

To simplify domain communication, we run a self-hosted Stalwart mail server directly on the server instance. Stalwart is an open-source, all-in-one mail server providing modern mail transfer agent (MTA) capabilities alongside full IMAP and JMAP (JSON Meta Application Protocol) support.

Stalwart is configured with universal catch-all routing across all studio-managed domains into a single operational store. Messages directed to admin@, support@, or specific service handles across any registered project domain are captured and routed into one consolidated pipeline, removing the need to manage dozens of separate external inboxes.

Custom Webmail via JMAP at /mail

Our internal operations tool, wizzy.help, connects directly to Stalwart over JMAP to power a dedicated email client accessible at /mail. Using JMAP over standard HTTP eliminates the parsing complexities and performance lag typical of legacy IMAP implementations.

The /mail view provides core inbox workflows:

• Domain Sorting: Inbound mail is grouped and filtered by the specific target domain it was sent to, keeping project contexts distinct.
• Message Management: Operators can search message bodies, inspect and download file attachments, and route items directly to archive, spam, or trash.
• Zero External Dependencies: Built with native Node.js HTTP and fetch capabilities, mail data stays strictly on the server without third-party email client libraries.

Sandboxed Rendering and Real-Time Alerts

Displaying raw HTML emails inside an operations dashboard introduces security and privacy concerns, particularly from tracking pixels and injected scripts. The /mail view renders all incoming email HTML inside a strictly sandboxed iframe. Remote assets and external images are blocked by default, requiring manual operator confirmation before any external URL is fetched.

To maintain quick response times without keeping browser tabs running, Stalwart triggers an immediate notification ping through our internal Telegram bot whenever a message hits any monitored domain, detailing the recipient domain, sender, and subject line.

Single Server Risks and Mitigation Strategies

Consolidating ~28 applications, supporting databases, and background daemons onto one physical host introduces an absolute single point of failure (SPOF). A bare-metal hardware failure, host kernel panic, upstream network outage, or corrupted system package update impacts every hosted application, client service, and internal tool simultaneously. Operating this infrastructure reliably requires direct operational controls rather than optimistic assumptions.

Resource Contention and Noisy Neighbors

Across a 62 GB RAM server, memory is the primary resource ceiling. Running ~28 applications alongside multiple PostgreSQL instances, Redis caches, Docker daemons, and Node.js runtimes means unconstrained workloads will eventually compete for physical memory. If an unconstrained application experiences a sudden memory leak, the Linux Out Of Memory (OOM) killer will terminate containers across the host to safeguard the operating system kernel—often terminating critical databases rather than the offending container.

To eliminate noisy neighbor issues, every service container receives strict Docker memory reservations and hard limits:

services:
  application:
    image: app-service:latest
    deploy:
      resources:
        limits:
          cpus: '1.50'
          memory: 1024M
        reservations:
          memory: 256M

Setting strict ceiling allocations ensures that any rogue process that exceeds its limit triggers an isolated container restart within its own control group (cgroup) instead of depleting host-level memory.

Preventing OOM Terminations with Health Thresholds

Silent container drops disrupt services before standard HTTP uptime pings detect an outage. Internal monitoring agents push real-time CPU, RAM, and disk saturation figures upstream. Polling thresholds trigger alerts via automated channels when aggregate server RAM usage exceeds 80%, or when any individual container approaches 85% of its hard limit. This warning window gives the engineering team time to adjust memory allocations or restart memory-leaking processes before automated kernel OOM terminations take place.

Cold Restore Readiness

Because physical hardware can fail permanently, disaster recovery cannot rely on host-resident data. Cold restore readiness separates compute runtime from state:

• Offsite Database Backups: Automated daily database dumps are transmitted to independent, external offsite object storage immediately upon completion.
• Docker Compose Definitions: Application definitions, volumes, and network maps are versioned outside the host environment.
• Environment Isolation: Decrypted environment configurations (.env) are kept synchronized in secure external secret storage.

If the host server experiences catastrophic hardware loss, full disaster recovery does not involve attempting hardware repair. It entails provisioning a clean host, installing the container runtime, pulling application compose files, injecting external environment secrets, and restoring database snapshots from offsite storage to resume service.

Client Operations: Managed Hosting and Care Packages

WEB3 Build Studio leverages this centralized Coolify and wizzy.help infrastructure to run client deliverables without passing infrastructure management overhead to product teams. Instead of requiring clients to provision isolated cloud providers, configure reverse proxies, and maintain container runtimes independently, client applications run directly on our managed server environment.

Build Pricing and Ongoing Care Tiers

Every engagement begins with a fixed-price build scope that includes product design, technical development, deployment, and 30 days of post-launch bug fixing. Fixed starting prices include:

• Telegram Bot: from $300
• Website: from $500
• Telegram Mini App: from $700
• Solana Token with Launch Page: from $700
• Web App or SaaS MVP: from $2,500
• Solana dApp: from $4,000

After launch, clients can transition directly into monthly hosting and care packages hosted on our servers, with pricing structured on our pricing page:

Included Operations and Scope Boundaries

Monthly care plans handle standard production upkeep:

• Server hosting and dedicated compute resources
• SSL certificate lifecycle management and automated renewal
• Scheduled daily database backups
• 120-second automated health polling and uptime alerting
• Routine security patches and dependency updates
• Normal technical maintenance to keep services online

Clear boundaries separate operational care from active product development. Standard maintenance covers stability, backups, and security. New application features, major architectural refactors, and complex third-party API integrations fall outside monthly retainers and are scoped and quoted separately as standalone milestones.

Decision Framework: Should Your Team Self-Host with Coolify?

Managed platforms like Vercel, AWS ECS, or Heroku make sense when managing a single project with basic infrastructure requirements. However, PaaS pricing models compound quickly once projects require persistent worker processes, staging tiers, and dedicated databases.

The Tipping Point

Self-hosting becomes technically and commercially viable once an organization maintains five or more active applications, background workers, or staging environments. At that scale, paying individual managed database fees and per-seat developer surcharges across multiple third-party providers exceeds the operational overhead of running a single dedicated high-spec server.

Operational Readiness Checklist

Self-hosting production workloads requires baseline operational discipline. Before migrating away from managed platforms, verify your team has the following covered:

• Linux administration fundamentals: Practical comfort handling SSH, system process monitoring, Docker storage reclamation, and OS-level security updates.
• DNS and routing management: Ability to configure wildcard records, CNAME routing, reverse proxies, and manage TTL propagation cleanly.
• Automated offsite backup routines: Verified, scheduled database dumps transmitted off the primary instance to prevent data loss during catastrophic hardware failures.
• Active health alerting: Immediate notifications for high resource consumption, failed deployments, and service outages delivered to your team's active chat channels.

The Technical Verdict

Coolify provides the deployment primitives: Git-based builds, automatic proxy configurations, and container isolation. For production reliability across dozens of services, pairing Coolify with custom visibility tooling—such as the lightweight wizzy.help dashboard and Telegram bot automation—bridges the gap between bare-metal hosting and enterprise-grade operations.

Get your website, bot, Mini App or web app built and kept running on our server — hosting, daily backups, monitoring with alerts and updates from $49/month: https://web3buildstudio.com.

Frequently Asked Questions

How many applications can you run on one Coolify instance? Capacity depends on runtime memory and traffic demands. In our setup, we run ~28 active applications, databases, and internal services on a single 62 GB RAM server managed by Coolify.

What happens if a self-hosted container crashes? Coolify applies container restart policies to recover failed instances automatically, while automated health checks alert engineers via Telegram if an endpoint stays down across polling cycles.

Is Coolify suitable for client production workloads? Yes, provided teams implement daily offsite database backups, active uptime monitoring, and routine host maintenance.

Frequently asked questions

Can Coolify really run ~28 production apps on one server?

Yes. Coolify operates as a self-hosted control plane running on top of Docker. It manages deployments, SSL certificates, and reverse proxy routing without heavy platform overhead. In practice, many apps—such as internal dashboards, staging environments, webhooks, Telegram bots, and microservices—spend most of their time idle. By sharing a host and applying strict Docker memory and CPU limits, 28 lightweight services can comfortably coexist on a single dedicated instance or virtual private server. The primary requirement is engineering each application cleanly: avoiding memory leaks, keeping container base images minimal, and offloading heavy static asset delivery to object storage or a CDN when needed.

How much RAM do you need for Coolify plus many apps?

Coolify itself requires relatively little overhead, typically consuming 1 to 2 GB of RAM for its management engine and reverse proxy. The total memory requirement depends on the runtime footprint of the individual applications and their databases. For example, running roughly 28 lightweight services—such as Node.js processes, Go binaries, Redis caches, and PostgreSQL instances—typically requires between 16 GB and 64 GB of RAM. Setting explicit memory reservations and swap space prevents out-of-memory (OOM) errors from killing critical processes. Sharing a single PostgreSQL instance across several smaller apps rather than running 28 separate database daemons significantly reduces baseline memory usage.

What happens if the server goes down?

If a single host goes down, all 28 deployed applications and databases become unavailable simultaneously. This is the primary trade-off of running multiple workloads on a single node. To mitigate downtime, containers should be configured with automatic restart policies (restart: unless-stopped) so they recover immediately when the operating system reboots. Independent external uptime monitoring must be set up to alert your engineering team immediately if the server stops responding. For critical production availability, you should maintain automated offsite snapshots and cold-standby provisioning scripts, allowing you to restore the entire Coolify instance and databases to a new server in minutes.

How are backups handled across all databases?

Coolify includes automated backup tooling for supported databases like PostgreSQL, MySQL, and MongoDB. You can configure scheduled cron jobs to dump each database at defined intervals, such as hourly or daily, and stream the compressed archives directly to external S3-compatible object storage. Storing backups on the local disk of the same server is insufficient; offsite storage ensures data survival even if the host suffers hardware corruption or catastrophic failure. In addition to database-level logical dumps, you should schedule full server-level filesystem snapshots with your cloud provider and regularly test restoring data into a clean staging container to verify backup integrity.

Is self-hosting cheaper than Vercel or Heroku-style PaaS platforms?

At scale, self-hosting is usually significantly cheaper in raw infrastructure spend. Managed PaaS platforms bill per container, per team seat, per gigabyte of bandwidth, and per build minute. Running 28 separate web apps and accompanying databases on managed platforms can quickly scale into thousands of dollars each month. A dedicated bare-metal server or large virtual machine running Coolify typically costs a predictable flat fee of $40 to $150 per month for the same compute capacity. However, you must factor in maintenance: self-hosting shifts operating system updates, firewall rules, and uptime management onto your internal engineering team or maintenance partner.

Can you self-host domain email reliably with Stalwart?

Yes, Stalwart is a modern, high-performance mail server written in Rust that supports JMAP, IMAP, and SMTP with low resource overhead. However, email reliability depends heavily on network reputation rather than the software alone. To ensure outbound deliverability to major providers like Google and Microsoft, the host server must have a clean IP address, matching reverse DNS (PTR records), and strictly valid SPF, DKIM, and DMARC records. If your hosting provider has a poor IP reputation or blocks port 25, you can still use Stalwart for internal accounts and route external outbound messages through an authenticated SMTP relay service.

Sources

• Coolify Documentation: Proxy Routing and Multiple Applications
• Localtonet: How to Self-Host Coolify Guide