Current infrastructure, earlier builds and cybersecurity learning. Each section makes clear whether the work is running, a past exercise or a planned deployment.
Managing guests across two hosts. Jump to the VM setup notes.
Publishing static pages. Jump to the deployment and upload fix.
Planned deployment. Jump to the service and performance checklist.
Running containers. Jump to DNS configuration and availability checks.
A practice environment. Jump to the exercises and scripting goals.
Web discovery, lab reporting and ransomware research.
Where my storage, hosting and virtualisation practice started.
I use Proxmox to create Debian guests, assign resources and manage each VM through its lifecycle.
The cluster gives me a common management interface. The physical connections, node roles and quorum design are documented on the Homelab page.
Nginx serves the static files that make up this portfolio.
I deployed the HTML, CSS, JavaScript and images to a dedicated Debian VM. The web root is /var/www/html.
Next, I plan to add Nginx Proxy Manager for HTTPS and web reverse proxying. The existing Nginx instance will continue serving the website files.
An SCP upload to
/var/www/html
failed with this error:
SSH connected successfully, but my Linux user didn't have write permission in the Nginx web root. That explained why I could log in but couldn't upload the image there.
I uploaded the image to my home directory, then used sudo on the server to move it into the website images folder.
A Debian VM hosting a PaperMC server, with ongoing Java and service-configuration practice.
The aim is to take a game server from its initial Java setup to a managed service, then document how it behaves under player activity.
I plan to configure PaperMC as a systemd service so it runs independently of an SSH session. These are the commands I will use to manage the service and read its logs.
If the service fails to start, I will check its status and logs, then verify the Java command, file permissions and working directory in the systemd unit.
Administration will use SSH over private VPN access. Players will connect through the Minecraft game port.
After deployment, I will compare gameplay responsiveness with CPU and Java memory use as player activity increases.
Container deployment, service dashboards, a Pi-hole configuration issue and the information I get from availability checks.
I use Docker Compose to define and start the Pi-hole and Uptime Kuma containers. Here is how I prepare the directory for Uptime Kuma.
Compose files live under /opt/docker/, with each application in its own directory.
The configuration file records the image, settings and storage used when the container starts.
I manage application settings through environment variables and keep persistent data separate from the container image.
Pi-hole filters DNS queries from clients configured to use it. I review its dashboard for queries, blocked domains and active clients.
When I tried to change the web-interface password inside Pi-hole, the change didn't take effect as expected.
I found that a Docker environment variable was setting the password and overriding the change inside Pi-hole.
The fix depended on the deployment configuration, not just the setting visible inside the application.
Uptime Kuma records whether configured endpoints respond, giving me a timeline to compare with service logs.
Planned next: Prometheus will collect resource metrics and Grafana will display trends, adding context to a simple reachable/unreachable result.
Checks have reported refused connections, certificate verification problems and application errors.
I use the error and timestamp to choose which service logs to inspect first.
I deployed Homarr using Docker Compose in a Debian VM and verified that its web interface was reachable on port 7575.
This earlier deployment gave me practice with container ports, Compose configuration and checking that a service is accessible after it starts. Its placement is not assigned in the current cluster plan.
A dedicated Debian VM for Linux and Bash exercises.
I practise changes to accounts, files and services here before applying similar ideas to hosted workloads.
I’m learning to combine commands with variables, conditions and loops. The goal is a script whose output and failure cases I can explain.
Next, I want to turn a repeatable manual task into a small script and document the result.
Practical platform exercises and independent research support my interest in cybersecurity.
I have practised finding information through robots.txt, sitemap.xml, hidden files and directories, subdomains and virtual hosts.
The exercise is about understanding what an application exposes before choosing the next investigation step.
TryHackMe ↗I also use Hack The Box for cybersecurity learning. My focus is building confidence with Linux, networking and web fundamentals before taking on more complex assessments.
These are learning exercises; I am continuing to develop the skills needed for independent security work.
Hack The Box ↗I worked on a CTF exercise involving Subrion 4.2.1 and reverse-shell access, then wrote a report and conclusion describing the exercise.
The reporting practice was useful alongside the technical work: explain the steps, record the evidence and make the outcome understandable.
I researched the ransomware’s kill-switch mechanism and how researchers investigate compiled malware. I also explored ways to study a sample without executing it.
This is research into malware-analysis concepts. I am still developing my understanding of static inspection, reverse engineering and safe analysis environments.
Earlier hands-on work that contributed to my current skills. These are separate from the live layout shown on the Homelab page.
I built a NAS on a Raspberry Pi 5 with external storage and used Tailscale for remote access. It gave me an introduction to running a useful network service and accessing it remotely.
I configured an Apache web server on the Pi before moving my portfolio hosting to Debian and Nginx. That earlier work helped me understand the relationship between a server process, its files and network access.
I installed Linux and Windows systems and practised virtualisation with VMware. Those builds gave me experience setting up an OS and working with virtual machines before my current Proxmox setup.
I will add further configuration examples, screenshots, scripts and lab notes as I complete them.