Linux engineering, self-hosted infrastructure, automation, observability, and practical developer software.
|
My work sits at the intersection of applications and systems: tools that run on Linux, observe infrastructure, automate repetitive operations, expose useful telemetry, manage local resources, or improve how developers interact with their machines. I am most interested in projects where understanding the underlying system matters just as much as building the interface around it. That has led me to work across:
I value software that is clear to operate, straightforward to inspect, modular enough to extend, and useful enough to keep running. |
|
Build the product. Understand the system. Remove the repetition.
|
A self-hosted dashboard that brings host metrics, Proxmox guests, Docker workloads, network topology, alerts, and administration into one infrastructure view. Nexora Agent provides host-local telemetry. Engineering surface
Built with
|
A modular Linux agent that collects node-local telemetry and reports it outbound to Nexora Lab. Its capability-based plugins run only where the host supports them. Telemetry surface
Built with
|
|
A framework-free ZSH environment that gives Linux systems a polished, distribution-aware shell while keeping the implementation lightweight and understandable. Designed around
Built with
|
A cross-platform image compression application built for both interactive use and repeatable automation. Designed around
Built with
|
|
A curses-based typing environment that combines practice, persistent progress, adaptive offline learning, and keyboard diagnostics inside the terminal. Designed around
Built with
|
A self-hosted media application that turns local or network-attached storage into a complete streaming environment. Designed around
Built with
|
Nexora Lab and Nexora Agent are release candidates. Clean-host installation, HTTPS, upgrade, and recovery acceptance remain open; see the release checklist.
Nexora Lab and Nexora Agent are separate projects with a shared, versioned telemetry protocol.
The dashboard owns the operational experience.
The agent owns node-local enrichment.
┌────────────────────────────────────────────────────────────────────────────┐
│ NEXORA LAB │
│ │
│ Fleet · Servers · Topology · Telemetry · Alerts · Administration │
└────────────────────────────────┬───────────────────────────────────────────┘
│
normalized data model
│
┌─────────────────┴──────────────────┐
│ │
┌────────▼─────────┐ ┌─────────▼─────────┐
│ Infrastructure │ │ Nexora Agent │
│ Providers │ │ │
│ │ │ Node-local │
│ Proxmox / APIs │ │ enrichment │
│ VM / LXC state │ │ │
│ Cluster state │ │ Sensors · SMART │
│ Storage / Tasks │ │ Docker · Network │
└──────────────────┘ └─────────┬─────────┘
│
┌─────────────────────┼────────────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Linux │ │ Docker │ │Hardware │
│ Host │ │ Engine │ │ / Disks │
└─────────┘ └─────────┘ └─────────┘
| Layer | Responsibility |
|---|---|
| Nexora Lab | dashboard, fleet state, alerts, topology, administration |
| Infrastructure providers | authoritative platform / infrastructure data |
| Nexora Agent | outbound host telemetry and machine-local enrichment |
| Linux / Docker / hardware | raw operating environment |
The result is a system where richer telemetry can be added without forcing the dashboard to become tightly coupled to one operating system, one hypervisor, or one hardware layout.
|
Linux |
Self-hosting |
Agents |
Web platforms |
┌────┬────────────────┬────────────────────────────────────────────────────┐
│ 01 │ Nexora Lab │ Infrastructure visibility and operations │
│ 02 │ Nexora Agent │ Host telemetry and system enrichment │
│ 03 │ DistroZSH │ Lightweight Linux shell experience │
│ 04 │ Python-Keybr │ Terminal training and keyboard diagnostics │
│ 05 │ CompressMe │ Image optimization for users and automation │
│ 06 │ MovieFlix │ Private media built around local / NAS storage │
└────┴────────────────┴────────────────────────────────────────────────────┘
The problem determines the stack. Technologies are tools, not the identity of the project.
|
Useful over impressive. A project should solve a workflow or remove friction, not exist only to demonstrate a technology. |
Understand the system. Good software makes behavior observable and important decisions explainable. |
Remove repetition. Repeated operations eventually become scripts, tools, agents, or better interfaces. |
|
Keep boundaries deliberate. Collection, presentation, integrations, storage, and platform-specific logic should have clear responsibilities. |
Control the important layers. Self-hosting is valuable when it improves control over deployment, data, and the underlying system. |
Ship, observe, refine. Useful software is shaped by real usage, debugging, feedback, and repeated improvement. |
DISCOVER
understand the problem
│
▼
BUILD
create the smallest
useful system
│
▼
OBSERVE
expose behavior and
failure modes
│
▼
IMPROVE
remove friction and
tighten architecture
│
▼
AUTOMATE
make repeated work
disappear
│
└──────────────────────► iterate
A project is not finished because the interface renders or the command succeeds.
It becomes valuable when someone can understand it, run it, operate it, recover from problems, and extend it without fighting the architecture.
I publish my main projects in public because software becomes more valuable when people can inspect it, learn from it, run it, adapt it, and improve it.
If something I built has saved you time or made a system easier to operate, you can support continued development here:
Based in the Philippines · Support is open worldwide.
