Project
Afterlab
A self-hosted personal lab that connects infrastructure, physical devices, telemetry and AI into a single evolving system.
Active development
- Type
- Personal lab / AI & automation platform
- Context
- Personal project
- Duration
- 2026-Ongoing
The brief
A connected environment for building, testing and understanding systems
Afterlab is my personal experimental computing environment: a self-hosted system where software, physical devices, telemetry and AI can work together instead of living as isolated projects.
It started as a home lab, but gradually became something closer to a small operating layer for my own environment. A MiniPC runs the core services, ESP32 devices provide physical inputs and outputs, MQTT connects the different components, and Pixel acts as the intelligent interface on top of them.
It is built for one operator. There is no sign-up, no multi-tenancy and no public surface beyond the private web panel.
The project is deliberately modular. Infrastructure monitoring, device state, knowledge, automation, physical interfaces and AI capabilities can evolve independently while still sharing the same underlying system.
Purpose
Why build another platform?
I wanted a place where I could explore what happens when a home lab becomes more than a collection of Docker containers.
Most monitoring systems are designed to tell you whether a server is online. Afterlab is interested in a wider question: can a personal computing environment understand its own state, remember what has happened, interact with physical space and expose all of that through a useful AI interface?
That means combining things that are normally separate: infrastructure monitoring, embedded devices, automation, project context, local AI, interfaces and experimentation.
The result is less about building a traditional smart home and more about creating a personal technological environment that can gradually become observable, contextual and interactive.
In numbers
The project at a glance
Firmware devices on the network
Commits in two months
Project memory freshness window
Agent automated tests
System
One system, multiple layers
At the centre of Afterlab is a self-hosted MiniPC running the core services in Docker.
A FastAPI Agent is the operational authority. It sits between infrastructure, stored state and physical devices, owns every write and never runs arbitrary shell commands or changes Docker. Supabase provides authentication and persistent application data, while Mosquitto provides the MQTT backbone used by the hardware nodes.
Devices such as the Pixel CrowPanel, Afterlab ADV and the ESP32 sensor nodes publish their own state and consume information from the wider system. Personal computers and the ADV use a paired device token instead of the web login.
The web panel runs separately on Hetzner and never talks to the MiniPC directly. Two independent gates protect the way in: Cloudflare Access only admits the web server, with a token the browser never sees, and the Agent then checks that the user is me.
Mission Control provides the operational view of the lab: runtime state, services, API traffic and attention items. Host data such as CPU, RAM, disk usage and temperature is sampled every five minutes and kept for 90 days, so it can be read as history rather than only as a live snapshot.
When Pixel answers a question about the lab, deterministic reads come first. Simple questions are answered by a single tool, and questions that mix the current state with history are composed from two or three closed reads. An experimental planner only steps in after that, and the model's numbers can never replace the facts the Agent has verified.
The important part is that these are not standalone demos. They all speak through a shared architecture and are designed to become more useful as the system gains context.
Architecture
System map
Outcome
Where it stands
Afterlab is now a functioning platform rather than a collection of disconnected prototypes.
The core infrastructure is deployed, MQTT communication between the Agent and physical devices is operational, Mission Control exposes live system state, and historical host telemetry is being stored for longer-term analysis.
Pixel can already access several operational sources inside the system, while project memory, activity history and device state provide the foundations for increasingly contextual behaviour.
The project is intentionally never completely finished. Each new device or experiment becomes another opportunity to test how much useful context the system can collect, connect and expose without turning the architecture into a monolith.
Gallery
Selected work
A closer look at the screens, details and the build in context. Open any image to see it full size.
Highlights
What it does
Afterlab is built as a collection of interoperable layers. Each one can be useful on its own, but the interesting behaviour appears when they begin sharing state and context.
-
Self-hosted core
Docker-based infrastructure running the services that support the lab
-
Mission Control
A dedicated operational interface for system state, runtimes and telemetry
-
Pixel
The intelligent layer that answers from verified lab data before using a model
-
Physical nodes
ESP32-based devices connect the software system to the surrounding environment
-
MQTT backbone
A common event and state layer shared by embedded hardware and the Agent
-
Project Memory
Persistent project context designed to survive individual conversations
-
Knowledge Vault
A structured space for ideas, concepts, notes and long-term context
-
Historical telemetry
System health can be analysed over time instead of only observed live
-
Two independent gates
Cloudflare Access checks the machine, the Agent checks the user
Evolution
How it grew
The key milestones, from the first idea to where the project stands today.
-
Aug 2026
Connected foundation
Core services, Agent, Telegram and MQTT begin operating as one system
-
Aug–Sep 2026
Physical layer
ESP32 nodes, AfterDeck, ADV, CrowPanel and the Fedora desktop join the ecosystem
-
Sep 2026
Persistent context
Knowledge Vault and Project Memory add long-lived contextual state
-
Sep 2026
Mission Control
Runtime state, devices and operational telemetry gain a dedicated interface
-
Oct 2026
Historical telemetry
CPU, RAM, temperature and disk data begin being stored and queried over time
-
Oct 2026
Pixel planning
Deterministic composition and an experimental planner decide which sources answer each question
Technical foundation
Tools & stack
AI & Models
- ElevenLabs
- Ollama
- OpenAI
Backend
- Python
Backend API
- FastAPI
Database
- Supabase
Device Messaging
- MQTT
Embedded Hardware
- ESP32
Frontend
- TypeScript
Hardware
- Adafruit
- Arduino
- Raspberry Pi
Infrastructure
- Docker
- Fedora
Web Design
- React
Web Development
- WordPress
Next
What comes next
The next stage is less about adding more isolated features and more about improving how the existing information is connected.
Historical telemetry can help Pixel distinguish temporary events from meaningful changes. Device state can become contextual rather than simply online or offline. Activity history can help explain what has happened recently, while project memory can provide longer-term intent.
The long-term direction is an environment where Pixel does not simply answer questions about Afterlab, but can understand enough of its current and historical state to surface useful information proactively and choose the appropriate tools when needed.