Self-Run Game Server Hosting

Overview

Starting in 2018, I founded and have run a game server hosting business, renting managed game server instances to customers. The work is infrastructure operations plus customer service, billing, and community management.

This was never a hobby project. It was a real business, with paying customers who expected uptime, performance, and support.

Features

• Every customer gets an isolated instance, provisioned and managed through the AMP panel.
• Prometheus scrapes metrics from all of them into Grafana dashboards, and alerts go to Discord.
• Capacity is split between home servers and VPS instances, for cost on one side and security on the other.
• Customers restart and reconfigure their own servers from the web panel.
• Payment processing covers both recurring subscriptions and one-time purchases.
• Support runs in Discord channels, with ticket workflows for anything that needs tracking.

Technical highlights

Control plane

AMP (Application Management Panel) provided the multi-tenant foundation. It provisioned instances and managed their lifecycle, held each customer to their allocated resources, gave them a web interface to work in, and exposed an API for automation and integration. Customers managed their own servers without needing Linux expertise.

Monitoring infrastructure

Prometheus scraped every instance. Grafana showed server health, player counts, and resource utilization, and custom exporters covered the game-specific metrics. Alerts landed in Discord, which is how I heard about a problem before a customer reported it. The same data is what capacity decisions got made on.

Hybrid hosting model

The infrastructure spanned multiple locations. Home hardware gave higher capacity for the money, direct control over the machines and the networking, and lower latency for customers who happened to be nearby. VPS instances gave geographic distribution, absorbed demand spikes, and kept public-facing ingress off my home network. Routing put customers on the endpoint that suited them while the home side stayed behind controlled ingress.

Security architecture

Multi-tenant hosting lives on its boundaries. Customer instances were isolated from each other, management interfaces were protected from public access, ingress went through allowlists and firewalls, and patching stayed on a schedule. A single compromised customer instance couldn't affect other customers or reach the infrastructure underneath.

Architecture

graph TB
    subgraph customers [Customers]
        Players[Game Clients]
        Admins[Server Admins]
    end
    
    subgraph frontend [Frontend]
        Store[Storefront]
        Panel[AMP Panel UI]
    end
    
    subgraph control [Control Plane]
        AMP[AMP Controller]
        Billing[Billing System]
        Provisioning[Provisioning]
    end
    
    subgraph data [Data Plane]
        subgraph home [Home Infrastructure]
            HomeInstances[Game Instances]
            HomeStorage[World Storage]
        end
        
        subgraph vps [VPS Infrastructure]
            VPSInstances[Game Instances]
            VPSStorage[World Storage]
        end
    end
    
    subgraph observability [Observability]
        Prometheus[Prometheus]
        Grafana[Grafana]
        Discord[Discord Alerts]
    end
    
    Players --> HomeInstances
    Players --> VPSInstances
    Admins --> Panel --> AMP
    Store --> Billing --> Provisioning --> AMP
    AMP --> HomeInstances
    AMP --> VPSInstances
    HomeInstances --> Prometheus
    VPSInstances --> Prometheus
    Prometheus --> Grafana --> Discord

Business operations

Customer lifecycle

Customers arrive through marketing or word-of-mouth referral, pick what they want on the storefront, and pay. Provisioning creates the instance automatically. Then panel access and initial configuration, and after that they run the server themselves with support available when they want it. Retention is subscription renewals and upsells.

Support workflows

Support runs through Discord: ticket channels for tracking issues, a knowledge base for the questions that come up over and over, escalation paths for the ones that don't, and published response-time expectations and SLAs. Good support was a competitive differentiator. Customers stayed because problems got solved quickly.

Capacity management

Utilization monitoring shows which instances are over-provisioned. Allocation is deliberate enough that one noisy neighbor cannot take resources from everybody else. The rest is ordinary capacity planning for growth, and cost work that does not come out of customer performance.

Scale

At peak the platform ran several game types, Minecraft among them, with 100+ concurrent players across all of it, paying customers on recurring subscriptions, and a staff team helping with support and moderation.

Lessons learned

Multi-tenancy is hard. Isolation, fairness, and security need constant attention. Monitoring is not optional either, because you cannot run what you cannot see.

Support is part of the product. Technical excellence means nothing to a customer who cannot get help with it. Automation is what makes any of it scale, since manual processes break at customer volume, and the business half (billing, communication, process) turned out to matter as much as the infrastructure.

Current status

The business still runs, on an intermittent basis, and both the infrastructure and the operational knowledge are worth keeping. Multi-tenant operations, monitoring, customer-facing service delivery, and the business mechanics behind them are what I carried into platform and DevOps work.