Self-Hosted Linux Server

Overview#

This project is less about shipping a polished product and more about maintaining an environment that keeps core infrastructure skills active.

The server runs Proxmox on spare hardware and supports Ubuntu VMs, LXC containers, backups, and remote development. It gives me a place to work through the day-to-day concerns that managed platforms hide: storage layout, patching, snapshots, SSH hardening, restore confidence, and what happens when hardware is less reliable than the cloud.

What It Supports#

The environment is used for four main jobs:

• remote Linux development through SSH into an Ubuntu VM
• backup and restore practice with ZFS-backed storage and scheduled jobs
• lightweight service hosting before pushing projects elsewhere
• general administration practice around VM lifecycle, monitoring, and troubleshooting

Because it is persistent and self-managed, it creates the kind of operational repetition that actually builds comfort with Linux systems.

Main Components#

Proxmox host#

Proxmox provides the hypervisor layer for running KVM VMs and LXC containers on the same machine. It also gives me snapshotting, cloning, and an interface for rebuilding systems quickly when I want to test changes or recover from mistakes.

Ubuntu development VM#

The primary VM is an Ubuntu Server machine used for remote development. Working this way keeps the development environment aligned with the Linux systems I expect to deploy to and separates it cleanly from the local laptop.

That matters for a few reasons:

• the runtime environment is predictable
• the VM can be snapshotted or rebuilt without affecting the host machine
• storage and compute decisions feel more like real systems work than local-only development

Backup storage#

A separate backup target uses ZFS for checksumming, compression, and snapshots. The goal is not just to create backups, but to treat restore confidence as part of the system design.

Operational Work#

Running the environment keeps a broad set of recurring tasks in practice:

• patching Linux systems and checking service health
• provisioning and rebuilding VMs
• managing SSH keys and remote access rules
• reviewing disk health and storage usage
• testing snapshots and restore paths
• troubleshooting network, DNS, and performance issues across the stack

These are small tasks individually, but together they create the operational habits I want to keep developing.

Security and Access#

Remote access is built around SSH with key-based authentication. Password login is disabled, the exposed port is non-standard, and the Proxmox web UI stays on the local network.

This is not presented as enterprise-grade security. It is a practical self-hosted setup where the goal is to build good habits: reduce exposed surfaces, separate access paths, and understand exactly how remote access is configured.

Challenges#

The hardest parts come from the fact that the hardware is ordinary and the system is self-managed.

• consumer hardware makes disk health, thermals, and recovery more important
• Proxmox networking takes careful configuration when multiple VMs and services share the same environment
• backup quality is only real if restores are tested rather than assumed

Those constraints are part of why the project is useful. It forces attention onto reliability and recovery instead of assuming the platform will absorb mistakes.

What It Shows#

This project shows steady, hands-on infrastructure practice rather than a one-time build.

• Linux administration: patching, service management, logs, storage, and monitoring
• virtualization: VM provisioning, cloning, snapshots, and rebuilds
• storage management: ZFS usage, backup design, and disk-health awareness
• remote operations: SSH hardening, external access, and troubleshooting from outside the host
• self-directed ownership: maintaining systems without a managed service doing the hard parts for me