Marlin Scheler · Junior DevOps / System Engineer

Self-hosted platform demonstrating real-world system operation.

  • Deployable through staged releases and health checks
  • Observable through metrics, logs, and uptime tracking
  • Recoverable through backups, restores, and rollback strategies

What you can do here:

  • Explore the architecture
  • View live system components
  • Review operational decisions and trade-offs

Live System Components

Public entry points and restricted operations surfaces.

Platform Snapshot

Concrete operating characteristics of the platform.

Host

Single Hetzner VM with 4 vCPU, 8 GB RAM, and bounded disk usage.

Runtime

Services run in separate containers instead of sharing one unmanaged host setup.

Ingress

Nginx handles HTTPS, redirects, and hostname-based routing for public services.

Delivery

GitHub Actions defines staged SSH releases with health gates, rollback mechanics, and explicit production verification.

Monitoring

Prometheus, Grafana, Node Exporter, cAdvisor, and Uptime Kuma cover host and service visibility.

Recovery

Database dumps, project archives, and restore scripts are part of normal operations.

Operational Metrics

Measured platform scope and operational coverage.

Portfolio Surfaces

5 documented portfolio surfaces across two hosting boundaries: 4 through the VM ingress and docs on GitHub Pages.

Network Segments

3 Docker networks separating frontend, backend, and monitoring traffic.

Backup Cadence

Daily database and runtime backup jobs with defined retention.

Monitoring Coverage

Host, container, and application checks are included in the stack.

Security Model

Security is treated as part of system design, not a side note.

Ingress Control

  • TLS termination via Nginx (HTTPS only)
  • Redirect enforcement and hostname routing
  • Request filtering and layered security headers

Access Control

  • Grafana and internal tools behind authentication
  • No direct public exposure of internal services

Isolation

  • Service separation via Docker networks
  • Distinct boundaries between frontend, app, and monitoring

Recovery

  • Regular backups with defined retention
  • Restore scripts and documented recovery procedures

Operational Focus

This platform is designed to be operated, not just deployed.

  • Incidents can be detected via metrics and uptime checks
  • Logs provide traceability across services
  • Deployments are gated by health checks
  • Recovery paths are defined and tested
service map one ingress layer, containerized services, monitored operations
Internet
   |
Nginx (Ingress)
   |
Docker Services (App / Monitoring)
   |
Metrics + Logs (Prometheus / Grafana)
   |
Backup System

Projects

Projects framed by concrete system behavior and operational value.

platform

Genesis / Self-Hosted Platform

Platform used to validate operational decisions under real conditions instead of theoretical setups.

  • Focus: Deployability
  • Focus: Observability
  • Focus: Recoverability
  • Linux
  • Docker Compose
  • Nginx
  • GitHub Actions
Read case studies
project showcase

DMA Statistics Module

A contained PHP and MariaDB workload for match-statistics analysis, retained as a read-only architecture showcase.

  • Separates application routing, database state, and health behavior
  • Uses external match data and role-based statistics
  • Public access exposes project context, not administrative controls
  • PHP
  • MariaDB
  • Health checks
  • Monitoring
Open project showcase
reporting

Automated Web Analytics with AWStats

Reference reporting workflow for generating lightweight webserver reports without adding a heavy analytics stack.

  • Provides a documented AWStats configuration and cron-ready generator
  • Requires an intentional access-log source before activation
  • Fits the resource limits of a small single-host platform
  • AWStats
  • Shell scripts
  • Cron
  • Reporting
Read project overview
operations

Web Platform Migration and Hardening

Moves existing web workloads into a safer operating model with cleaner routing and tighter access control.

  • Improves SSH, TLS, firewalling, and reverse proxy structure
  • Reduces cross-impact between services
  • Turns inherited setups into supportable systems
  • Ubuntu
  • SSH
  • UFW
  • Nginx
View architecture
stateful application

Inventory Tracking Application

Database-backed CRUD application for tracking stock and inventory changes under normal operational constraints.

  • Models relational inventory and stock state
  • Supports create, update, and delete workflows
  • Validates backup and restore behavior against persistent data
  • PHP
  • MariaDB
  • CRUD
  • Health checks
Read project notes
security automation

Vulnerability Relevance Automation

Current security automation work for turning vulnerability feeds into actionable, asset-relevant review tasks.

  • Maps ENISA EUVD records against an asset inventory
  • Adds CVSS, KEV, and EPSS context before review
  • Focuses on repeatable triage instead of manual feed scanning
  • ENISA EUVD API
  • SQLite
  • Automation
  • Freshservice
Read project overview

Documentation

Full documentation available: docs.shellr.net

The documentation site is the full technical record for the platform. It connects the landing page with architecture, deployment, monitoring, and recovery details.

Includes:

  • Architecture
  • Deployment flow
  • Monitoring setup
  • Backup and restore strategy