Aeoncore - Technical Architecture Overview

In my previous posts, I shared the "Why" and the "What" behind Aeoncore, my self-hosted AI and services platform. Today, I’m pulling back the curtain on the "How."

When designing a platform – even a personal one – the architecture is a statement of intent. For Aeoncore, my goal wasn’t just to make something that works, I wanted to build a system that mirrored production-grade standards: isolated, observable, secure, and – most importantly – extensible.

Aeoncore currently runs on a single physical node – an Intel i9 workstation with an RTX 3090 GPU, 128GB of system RAM, and mixed NVMe/HDD storage – acting as a compact but powerful home datacenter.

The Foundation: A Hypervisor-First Strategy

I chose to install a hypervisor on the physical hardware and split the work between several virtual machines.

The Rationale: Service isolation. By separating roles into distinct Virtual Machines (VMs), the system becomes much easier to manage now while also being more flexible as needs evolve.

• I can allocate the physical hardware resources to individual VMs. For example, with an 8-core CPU, I can allocate 2 cores to one machine, 2 to another, and 4 for a third. If one VM's needs grow, I can reallocate those fairly easily.
• I can directly pass-through key hardware resources to a specific VM. This ensures the services that require that hardware have direct control of it.
• If the platform needs to grow, and I later add another physical server, I can completely migrate a VM from one host to another, or connect multiple hosts into a cluster for high availability and failover.
• I went with Proxmox as my flavor of hypervisor for a few reasons. It's Linux-based, and all my VMs are too. It also has the native ability to run containers if I need something run at the host level. And crucially, it's free and open-source, and has strong support and documentation from the community.

We’ve partitioned the system into three specialized functional zones:

• Sirius: This is the jack-of-all-trades machine. It's a Linux (Ubuntu LTS) VM that handles most of my general services. These generally fall into a few key categories: network services (Tailscale, Nginx Proxy Manager, DNS, and PiHole), monitoring services (Beszel, Uptime Kuma), platform and container services (Dockge, Dozzle, Kopia), and some user services (Homepage, Linkwarden).
• Vega: This is the main storage vault. It's a TrueNAS SCALE VM with direct hardware passthrough of the physical HDDs. This enables me to put hard drives into a proper ZFS mirror array, provides a shared storage location for the platform's other services, and also operates as a private cloud for user storage with sync agents on PC and mobile.
• Deneb: This is the main AI machine. Like Sirius, it's a base Linux VM, but it has dedicated pass-through of the RTX 3090 GPU, giving it full and exclusive control of the graphics card. In addition, it has twice the CPU cores and six times the system RAM of either of its VM peers. This gives it plenty of overhead to do some serious thinking, whether that's text inference with Ollama/OpenWebUI, or image generation with Stable Diffusion and ComfyUI.

Containers & Orchestration: Complexity vs. Utility

I chose to run containerized services whenever possible.

The Rationale: Containers provide flexibility for applications in the same way VMs provide flexibility for operating systems. By running apps and services as containers, it's easier to manage and standardize.

• Docker Compose vs. Kubernetes. Choosing the right tool for the current scale is as important as planning for the next one. While Kubernetes has a lot of pros, for a single-node setup like mine, Kubernetes adds complexity without providing immediate ROI. Docker Compose allows for rapid deployment, easy rollbacks, and clear versioning of service images pulled from public registries.
• I can standardize my configuration files, easily spin up additional services, and manage the whole stack via container managers.

Networking & Security: Zero-Trust by Design

I chose to not expose Aeoncore services publicly, keeping all systems "internal."

The Rationale: I'm not a security or networking expert, and I wanted to minimize my risk profile by limiting any available attack surface exposed to the internet.

• Aeoncore takes a zero-trust approach using Tailscale. All user-facing services (like tau.aeoncore.net) resolve to internal Mesh VPN IPs. I have zero public-facing endpoints.
• I have remote access to my entire platform (AI, services, even administer it) from anywhere in the world, as long as I'm using one of my devices.
• This also simplifies user authentication, because access to the network itself requires device-level authentication through Tailscale. If a device can route to the platform, it’s already been authenticated and approved.

Platform Reliability: Operational Discipline

I chose to implement observability and backup systems before I even began to work on the AI services.

The Rationale: I didn't want to invest time and energy building user-facing services before I was sure of my foundations. Establishing monitoring and backups were first-order priorities.

• For monitoring, I implemented Beszel on both VMs and the hypervisor itself to keep an eye on both hardware and virtual resource utilization, while Uptime Kuma keeps tabs on my service availability.
• For backups, I configured automated Proxmox snapshots, as well as configured Kopia to keep regular copies of my app configurations. In the event of a failure, I can roll back to a previous snapshot quickly.

The AI Application Layer

I chose to build out my AI stack last, and to behave similarly to the chatbots most people already use to interact with AI.

The Rationale: Those platforms work for a reason, they're intuitive and simple for people to use.

• Tau: My text inference or large language model (LLM) platform is based on an Ollama back-end with an Open WebUI front-end. Ollama is great for maintaining different models, especially customizing existing ones, and pulling new ones. Open WebUI will be incredibly familiar to anyone who's ever used an existing LLM like ChatGPT.
• Ceti: My image generation platform is based on a Stable Diffusion architecture with a ComfyUI interface layered on top. I have multiple checkpoint models to choose from, and as a "power user" interface, it gives access to a high degree of customization with how your art is generated.

Right now, these are fairly basic systems, and that's by design. The platform is still in 1.0 or "MVP" state, with many of the customizations deferred until I could get that basic functionality working. However, the product roadmap does include additional services that will come online soon:

• Tau → Ceti Integration: I want users to be able to describe an image with an LLM, and have that image get generated in the same UI. This will be instantly recognizable to anyone who has used ChatGPT/DALL-E or Gemini/NanoBanana.
• Agentic Orchestration: Right now, the AI is only able to respond when you give it prompts, which means the platform is sitting idle the majority of the time. I'm building some n8n workflows that will make better use of that idle computing time to help me with various projects.

Why This Architecture Matters

To a non-technical person, I know that this stack represents a jargon soup of modern tech: Proxmox, Docker, Tailscale. Words that don't necessarily mean much to you except as "names of tech you don't understand well." If you're still reading, I hope I've given enough context to help you make sense of it all.

To a technical manager or engineer, I hope this displays sensible judgment in platform architecture. I didn't just build a server and start installing software; I planned and built a platform to act as the canvas for me to draw upon, that's stable enough to satisfy current needs while remaining flexible for future ones.

To an executive or PM, I'm hoping this shows product thinking and systems design. This isn't a hodgepodge of services, it's a collection of tools that are designed to work together to do things real users will want to be able to do. As a single-user platform, that's easy, but I'm also implementing this for my family to use as well, which means I have distinct user personas I need to satisfy.

1.0 Is Just The Beginning

The roadmap is already in motion. The journey from 0 to 1 has been significant, and I'm pleased with the result, but a real platform will grow and evolve, and Aeoncore is no different. I'll talk about the full product roadmap in the near future, but planned items include improvements to the platform itself as well as new user services.

Aeoncore proves that with the right architectural intent, you don't need a data center to build something world-class.

You just need discipline, time, and a sensible plan.