Ayron Jins builds systems.
Understand them.

Choose what to inspect.

Detailed material is organised into focused pages, so you can go directly to the work that matters to you.

A portfolio of systems, not just screenshots.

Ayron Jins is a student systems builder, and the areas below aren’t really separate: networking, Linux infrastructure, homelab engineering, AI systems, automation and the public tools all feed into each other. A network makes a service reachable. Infrastructure makes an experiment repeatable enough to trust. Software is what turns the result into something someone else can actually use.

The work documented here is mostly about the layer beneath the interface: how a request actually travels, how a service gets operated day to day, where an agent's boundaries are drawn, and how a failure gets traced rather than guessed at.

Practical utilities for the public web.

The Tools Lab turns the portfolio’s technical interests into interfaces you can actually use. They're not placeholder calculators. Each one demonstrates something specific, whether that's backend safety, a browser-local algorithm, DNS/TLS reasoning, or how HTTP and technical SEO signals actually work.

The systems layer behind the work.

The Home Lab is where infrastructure concepts become operating practice. It brings together Linux administration, Proxmox virtualization, Docker services, Nginx at the web edge, DNS, storage, systemd service management, monitoring and backups. The important part is not the list of products; it is being able to explain the request path and identify which boundary failed.

The same thinking supports the public tools: validate an input, constrain a capability, observe the result and make the next decision from evidence. The homelab and networking case study records the operating environment and the storage expansion incident in more detail.

Make intelligence operate inside a boundary.

The AI work here is about more than generating text. KHS AI is really an exploration of how a model reasons about a goal, works with the tools it's explicitly given, interacts with software, and (this is the part that matters) knows when to stop or recover once the outcome looks uncertain.

The surrounding system is what actually determines whether an agent is useful: permissions, state tracking, APIs, local model runtimes, user control, verification. None of that shows up in a demo, but all of it decides whether the thing works. Read the KHS AI case study for the architecture, limits and testing questions, or open the broader AI and development page for the surrounding vocabulary.

Open the work behind the summary.

Start with the projects page for a guided route through KHS AI, home-lab infrastructure, networking and the public Tools Lab. Each path points to the level of detail that makes the implementation understandable.

Open something real.

These links lead to active projects and interfaces, not another repetition of the category list.