VPS Setup & Secure SaaS Deployment | Nginx Reverse Proxy Case Study

Secure VPS Infrastructure and Production SaaS Deployment for a France-Based Business

Project Overview

We developed and configured a secure VPS infrastructure and production SaaS deployment environment for a France-based business that needed to move its application from a development environment to a reliable, secure, production-ready cloud server.

The project focused on the infrastructure layer behind a SaaS application, including VPS setup, Linux server configuration, application deployment, Nginx reverse proxy configuration, SSL/HTTPS, firewall hardening, Docker services, domain routing, database deployment, process management, server monitoring, and production security.

The client required a deployment architecture capable of hosting multiple application services while keeping internal services protected from direct public access.

We designed the infrastructure around a clear production model:

Internet → Nginx → Application Services → Database / Internal Services

Rather than exposing application ports directly to the internet, Nginx was configured as the public-facing reverse proxy. Internal services were bound to controlled interfaces and accessed through the appropriate application layer.

The deployment provided the client with a foundation for running a modern SaaS application on its own Linux VPS infrastructure while maintaining control over the server, application environment, domains, SSL certificates, databases, and deployment configuration.

 

---

The Business Challenge

The client had a SaaS application that needed a production deployment environment.

The development environment was suitable for building and testing the application, but production deployment introduced a completely different set of requirements.

A production SaaS server needs to handle:

• Public HTTP/HTTPS traffic

• Domain routing

• SSL certificates

• Application processes

• Database services

• Internal APIs

• Background services

• Server security

• SSH access

• Firewall rules

• Application restarts

• Logs

• Reverse proxy configuration

• Environment variables

• Deployment consistency

Simply uploading application files to a VPS would not provide a reliable production architecture.

The client therefore required a properly configured infrastructure where public traffic could be securely routed to the appropriate application services.

---

The Main Infrastructure Problems

Before production deployment, several infrastructure concerns needed to be addressed.

Application Exposure

Application services should not all be directly accessible from the public internet.

Reverse Proxy

The system needed a central HTTP/HTTPS entry point.

SSL

The SaaS application needed encrypted HTTPS communication.

Server Security

SSH, firewall rules, users, services, and exposed ports needed to be controlled.

Application Management

Backend services needed reliable startup, restart, and failure handling.

Database Protection

PostgreSQL and Redis should not be unnecessarily exposed publicly.

Domain Routing

The client's domain needed to resolve correctly to the VPS and route requests to the correct application.

Production Configuration

Development configuration needed to be separated from production configuration.

---

Project Objectives

The infrastructure project was designed to:

1. Configure the client's VPS.

2. Install and harden the Linux environment.

3. Configure secure SSH access.

4. Configure firewall rules.

5. Install Docker and required services.

6. Deploy the SaaS application.

7. Configure Nginx as a reverse proxy.

8. Connect the production domain.

9. Configure HTTPS/SSL.

10. Protect internal application ports.

11. Deploy PostgreSQL.

12. Deploy Redis where required.

13. Configure application services.

14. Configure environment variables.

15. Establish production logging.

16. Configure service restart behavior.

17. Validate external access.

18. Test the complete production architecture.

The central objective was:

Turn a raw VPS into a secure, production-ready SaaS hosting environment.

---

The Solution

We designed a production deployment architecture based on a Linux VPS, Dockerized application services, Nginx reverse proxy, PostgreSQL, Redis, HTTPS, and server-level security.

A simplified architecture is:

                         INTERNET
                            │
                            ▼
                     Domain / DNS
                            │
                            ▼
                    Nginx Reverse Proxy
                       │          │
                    HTTPS       Routing
                       │          │
              ┌────────┴──────────┴────────┐
              ▼                             ▼
        React / Next.js                API Services
                                          │
                                  ┌───────┴───────┐
                                  ▼               ▼
                              Node.js          FastAPI
                                  │               │
                                  └───────┬───────┘
                                          ▼
                                  PostgreSQL / Redis

The important architectural principle was:

Only the required public entry points are exposed.

Internal application services remain behind the reverse proxy and server network boundaries.

---

What Is VPS Deployment?

A Virtual Private Server (VPS) provides a dedicated virtualized server environment where an organization can deploy and manage its own applications.

Unlike basic shared hosting, a VPS provides significantly more control over:

• Operating system

• Server software

• Network configuration

• Firewall

• Docker

• Nginx

• Application processes

• Databases

• SSL

• Deployment architecture

For SaaS applications, this level of control can be useful when the application requires custom backend services, databases, APIs, containers, or specialized infrastructure.

---

VPS Provisioning

The first stage involved preparing the VPS for production.

The server configuration included:

• Linux operating system

• Server hostname

• System updates

• Required packages

• Administrative user

• SSH configuration

• Firewall

• Docker

• Nginx

• Application dependencies

The goal was to establish a clean baseline before deploying the SaaS application.

---

Linux Server Configuration

The VPS was configured as a dedicated Linux production environment.

Initial server preparation included:

VPS
 ↓
System Update
 ↓
Required Packages
 ↓
User Configuration
 ↓
SSH Security
 ↓
Firewall
 ↓
Docker
 ↓
Nginx
 ↓
Application Deployment

Keeping server preparation separate from application deployment makes infrastructure troubleshooting easier.

---

SSH Security

SSH provides administrative access to the VPS, but exposing SSH without appropriate controls creates unnecessary security risk.

The configuration therefore focused on:

• Secure authentication

• Administrative user management

• Root-access restrictions where appropriate

• SSH configuration

• Key-based authentication where available

• Controlled SSH access

• Firewall restrictions

The goal was to ensure that server administration remained controlled.

---

Firewall Configuration

A production VPS should expose only the ports required by the architecture.

A typical public-facing configuration includes:

Port 80   → HTTP
Port 443  → HTTPS
Port 22   → SSH, restricted where appropriate

Application ports such as:

3000
8000
5432
6379

do not need to be publicly exposed when the services operate internally behind Docker or the local server network.

This significantly reduces the public attack surface.

---

Why Port Security Matters

Consider a SaaS application with:

React → 3000
FastAPI → 8000
PostgreSQL → 5432
Redis → 6379

Exposing all of these ports publicly would create unnecessary entry points.

Instead:

Internet
   ↓
443 HTTPS
   ↓
Nginx
   ↓
Internal Services

The database and cache remain internal.

---

Docker Installation

Docker was incorporated to provide consistent application environments.

The application stack can be separated into containers such as:

Docker
 ├── Frontend
 ├── Node.js API
 ├── FastAPI
 ├── PostgreSQL
 ├── Redis
 └── Supporting Services

This allows each service to maintain its own dependencies and runtime environment.

---

Why Docker Was Used

Docker provides several advantages for SaaS deployment.

It helps with:

• Dependency isolation

• Deployment consistency

• Service separation

• Environment reproducibility

• Application updates

• Service management

• Development-to-production consistency

It also makes it easier to recreate the application environment on another VPS when required.

---

Production Environment Variables

Application configuration was separated from application source code.

Environment variables can contain values such as:

DATABASE_URL
REDIS_URL
API_URL
SECRET_KEY
JWT_SECRET
AI_API_KEY
APP_ENV
DOMAIN

Sensitive credentials should not be hard-coded into frontend source code or committed to public repositories.

---

Database Deployment

PostgreSQL was deployed as part of the production application infrastructure.

The database architecture was designed to remain internal to the VPS or private container network.

A simplified structure is:

Application
     ↓
Internal Network
     ↓
PostgreSQL

The PostgreSQL port does not need to be exposed publicly for normal application operation.

---

Redis Deployment

Redis was deployed where required by the SaaS architecture.

Redis can support:

• Caching

• Sessions

• Background jobs

• Temporary state

• Rate limiting

• Queue-related operations

Like PostgreSQL, Redis should generally remain inaccessible directly from the public internet unless a specific architecture requires otherwise.

---

Nginx Reverse Proxy

One of the most important parts of the deployment was the Nginx reverse proxy configuration.

Nginx acts as the public gateway to the application.

Instead of customers connecting directly to internal application ports, requests arrive at Nginx.

Customer
   ↓
HTTPS
   ↓
Nginx
   ↓
Application

This creates a clean separation between:

Public traffic

and

Internal services.

---

Why Nginx Was Used

Nginx provides several useful capabilities for SaaS deployments.

It can handle:

• Reverse proxying

• HTTPS termination

• Domain routing

• Static assets

• Request forwarding

• Connection management

• Security headers

• Multiple applications

• Multiple subdomains

This makes Nginx a strong infrastructure component for VPS-hosted SaaS applications.

---

Nginx Routing Architecture

The reverse proxy can route different domains or paths to different services.

For example:

app.example.com
       ↓
Nginx
       ↓
Frontend Application


api.example.com
       ↓
Nginx
       ↓
FastAPI / Node.js API

This allows multiple services to operate behind the same VPS.

---

API Reverse Proxy

Backend APIs can run on internal ports such as:

127.0.0.1:8000

or within a Docker network.

Nginx forwards external API requests internally.

For example:

https://api.example.com
          ↓
       Nginx
          ↓
      FastAPI :8000

The customer never needs to know the internal application port.

---

Frontend Reverse Proxy

The same architecture can be applied to React or Next.js applications.

For example:

https://example.com
       ↓
Nginx
       ↓
Next.js Application

This creates a clean production URL without exposing the frontend's internal port.

---

Domain & DNS Configuration

The client's domain was connected to the VPS through DNS configuration.

A simplified process is:

Domain
  ↓
DNS
  ↓
VPS Public IP
  ↓
Nginx
  ↓
Application

DNS records must point the relevant domain or subdomain to the production server.

---

SSL / HTTPS Configuration

HTTPS was configured to encrypt communication between users and the SaaS application.

A typical certificate workflow uses Let's Encrypt.

The architecture becomes:

Browser
   ↓
HTTPS :443
   ↓
SSL Certificate
   ↓
Nginx
   ↓
Application

This protects data transmitted between the user and the public application endpoint.

---

Let's Encrypt

Let's Encrypt can provide trusted TLS certificates without requiring a commercial certificate purchase.

The production setup includes certificate issuance and renewal considerations.

Automatic renewal is important because certificates have limited validity periods.

---

HTTP to HTTPS Redirect

Once HTTPS was configured, HTTP traffic could be redirected to HTTPS.

The conceptual flow is:

http://example.com
        ↓
     Redirect
        ↓
https://example.com

This ensures that users reach the encrypted version of the application.

---

Security Headers

Nginx can also be configured to provide appropriate HTTP security headers.

Depending on application requirements, these can include controls related to:

• Content Security Policy

• X-Content-Type-Options

• Referrer Policy

• Frame protection

• Transport security

The exact header configuration should be tested against the application's frontend, APIs, authentication, and third-party integrations.

---

Application Deployment

After the VPS and networking layers were prepared, the application services were deployed.

The deployment process was structured as:

Source Code
   ↓
Production Configuration
   ↓
Docker Build
   ↓
Container Deployment
   ↓
Database Connection
   ↓
Redis Connection
   ↓
Nginx Routing
   ↓
HTTPS
   ↓
Production Testing

---

Frontend Deployment

The frontend application was deployed as a production build.

Depending on the application architecture, this could involve:

• React

• Next.js

• Node.js runtime

• Static asset serving

The production frontend is then connected to the backend API through the configured public API domain or route.

---

Backend Deployment

Backend services were deployed separately from the frontend.

The architecture can contain:

Frontend
   ↓
Nginx
   ↓
Backend API
   ↓
Database

For Python services, FastAPI can be served through an ASGI server such as Uvicorn or Gunicorn with an appropriate deployment configuration.

Node.js services can run through their production runtime within Docker.

---

FastAPI Production Deployment

The FastAPI application was configured as a production backend service.

The internal architecture can look like:

Nginx
  ↓
FastAPI
  ↓
Uvicorn
  ↓
Application Code
  ↓
PostgreSQL / Redis

The application does not need to expose its internal port directly to the public network when Nginx handles external traffic.

---

Node.js Production Deployment

Node.js services were configured for production execution.

Depending on the application, the service can handle:

• API requests

• Business logic

• Authentication

• SaaS operations

• External integrations

• Background services

Docker provides the runtime environment and Nginx provides the public routing layer.

---

Process Management

Production applications must remain available even when individual processes restart or fail.

Container restart policies and appropriate process-management strategies were incorporated into the deployment architecture.

The objective is:

Service Failure
      ↓
Restart / Recovery
      ↓
Application Available

This reduces the need for manual intervention after routine service failures.

---

Database Migrations

Application database schemas need to be synchronized with the deployed application version.

The deployment process therefore includes database migration management where required.

A typical flow is:

Application Update
       ↓
Migration Check
       ↓
Database Migration
       ↓
Application Start

Migration procedures should be tested before applying structural database changes to production.

---

Logging

Production logging is important for diagnosing:

• Application errors

• API failures

• Nginx errors

• Authentication issues

• Database problems

• Container failures

• SSL problems

The infrastructure therefore maintains logs at different layers:

Nginx Logs
Application Logs
Container Logs
Database Logs
System Logs

Centralized log management can be introduced later as the infrastructure grows.

---

Monitoring

Server and application monitoring can track:

• CPU usage

• RAM usage

• Disk usage

• Network traffic

• Container status

• Application health

• Database health

• API availability

Monitoring becomes increasingly important as SaaS traffic increases.

---

Health Checks

Application health endpoints can be used to verify whether services are functioning correctly.

For example:

GET /health

can return a simple status response.

More comprehensive health checks can verify:

Application
     ↓
Database
     ↓
Redis
     ↓
External Dependencies

This helps identify whether the problem is in the application or infrastructure layer.

---

Server Storage Management

A SaaS VPS requires careful disk management.

Storage can be consumed by:

• Docker images

• Container logs

• Databases

• Uploaded files

• Application builds

• Backups

Disk usage monitoring and cleanup procedures are therefore important parts of server administration.

---

Backup Strategy

Production SaaS infrastructure should have a backup strategy appropriate to the application's data requirements.

Potential backup components include:

• PostgreSQL database

• Uploaded files

• Application configuration

• Nginx configuration

• Docker configuration

• Environment configuration where securely managed

A backup is only useful if it can actually be restored, so restoration testing is an important part of a mature backup strategy.

---

Server Security Architecture

The VPS security model was built in layers.

Internet
   ↓
Firewall
   ↓
Nginx
   ↓
Application
   ↓
Internal Services
   ↓
Database

Each layer has a specific responsibility.

---

Principle of Least Exposure

The deployment follows the principle:

Expose only what needs to be public.

For a typical SaaS application:

PUBLIC
 ├── 80
 └── 443

RESTRICTED
 └── SSH

INTERNAL
 ├── PostgreSQL
 ├── Redis
 ├── FastAPI
 └── Node.js

This reduces unnecessary network exposure.

---

Server Updates

Regular operating-system updates are an important part of VPS management.

The production server requires ongoing maintenance for:

• Security patches

• Docker updates

• Nginx updates

• Runtime updates

• Database updates

• Dependency updates

Infrastructure management therefore continues after the initial deployment.

---

Production Architecture

The final infrastructure can be represented as:

                           INTERNET
                              │
                              ▼
                       Domain / DNS
                              │
                              ▼
                        Firewall
                              │
                              ▼
                     Nginx Reverse Proxy
                       │             │
                       │             │
                    HTTPS          Routing
                       │             │
              ┌────────┴─────────────┴────────┐
              │                                │
              ▼                                ▼
       React / Next.js                    API Services
                                              │
                                   ┌──────────┴──────────┐
                                   ▼                     ▼
                                Node.js              FastAPI
                                   │                     │
                                   └──────────┬──────────┘
                                              ▼
                                    Internal Docker Network
                                              │
                                  ┌───────────┴───────────┐
                                  ▼                       ▼
                             PostgreSQL                 Redis

This architecture provides a clear boundary between public traffic and internal application services.

---

Development & Deployment Process

Phase 1 — Infrastructure Assessment

We reviewed:

• Application architecture

• Required services

• Domain structure

• Database requirements

• Runtime requirements

• Deployment requirements

• Security requirements

This established the infrastructure blueprint.

---

Phase 2 — VPS Provisioning

The Linux VPS was prepared with:

• System updates

• Administrative access

• Required packages

• Server configuration

• Security baseline

---

Phase 3 — SSH Hardening

SSH access was configured and restricted according to the production security requirements.

---

Phase 4 — Firewall Configuration

Only the required public and administrative ports were made accessible.

Internal application and database services remained protected.

---

Phase 5 — Docker Environment

Docker and required container services were configured.

---

Phase 6 — Application Deployment

Frontend and backend services were deployed in production configuration.

---

Phase 7 — Database & Redis

PostgreSQL and Redis were configured within the internal application environment.

---

Phase 8 — Nginx Reverse Proxy

Nginx was configured to route:

Domain → Frontend
API Domain → Backend

while keeping internal ports protected.

---

Phase 9 — DNS Configuration

The domain was pointed to the VPS and DNS propagation was verified.

---

Phase 10 — SSL Configuration

HTTPS certificates were configured and the application was made available securely over TLS.

---

Phase 11 — Production Testing

The complete stack was tested from the public internet.

Testing included:

• Domain resolution

• HTTPS

• Frontend loading

• API requests

• Authentication

• Database connectivity

• Redis connectivity

• Nginx routing

• Container status

• Error handling

• Firewall behavior

• Internal service exposure

---

Key Technical Challenges

Challenge 1 — Securing a Raw VPS

A newly provisioned VPS is not automatically a secure SaaS production environment.

The server required deliberate configuration of:

• SSH

• Firewall

• Users

• Ports

• Services

• Application access

---

Challenge 2 — Routing Multiple Services

The application contained multiple internal services.

Nginx provided the routing layer required to expose them through clean public domains without exposing their internal ports.

---

Challenge 3 — SSL & Domain Configuration

The production domain needed to resolve correctly to the server, while HTTPS needed to be configured without breaking API or frontend communication.

---

Challenge 4 — Protecting Internal Services

PostgreSQL, Redis, FastAPI, and Node.js did not need to be directly accessible from the public internet.

The network architecture therefore separated public endpoints from internal services.

---

Challenge 5 — Production Environment Differences

Development environments and production servers have different requirements.

Environment variables, domains, ports, database connections, SSL, logging, and security settings all needed to be adapted for production.

---

Business Impact

The infrastructure deployment provided the France-based client with a controlled production environment for its SaaS application.

The architecture can help the business:

• Deploy SaaS applications on its own VPS

• Reduce unnecessary public service exposure

• Serve applications through HTTPS

• Centralize traffic through Nginx

• Run multiple application services

• Protect databases from direct public access

• Containerize production services

• Manage domains and subdomains

• Establish a repeatable deployment architecture

• Maintain greater control over infrastructure

The primary transformation was:

Raw VPS → Secure, structured, production-ready SaaS infrastructure.

---

Why Nginx Reverse Proxy Is Important for SaaS

A reverse proxy is more than a traffic forwarding mechanism.

Nginx creates an abstraction layer between users and internal application services.

Without a reverse proxy:

User → :3000
User → :8000
User → :8080

With Nginx:

User
 ↓
https://app.example.com
 ↓
Nginx
 ↓
Internal Application

This creates cleaner URLs, centralized HTTPS handling, controlled routing, and reduced exposure of internal services.

---

VPS vs Shared Hosting for SaaS

Shared Hosting

Shared hosting is generally designed for websites and simpler applications.

Limitations can include:

• Limited server control

• Restricted runtimes

• Limited background services

• Limited networking configuration

• Limited Docker support

• Less infrastructure flexibility

VPS

A VPS provides substantially more control over:

• Linux

• Docker

• Nginx

• Databases

• Application runtimes

• Firewall

• Networking

• Server configuration

• Deployment architecture

For custom SaaS applications with multiple services, a VPS can provide the infrastructure flexibility required by the application.

---

Managed Cloud vs Self-Managed VPS

A self-managed VPS provides greater control over the operating environment, but it also creates responsibility for:

• Security updates

• Backups

• Monitoring

• Server maintenance

• SSL

• Firewall

• Application deployment

• Incident response

This project therefore treated server management as an ongoing infrastructure responsibility rather than simply installing an application once.

---

Future Infrastructure Expansion

The deployment can be expanded as the SaaS product grows.

Potential future improvements include:

• Automated CI/CD

• GitHub Actions deployment

• Load balancing

• Multiple VPS nodes

• Database replication

• Managed PostgreSQL

• Object storage

• CDN integration

• Centralized monitoring

• Prometheus

• Grafana

• Automated backups

• Log aggregation

• Container orchestration

• Infrastructure as Code

• Zero-downtime deployments

• Automated security scanning

• Disaster recovery architecture

This creates a path from a single VPS deployment toward a more distributed production infrastructure.

---

Technology Stack

Server & Infrastructure

• Linux

• VPS

• Docker

• Nginx

• SSH

• Firewall

• SSL/TLS

• Let's Encrypt

• DNS

Application

• React.js

• Next.js

• Node.js

• Python

• FastAPI

• Uvicorn

Database

• PostgreSQL

• Redis

Deployment

• Docker Compose / Containerized Services

• Nginx Reverse Proxy

• Production Environment Variables

• Database Migrations

• Application Logs

• Health Checks

Security

• SSH Hardening

• Firewall Configuration

• HTTPS

• Access Control

• Internal Service Isolation

• Secure Environment Configuration

• Restricted Database Exposure