How OE6VAG.NET Is Hosted
Self-hosted web infrastructure for a website that is also a live radio-data platform.
OE6VAG.NET runs on a small server at home, but the website itself is only one part of the system. In addition to the Ghost CMS, the platform publishes live data from several radio receivers, maps, decoded weather and satellite data, ADS-B traffic, radiosondes, FT8 reception, C-ITS test drives and a local radio archive.
The result is a small distributed system: dedicated receivers collect and decode data, several Raspberry Pis and an SDR server process it, and a central Intel N100 server publishes the results on oe6vag.net.
Core Web Server
The central system is an Intel N100 Mini PC running Ubuntu Server 24.04 LTS. It acts as the web server, data hub and storage gateway for the public site.
The main web stack consists of:
- Caddy as the HTTPS server and reverse proxy
- Ghost 5 as the content management system
- MySQL 8 as the Ghost database
- Docker for the main application services
- Mosquitto for MQTT
- small local APIs and publishing services for live receiver data
Ghost and MySQL run in Docker containers. Caddy runs directly on the host and is the central entry point for web requests.
Routing and HTTPS
The Internet connection uses a dynamically assigned public IP address. A Cloudflare DDNS container keeps the DNS record up to date whenever that address changes.
Incoming HTTPS traffic is forwarded by the home router to Ubuntu server. Caddy then decides where each request belongs.
Normal pages are forwarded to Ghost, while live-data applications and files are served from separate local directories or proxied to their respective backends. This makes it possible to combine a conventional CMS with independently generated radio-data pages under one domain.
A separate Cloudflare Tunnel is used for remote SSH access through ssh.oe6vag.net. The tunnel is not used for normal website traffic.
Live Radio and Sensor Data
The interesting part of the setup is that the web server is connected to several independent receiver systems.
HF SDR Server
A second Intel N100 Mini PC runs an SDRplay RSPdx with KA9Q Radio.
The RSPdx produces one wideband IQ stream from which several virtual receivers are generated in parallel. At the moment this is used for:
- HFDL
- DWD RTTY / SYNOP
- FT8 on 30 m
- WEFAX as an experimental service
The decoded results are transferred to Ubuntu server and published on the website.
Raspberry Pi Radio Server
A Raspberry Pi 3B+ still operates several dedicated receivers:
- ADS-B with readsb and tar1090
- METEOR-M2-4 weather-satellite reception
- Inmarsat STD-C / SafetyNET / EGC
Some data is copied to the web server as static content; tar1090 is made available through a reverse proxy.
DCF77
A Raspberry Pi Zero 2 W receives and decodes DCF77 on 77.5 kHz. Its current status is pushed to the web server every few seconds and displayed on the DCF77 page.
Radiosondes
A separate rdzTTGOsonde receiver tracks weather balloons. In addition to feeding SondeHub and radiosondy.info, it publishes received packets by MQTT to the local server.
The packets are stored in a SQLite database and made available through a small API and a local web map.
C-ITS
For C-ITS experiments, a mobile receiver obtains messages through OpenTrafficMap during test drives. GPS data from an iPhone running OwnTracks is correlated with the received messages.
Completed trips are processed automatically and published as web pages and maps.
TinyGS
A separate 868 MHz TinyGS receiver operates as station OE6VAG_2. TinyGS uses its own cloud backend, so the website links to or embeds the station information rather than processing TinyGS packets locally.
Public Services
Besides the normal Ghost pages, the server currently publishes several live or automatically generated sections:
/hfdl/— HFDL aircraft reception/sondes/— radiosonde map/dcf77/— DCF77 live status/meteor/— METEOR-M2-4 images/dwd-rtty/— DWD RTTY and SYNOP/stdc/— Inmarsat STD-C / EGC/tar1090/— ADS-B traffic/cits/— C-ITS test drives/ft8/— FT8 reception on 30 m/downloads/— radio archive
This separation is intentional: Ghost handles editorial content, while Caddy also publishes independent live-data applications under the same domain.
MQTT and Local APIs
MQTT is used as an internal transport for several data sources.
The Mosquitto broker on Ubunrtu server receives, among other things, radiosonde packets and GPS information from OwnTracks. Small local services store, normalize or convert that data before selected results are exposed on the public website.
The MQTT broker itself is separate from the normal web path.
Storage and Radio Archive
The web server also has a separate local archive disk. It contains radio-related material such as books, magazines, schematics, historical documents, tools and downloads.
Selected files are published through the /downloads/ section of the website.
Backup
The important server data is backed up automatically once per day to a separate NAS on the local network.
The backup includes the Ghost content and database, relevant Docker data, Caddy configuration, MQTT data, radiosonde data and selected system configuration. The SDR server has its own scheduled backup as well.
Keeping the backup on a separate system means that a failure of the web server does not automatically destroy the backup copy.
Why Self-Host?
The main reason is experimentation.
A normal hosting package would be sufficient for a simple website, but OE6VAG.NET is also the presentation layer for a growing collection of radio and sensor projects. Self-hosting makes it possible to combine a CMS, reverse proxies, MQTT, APIs, SDR processing, maps, automatically generated pages and local storage without forcing everything into a conventional web-hosting model.
In simplified form, the architecture looks like this:
radio receivers and sensors → local decoding and processing → Ubuntu server → Caddy → oe6vag.net
The website is not just hosted at home — it is the visible front end of the radio infrastructure behind it.