Self-Hosted VPS Infrastructure

The context

The software house needed infrastructure that could host internal applications, development services, and business systems without depending entirely on external VPS providers.

Instead of renting another cloud server, an existing physical machine was prepared as an on-premise server running Ubuntu 24.04. The objective was to make the machine behave like a practical self-hosted VPS: always reachable, remotely manageable, secure, and capable of running multiple production services.

The challenge

The project involved much more than installing Ubuntu and exposing a few ports. A server located inside a local network sits behind a router and NAT, which means networking, security, service management, remote administration, and infrastructure reliability all needed to be designed together.

• The server initially received its address dynamically from the local network
• Applications needed to be reachable from outside the office network
• The router had to correctly forward selected services to the internal server
• SSH access needed to use key-based authentication instead of relying on passwords
• Public IP, NAT, and possible CGNAT conditions needed to be identified
• Multiple applications needed to coexist on the same physical server
• Remote administration needed to remain available without physical access to the machine
• The server needed monitoring and safe shutdown behavior during power failures

The approach

I treated the machine as infrastructure rather than as a normal desktop computer. The setup was built layer by layer, starting from the local network and operating system before exposing any application to the public internet.

Each layer was verified independently. Local connectivity was established first, followed by static addressing, router configuration, remote SSH access, service deployment, monitoring, and operational safeguards.

• Install and prepare Ubuntu 24.04 as the server operating system
• Identify the active Ethernet interface and local network configuration
• Assign a predictable internal IP address through static networking or router DHCP reservation
• Verify the router's WAN address and determine whether the connection was behind NAT or CGNAT
• Configure selective TCP port forwarding on the ZTE router
• Set up secure SSH access using public and private keys
• Create dedicated Linux users for server and application administration
• Install Docker for containerized services where appropriate
• Prepare native application environments for workloads that should run directly on Ubuntu
• Configure remote administration tools for operational access
• Monitor CPU, memory, storage, network, and NVIDIA GPU resources
• Integrate UPS monitoring and automated shutdown procedures

Network architecture

The server remains inside the software house's private LAN while selected services are exposed through the router. The router acts as the boundary between the public internet and the internal server.

Internet
   |
   v
Public IP
   |
   v
ZTE Router / NAT
   |
   |-- TCP port forwarding
   v
Ubuntu 24.04 Server
   |
   |-- SSH administration
   |-- Docker services
   |-- Frappe / ERPNext workloads
   |-- RustDesk services
   |-- AI / Ollama services
   |-- Internal development services
   v
Local Network

Secure remote access

SSH became the primary administration interface. Instead of distributing server passwords, access could be provided using dedicated Linux accounts and SSH key pairs.

ssh -i ~/.ssh/admin.pem admin@SERVER_PUBLIC_IP

This approach makes individual access easier to control and provides a cleaner foundation for managing multiple developers or administrators who need access to the infrastructure.

Application hosting

Once the networking and administration layers were stable, the server became a shared platform for different workloads. Applications could run either directly on Ubuntu or inside containers depending on their operational requirements.

Infrastructure reliability

Running infrastructure from an office also introduces physical operational concerns that are usually hidden by cloud providers. Power availability became part of the server design.

A Prolink UPS was integrated with Network UPS Tools so Ubuntu could detect when the server switched to battery power. Shutdown automation was prepared to safely power off the machine after a defined period on battery rather than allowing an uncontrolled shutdown.

What was delivered

The result was a physical Ubuntu server that could be operated similarly to a VPS while remaining inside the company's own infrastructure.

• Ubuntu 24.04 server installation and operating environment
• Predictable local network addressing
• Public internet connectivity through router NAT and port forwarding
• SSH key-based remote administration
• Dedicated server users for application management
• Docker runtime for containerized workloads
• Environment for hosting Frappe and ERPNext applications
• Self-hosted remote access services
• Local AI and Ollama hosting capability
• CPU, memory, storage, network, and GPU monitoring
• UPS integration and automatic safe-shutdown handling

The outcome

The software house gained infrastructure that it could operate and control internally instead of treating every new application as a reason to provision another external VPS.

More importantly, the project established the fundamental infrastructure knowledge required to operate real services: Linux administration, networking, NAT, SSH security, application deployment, process management, observability, remote access, and hardware-level reliability.

• Greater control over where company services and data are hosted
• A reusable environment for deploying internal applications
• Remote server administration from outside the office network
• Reduced dependency on separate cloud instances for suitable workloads
• A foundation for hosting ERP, automation, scraping, and local AI services
• Better understanding and control of the complete infrastructure stack
• Ability to expand the server incrementally as new internal services are introduced

Technology decisions

The infrastructure was deliberately built using standard and widely supported technologies. The goal was not to reproduce every feature of a public cloud platform, but to create a server that was understandable, maintainable, secure, and practical for the software house's actual workloads.

• Ubuntu 24.04 LTS as the host operating system
• Linux networking for server interface configuration
• ZTE router NAT and port forwarding for controlled public access
• OpenSSH for remote server administration
• SSH public-key authentication for administrator access
• Docker and Docker Compose for containerized workloads
• Frappe Framework and ERPNext for business application workloads
• RustDesk for self-hosted remote access
• Ollama for local AI model serving
• NVIDIA GPU and nvidia-smi for GPU workloads and monitoring
• Network UPS Tools for UPS monitoring and shutdown automation
• Standard Linux system tools and systemd for service operations

What I learned

One of the most important lessons from this project was that hosting an application is only a small part of running infrastructure. A reliable server depends on networking, access control, process management, hardware, power, monitoring, and recovery procedures working together.

Building the environment from the physical machine upward gave me a much clearer understanding of what cloud VPS providers normally abstract away and how application infrastructure behaves before it reaches the application layer.