Case Study – Aeoncore Personal AI/Services Platform

Overview

Aeoncore is a self-hosted, end-to-end AI and services platform, designed and built from the ground up as a solo project during a professional development period in 2025–2026. The platform delivers local AI inference, private cloud storage, network services, and containerized infrastructure – all running on a single physical node, managed entirely by one person, and operated to production-equivalent standards.

It was not built for commercial deployment. It was built to answer a question: what does it look like when someone applies real production discipline to a personal project, without a team, without a budget, and without the option to buy their way out of hard problems?

The answer is Aeoncore.

Context & Motivation

The Catalyst

The project originated from an opportunistic hardware situation. A high-end gaming workstation – Intel i9, 128GB RAM, mixed NVMe/HDD storage, and an NVIDIA RTX 3090 – had become available and was sitting largely idle. The RTX 3090 was the pivotal component. While four years old and two GPU generations behind the current market, its 24GB VRAM capacity occupies a meaningful sweet spot in the modern AI hardware economy: large enough to keep sizable open-weight models resident entirely on-card, which is orders of magnitude faster than offloading into system RAM. A machine that predated the AI era turned out to be well-suited for it.

At roughly the same time, the landscape for open-weight models had crossed a usability threshold. Tools like Ollama had made local model management genuinely accessible. Frameworks like Stable Diffusion had matured. What had previously required enterprise infrastructure – or a cloud vendor's billing account – could now run on well-configured consumer hardware. Building a legitimate local AI platform stopped being theoretical.

The Professional Rationale

Having the hardware removed the capital barrier. What remained was the design and execution challenge, which is where the professional value of the project actually lives.

The build served three simultaneous goals. First, it provided a forcing function for hands-on learning across a technology stack – hypervisors, containerization, networking, AI tooling – that could not be learned as effectively any other way. Reading documentation is not the same as being responsible for an operational system. Second, it produced a tangible artifact: something demonstrable, explainable, and improvable, rather than another theoretical exercise. Third, it delivered genuine utility. The platform had to become part of daily workflows for it to be worth building. A portfolio project that no one actually uses is not evidence of operational discipline.

The Ownership Thesis

Underneath the practical rationale was a more fundamental conviction. When you rely entirely on cloud services, you consume an experience someone else designed. You accept their constraints, their pricing model, their roadmap decisions, and their architectural tradeoffs. Building and operating your own platform forces a different posture – one that requires you to understand the full stack, own the consequences of every decision, and design around real constraints rather than someone else's defaults.

If you want to truly own the experience, you probably need to own the platform.

What began as an experiment in capability became an exercise in ownership.

Design Philosophy

Enterprise Standards at Personal Scale

The guiding principle throughout the design and build was: enterprise-grade discipline, implemented at personal scale. This was a deliberate choice, not an aspiration. It shaped every architectural decision, from the initial choice to use a hypervisor rather than a bare-metal install, to the decision to implement monitoring and backups before touching the AI services.

The easiest version of this project would have been a monolithic install: Linux, Docker, Ollama, done. That approach works for a hobbyist. It is brittle, difficult to reason about, hard to scale, and expensive to change. It produces a running system, not an operational platform. The difference matters.

Constraint as Design Variable

Aeoncore was built under a hard constraint: the project budget was effectively zero. No additional hardware purchases. No software licensing. No paid services beyond the electricity bill. Every design decision had to work within what existed.

This constraint was not treated as a limitation so much as a parameter to design within – exactly the kind of parameter that governs real production environments, where budget ceilings are real and the question is never "can we buy our way to a better solution?" but "what is the best architecture given what we have?"

The most significant constraint was power. The existing power supply unit barely supports the RTX 3090 at full load. This means the GPU cannot be joined by a second card without a power supply replacement – a ceiling that caps the compute expansion path and shapes the architectural roadmap accordingly. Acknowledged as technical debt, this constraint is documented and has a known mitigation path: a PSU upgrade when budget allows restores the expansion option. In the meantime, the architecture is designed to maximize the single-GPU configuration, with VRAM allocation managed carefully across workloads.

There is a secondary operational consequence worth noting transparently: because the GPU is allocated exclusively to the Deneb VM at the hypervisor level, local physical management of Deneb during boot requires timing an intervention before GPU passthrough completes – a manual workaround for a constraint that remote management cannot fully address. It is not elegant. It is documented, understood, and stable.

Modularity as Risk Mitigation

Given a $0 budget, the ability to re-architect without re-purchasing was not optional – it was the only available risk mitigation strategy. The platform was therefore designed for modularity from the start: discrete virtual machines for discrete functional roles, containerized services within each VM, and clean interfaces between layers.

This design choice proved its value repeatedly. When the understanding of a subsystem deepened and its configuration needed revision, the change could be scoped to the relevant VM or container without cascading disruption to the rest of the stack. When a networking decision turned out to be wrong, it could be corrected at the network layer without touching the AI services. The modularity was not premature optimization – it was structural resilience against a known pattern of iterative learning.

Architecture

The Physical Node

Aeoncore runs on a single workstation chassis acting as a compact home datacenter:

CPU: Intel i9 (multi-core)

RAM: 128GB system memory

GPU: NVIDIA RTX 3090 (24GB VRAM)

Storage: Mixed NVMe (primary) and HDD (bulk/NAS)

Network: Internal LAN with zero public-facing exposure

The Hypervisor Layer

Proxmox VE was selected as the hypervisor for several reasons: open-source licensing (no cost), strong community documentation, native Linux compatibility, built-in LXC container support alongside full VM management, and the ability to support multi-node clustering if a second physical machine is added in the future.

The decision to run a hypervisor rather than a direct install was deliberate. Service isolation at the VM level allows resource allocation to be adjusted, workloads to be migrated between hosts, and individual VMs to be snapshotted and restored independently. It is the difference between a house built to code and one that was not – the former can be added to; the latter has to be torn down.

The Functional Zones

The platform is partitioned into three specialized virtual machines, each with a defined role:

Sirius is the general services VM, running on Ubuntu LTS. It handles network infrastructure (Tailscale mesh VPN, Nginx Proxy Manager, DNS, Pi-hole ad blocking), platform monitoring (Beszel, Uptime Kuma), container management (Dockge, Dozzle), backup orchestration (Kopia), and user-facing utility services (a unified homepage portal, Linkwarden).

Vega is the storage VM, running TrueNAS SCALE with direct hardware passthrough of the physical HDDs. This enables a proper ZFS mirror array for data integrity, provides a shared network storage location accessible by the platform's other services, and operates as a private cloud for user devices – with sync clients on desktop and mobile – without a single byte of data leaving the local network.

Deneb is the AI compute VM, running a base Linux environment with exclusive GPU passthrough of the RTX 3090. It carries twice the CPU allocation and six times the RAM of its peer VMs, and runs the full AI service stack: Ollama and Open WebUI for text inference (the "Tau" front-end), and Stable Diffusion with ComfyUI for image generation (the "Ceti" front-end).

Networking & Security

All user-facing services are internal only – there are no public-facing endpoints. Remote access is handled exclusively through Tailscale, a zero-trust mesh VPN that authenticates at the device level. Access to the network IS authentication; if a device can route to the platform, it has already been verified. This approach was chosen deliberately to minimize attack surface – not from a position of networking expertise, but from a position of honest risk assessment. The platform is most secure when the default posture is closed.

Containers & Orchestration

Services within each VM run as Docker containers managed via Docker Compose. Kubernetes was evaluated and rejected: for a single-node configuration, it adds architectural complexity with no immediate operational return. Docker Compose provides rapid deployment, clean versioning of service configurations, easy rollbacks through image pinning, and the ability to spin up new services in minutes rather than hours.

Build Execution

Sequencing the Build

The project was built in deliberate phases, each validating a layer before the next was introduced:

The first phase established the bare-metal foundation: hardware assembly, Proxmox installation, initial VM configuration. Nothing ran on it yet. The foundation had to be stable before anything was built on top of it.

The second phase stood up Sirius and the general service stack – monitoring, networking, container infrastructure, backups. The explicit decision was made to get observability and backup systems operational before building any user-facing services. This is production thinking: you do not build on a foundation you cannot see and cannot recover from.

The third phase added storage. Hard drives were added to the chassis, Vega was provisioned with TrueNAS, ZFS was configured, and the private cloud sync was established. Shared storage became available to the rest of the platform.

The fourth phase provisioned Deneb – allocating the GPU, building out the AI service stack, and bringing Tau and Ceti online. By the time AI services were being configured, the platform beneath them was already stable, observable, and backed up.

The Reality of Iterative Learning

The build process was iterative, reflective of what happens when a practitioner is learning a technology stack while simultaneously architecting and operating it.

The overhead cost of this approach was real. Planning and principal build occurred before agentic AI tooling had reached the capability level where it could maintain coherent architectural context across a multi-layer system build. That context had to be maintained at the human level: in documentation, in design notes, in a mental model that had to stay current with each change to the underlying stack. It was a meaningful cognitive load, and it produced a genuine appreciation for what that kind of tooling – when it matures – will change about solo infrastructure work.

The Docker Compose configurations were the most frequent site of iteration. Each new service layer had to be integrated with the existing compose files, and each integration surfaced new dependencies or conflicts that required adjustment. The Deneb AI stack was particularly involved: Ollama, Open WebUI, and the Stable Diffusion layer needed to see each other and share GPU resources without over-allocating VRAM. Configuring SDXL to release the GPU when idle – rather than holding VRAM permanently – required understanding the resource lifecycle at a level the initial configuration had not accounted for. The models, once configured correctly, coexist cleanly. Getting there required several iterations.

The backup configuration provided the clearest example of the find-and-fix pattern. The initial setup backed up VM data to the NAS – sensible in concept. What it actually did was attempt to back up the NAS's own operating data to itself: a circular configuration that produced no useful backups and, worse, created a false sense of coverage. The failure was not immediately visible because the process completed without obvious errors. It surfaced during a configuration audit. The correct approach – backing up VM snapshots through Proxmox directly, with NAS data handled separately through ZFS native snapshots – was implemented, tested, and has been stable for months. The lesson was not that mistakes happen; it was that backup configurations require validation, not just completion. A backup you have not tested is not a backup.

Other iterations were less dramatic but equally characteristic: CPU and RAM reallocations between VMs as actual utilization patterns became clear, IP addressing and DNS namespace adjustments as the internal service map grew, authentication and permissions tuning as the user base expanded beyond a single person.

In a production environment with SLA obligations, this rate of change would require change management processes to control risk. Aeoncore's operating context – no SLA guarantees, no external dependencies – allowed the iteration to be aggressive. The platform was designed to tolerate it. That is not an excuse for the changes; it is the reason the modular architecture was worth building in the first place.

Current State & Operational Status

What 1.0 Delivered

Aeoncore 1.0 is operational. The core platform services – monitoring, networking, backup, storage – run without active management. The NAS and private cloud sync are used daily. The AI services are available on demand for research, experimentation, and workflow development.

The AI services are not in heavy daily use. This is worth stating directly, because the honest accounting of what a personal AI platform delivers matters more than the theoretical accounting. What the platform provides is readiness: the ability to run a local model, test a new capability, prototype an agentic workflow, or evaluate a new tool without spinning up a cloud account, writing a check, or waiting for provisioning. The marginal cost of experimentation is near zero. That changes what experimentation is possible.

The 2.0 Roadmap

The 2.0 roadmap is documented and partially in progress, with execution gated primarily on budget constraints that remain unresolved. Planned features include the Tau/Ceti unified pipeline (natural language image generation without leaving the chat interface), autonomous web search with citation (moving from static inference to a dynamic research partner), Obsidian knowledge base integration via local RAG (turning private notes into a searchable AI-backed resource), and a dedicated Proxmox Backup Server node for off-primary resilience.

Several of these features require modest capital expenditure – hardware for the backup node, specifically – that is deferred until the professional employment situation resolves. Program-level planning has continued in the interim. The platform is designed to receive these capabilities without re-architecting the core; the 1.0 architecture was built with 2.0 in mind.

What This Demonstrates

Production Discipline Transfers

The argument Aeoncore makes is not that building a home server is impressive. Plenty of people build home servers. The argument is that the discipline applied here – hypervisor-first architecture, service isolation, observability before services, modular design, documented iteration – is the same discipline that governs production infrastructure decisions, because it is production infrastructure discipline, applied at a different scale.

The scale is personal. The standards are not.

A platform built this way can be explained to an engineer, evaluated by an architect, and operated by a practitioner. It was designed with all three audiences in mind, because the person building it was wearing all three hats simultaneously.

Full-Stack Ownership

Program and product management roles frequently create distance from the implementation layer. That distance has costs. A program manager who cannot read an architecture diagram cannot evaluate whether the architecture serves the program. A product manager who has never operated a production service does not fully understand what "operational overhead" means when an engineering team raises it as a concern.

Aeoncore closed that distance deliberately. Every decision in the stack – from hypervisor selection to VRAM allocation strategy to backup configuration validation – was made, owned, and corrected by the same person. There is no part of this platform that someone else built and this author simply managed.

That is a professional posture, not a technical credential. The specific technologies will change. The posture does not.

The Platform as Capability

The final argument is forward-looking. Aeoncore exists not just as a completed project but as a standing capability – a platform that makes future experimentation fast and future proof-of-concept work low-friction. New models can be evaluated in hours. New agentic workflows can be prototyped against real infrastructure. New integrations can be tested without cloud accounts or API costs.

The value of building the platform is not only what it has already done. It is what it makes possible to try next.

Aeoncore is a living platform. This document reflects its state as of May 2026.