☁️ Building a Secure On-Prem Private Cloud with Apache CloudStack, NGINX Reverse Proxy, and Cloudflare Tunnel

Arpan Bhattacharya — Fri, 06 Mar 2026 05:32:40 +0000

Modern applications are often deployed on public cloud platforms like AWS, Azure, or GCP. However, many organizations still require on-premise infrastructure to maintain greater control over networking, security, and data management.

In this article, we will walk through the architecture and setup of an on-premise private cloud built using Apache CloudStack, where internal virtual machines run within a private network and external access is securely managed using Cloudflare Tunnel and an NGINX reverse proxy VM.

This architecture allows services to remain isolated inside a private network while still being accessible from the internet in a secure and controlled manner.

🏗️ Architecture Overview

The infrastructure is designed around a layered architecture where external traffic is carefully routed through controlled entry points before reaching internal services.

Key characteristics of this architecture:

All internal workloads run within a private network
No application VM is directly exposed to the internet
A dedicated reverse proxy VM acts as the entry gateway
Cloudflare Tunnel securely connects external traffic to the internal network

This model closely resembles architectures used in enterprise environments with private subnets and controlled ingress gateways.

🌐 Internal Network Design
The CloudStack environment uses an internal network:
10.1.0.0/16

This private address space enables communication between virtual machines without exposing them publicly.

All services communicate through private IP addresses within the internal network.

Example internal access:
http://10.1.0.20:3000

Since this network is isolated, only the NGINX proxy VM is responsible for routing traffic from external sources.

🔐 Secure External Access Using Cloudflare Tunnel

Traditionally, exposing services requires opening firewall ports or assigning public IP addresses. Instead, this architecture uses Cloudflare Tunnel, which allows secure inbound access without exposing internal infrastructure.

Cloudflare Tunnel works by creating a persistent outbound connection from the server to Cloudflare's network. Incoming traffic from the internet is then routed through that tunnel.

Advantages of this approach include:

No need to open inbound firewall ports
Protection against common network attacks
Secure encrypted communication
Simplified external routing

Traffic flow example:
app.example.com → Cloudflare → Cloudflare Tunnel → NGINX Proxy

This design ensures that the internal infrastructure remains hidden from direct internet exposure.

⚙️ NGINX Reverse Proxy Layer

The NGINX VM acts as the central routing component inside the internal network.

It receives requests forwarded through the Cloudflare Tunnel and then routes them to the appropriate internal service.

Example CLoudflare configuration:

tunnel: <your-tunnel-id>
credentials-file: /etc/cloudflared/<tunnel-id.json>
protocol: http2
ingress:
- hostname: app1.example.com
  service: http://localhost:80
- hostname: app2.example.com
  service: http://localhost:80

This cloudflare tunnel config targets the nginx proxy vm to receive the traffice and forward it.

Example NGINX configuration:

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 2G;
    client_body_timeout 300s;
    proxy_read_timeout 300s;
    proxy_connect_timeout 300s;
    proxy_send_timeout 300s;
    proxy_request_buffering off;
    proxy_buffering off;
    location / {
        proxy_pass http://10.1.12.46:80/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

With this configuration:
Incoming Request → NGINX → Internal Service

This allows multiple services to be hosted behind a single entry point.

NGINX effectively functions as an internal application gateway.

🔁 End-to-End Request Flow

When a user accesses an application, the request passes through several controlled layers.

Step-by-step flow:

A user visits: https://app.example.com
DNS resolution occurs via Cloudflare.
Cloudflare forwards the request through the Cloudflare Tunnel.
The request reaches the NGINX reverse proxy VM.

NGINX routes the request to the appropriate internal virtual machine.

Example:
NGINX → 10.1.0.20:3000

The application processes the request and returns a response through the same path.

This layered routing ensures that external traffic never directly interacts with internal application servers.

🛡️ Security Advantages

This architecture provides several security benefits.

Internal Service Isolation

Application and database servers remain within the private network and are not reachable from the internet.

No Public Exposure of Application Servers

Only the reverse proxy VM communicates with external systems.

Encrypted Tunnel Communication

Cloudflare Tunnel ensures that all traffic entering the network is encrypted and authenticated.

Reduced Attack Surface

Since inbound firewall ports are not exposed, the attack surface is significantly minimized.

📊 Architectural Benefits

This setup offers several operational advantages:

Centralized ingress control
Secure external access without opening ports
Simplified routing for multiple services
Scalable infrastructure for additional virtual machines
Clear separation between external traffic and internal services

The design principles are similar to cloud-native patterns used in modern infrastructures such as:

Private VPC networks
Reverse proxy gateways
Ingress controllers
Secure edge tunnels

🧠 Key Takeaways

Designing an on-premise private cloud environment requires careful planning of networking, security, and traffic routing.

By combining:

Apache CloudStack for virtualization
NGINX as a reverse proxy gateway
Cloudflare Tunnel for secure external access

it is possible to build an infrastructure where services remain protected within a private network while still being accessible externally in a controlled way.

This architecture provides a strong foundation for hosting multiple services, APIs, and applications while maintaining a secure and scalable deployment model.

PostgreSQL Locally, the Easy Way: Docker Compose!

Arpan Bhattacharya — Wed, 18 Jun 2025 10:51:07 +0000

Tired of database setup headaches during local development? Installing PostgreSQL directly can be a mess of version conflicts and dependency issues. But what if there was a simpler, cleaner solution?

Enter Docker and Docker Compose.

These tools let you run PostgreSQL in an isolated container, making your local setup reproducible, portable, and incredibly easy to manage. No more "it works on my machine" excuses!

Why Docker Compose?

Isolation: Your database runs in its own clean container, avoiding conflicts with your system.
Reproducibility: A simple configuration file ensures everyone on your team has the exact same database environment.
Portability: Move your setup between projects or operating systems with ease.
Clean-up: Stop and remove containers without leaving a trace on your system.

Quick Setup: Your docker-compose.yml
Create a file named docker-compose.yml in your project:

services:
  db:
    image: postgres:latest
    restart: always
    container_name: postgres_db
    volumes:
      - ./data/db:/var/lib/postgresql/data
    ports:
      - 5432:5432 # default PostgreSQL port (make sure this port is not in use)

    environment:
      - POSTGRES_USER=your_username
      - POSTGRES_PASSWORD=your_password
      - POSTGRES_DB=your_database_name

  adminer:
    image: adminer:latest
    restart: always
    container_name: adminer
    ports:
      - 8080:8080 # Adminer web interface port
    depends_on:
      - db

What's happening here? We're defining a db service using the postgres image. We set environment variables for your database name, user, and password (please change the password!). The ports line maps port 5432 on your machine to the container. Crucially, the volumes line ensures your data persists even if you restart the container.

Run It!
Navigate to your docker-compose.yml directory in your terminal and run:

docker compose up -d

This command starts your PostgreSQL database in the background.

Connect and Develop
Now you can connect to your local PostgreSQL instance using:

Host: localhost
Port: 5432
Database: your_db_name
User: your_username
Password: your_password (your chosen password)

To remove containers and networks (but keep your data volume):

docker compose down

Embrace Docker Compose for your local PostgreSQL setup. It's a game-changer for developer sanity and team collaboration! 🌟🌟

DEV Community: Arpan Bhattacharya

☁️ Building a Secure On-Prem Private Cloud with Apache CloudStack, NGINX Reverse Proxy, and Cloudflare Tunnel

PostgreSQL Locally, the Easy Way: Docker Compose!