Back to Blog
On-Premise DeploymentPM2Node.jsInfrastructureDevOps

What On-Premise Deployment Taught Me About Real Constraints

Cloud deployment hides process management, restarts, and connection handling behind platform defaults. Deploying on a client's 4-core server with no managed services made every one of those assumptions explicit โ€” and forced better infrastructure decisions upfront.

Mar 10, 20256 min read

Most of my previous work was on cloud infrastructure. Managed databases, auto-scaling, health checks handled by the platform. The Digital SIR system deployed on the client's own servers. No cloud. No managed anything.

That changed what careful operations actually means.

Problem

On a cloud platform, if your app crashes, the platform restarts it. If you need more capacity, you provision it. If a database connection drops, the managed service handles reconnection. These are comfortable defaults that become invisible when you rely on them.

On-premise removes all of that. Process management, restart policies, memory limits, connection handling, logging rotation, deployment procedures. All of it becomes explicit. If the app crashes and nobody configured PM2 to restart it, it stays down.

The client's servers were physical machines with fixed specs. 4-core CPU, fixed memory. No elastic capacity. The system had to work reliably within those constraints from day one.

Physical server specs and constraints

There was also no VPC or private networking with managed security groups. Database connections had to be configured for the internal network with explicit connection limits. Exposing the wrong port meant a direct security risk.

Solution

I treated infrastructure constraints as design inputs from the start, not as problems to solve later.

For process management: PM2 cluster mode with explicit memory limits per process. The 1GB max_memory_restart setting means a process that hits a memory leak restarts before it affects other processes.

For resilience: autorestart policies, graceful SIGTERM handling, and uncaught exception recovery. The app handles its own process lifecycle.

For observability: Winston structured logging to per-brand log directories with rotation. When something goes wrong on a server with no cloud logging service, you need local logs that are organized and searchable.

For deployment: PM2 reload for zero-downtime updates. Old processes drain active connections while new processes take incoming traffic.

Result

The system has run on client hardware at 99.95% uptime.

Process crashes that would previously require manual intervention now recover automatically. Memory limits prevent runaway processes from taking down adjacent brand instances.

Structured logs made several production incident investigations straightforward. Searchable, timestamped records per brand per day, available locally.

The main difference from cloud deployment: nothing is automatic unless you make it automatic. That is both the constraint and the control.

Found this useful?

Share it with someone who'd appreciate it.

https://wardvisual.com/blogs/on-premise-deployment-lessons

Eduardo Manlangit Jr.
Eduardo Manlangit Jr.

@wardvisual ยท ๐Ÿ‡ต๐Ÿ‡ญ Dasmarinas City, Cavite PH

Full-stack engineer. Business systems, database optimization, and operations software.

Follow