Caius' Experiments

Why I Self Host

Caius Brindescu — Sat, 28 Mar 2026 00:00:00 +0000

I have been running my own servers, on and off since college. They have been a great experimentation platform, and given me resources to tap into for my professional life. It wasn't always smooth sailing, but here's some of my takes, and why it's always been worth the hassle, at least for me.</p>

A short history
The early days
Later on during grad school, I had to setup the research group server 1</a></sup>. Using DynDNS</a>2</a></sup>, it was publicly accessible. That worked fine for a while, until a vulnerable Apache module turned it into a spam bot. I only found out when I got an annoyed email from a sysadmin in Bucharest, Romania, that it was spamming their network. Took it down for the day, cleaned it up, and made a note to apply patches more often in the future.</p>
Today
Currently, I am running a Pi Cluster with 4 Raspberry Pi 4 Nodes, with 4 GB each, running K3s</a>. While not a very powerful cluster, and only using SD Card for storage, it's enough to serve a static website, grafana, prometheus, and any random experiments. I also have a 1 node Framework Desktop that will run more "critical" systems, like a Postgres database for services that need it.</p>
Why?
Learning #</span></a> </h2>
This has been the primary reason for this. The Pi Cluster in particular was a great learning experience. Testing a repeatable Ansible set of playbooks, getting K3S to work and deploying a few services using both plain Kubernetes templates and Helm is not something I get to do in my day job.</p>
I find that I learn best when working on something practical. This is true from programming languages to infrastructure and networking. Having a "disposable" setup makes this a lot easier when learning.</p>
Enshittification
It's an unfortunate reality of today's world. Free services get more restrictive, open source alternatives get yanked 3</a></sup>, or the prices get constantly increased, with "AI" as the excuse 4</a></sup>.</p>
Having your own services protects from this reality, and you don't need to worry as much about increased costs, lost access, etc.</p>
Private access
From the grad school days, I've learned to be wary when exposing anything over the internet. To this end, the cluster is currently private and I access it from anywhere using Tailscale. The free tier 5</a></sup> is enough for me and my partner, and we can access the services from anywhere. Of course, locally we can always use the local network.</p>
Using Cert Manager</a>, I have publicly valid certificates and DNS that points to the Tailscale IP address of a node in the cluster. This works great, and we don't get any annoying browser warnings. Making everything public is only a matter of updating the DNS records.</p>
Your data, your rules
The downsides
Reliability
Data safety
If anything were to happen to the hardware, well, the data is gone. That is solved by having automatic backups to S3 6</a></sup>, and having a good 3-2-1 backup policy</a> is critical.</p>
Also, test your backups regularly. You don't want to find that your backups are broken when you really need them.</p>
Cost
In particular, the upfront costs of getting the hardware. This is only getting more expensive these days 7</a></sup>. However, if you've got some old hardware lying around, or go the used option, it's going to be less of a concern.</p>
Security #</span></a> </h2>
If the spambot incident taught me anything, it's that if it's open to the internet it's a target. Data leaks could be more serious if it has private data, and you're the only one in charge and responsible for securing it. Keeping up to date with patches becomes even more critical the more sensitive the stored data. A solution like Tailscale sidesteps the issue by keeping everything private.</p>
Conclusion
Footnotes
^{1</sup>
In our living room, because the university policies for a "hard-wired" server were beyond draconian, and made the hardware useless for the research we were doing</p>
</div>}
^{2</sup>
It was free in those days</p>
</div>}
^3</sup>
Minio archiving their open source repo</a></p> </div>
^4</sup>
Google Workspace price increase due to new AI features</a></p> </div>
^5</sup>
I am aware that this could enshittify in the future. However, Headscale</a> is an option, so I'm confident there's an offramp if I need it</p> </div>
^{6</sup>
For data durability, I haven't found anything that beats S3, or other key store offerings by a large cloud vendor.</p>
</div>}
^7</sup>
RAM price hikes</a></p> </div>

Self Hosted Postgres in Kubernetes with PITR Recovery

Caius Brindescu — Wed, 31 Dec 2025 00:00:00 +0000

Introduction #</span></a> </h1>

I would like to selfhost a few services, and they require persistence, in the form of a PostgreSQL database. Since my Kubernetes cluster runs on 4 Raspberry Pi 4, each with an SD card for disk, it's only a matter of time until one of them gets corrupted. To avoid the innevitable and predictable data loss, I'll need automated backups, idealy with Point-In-Time Recovery (PITR).</p>

If I'm going to reinvent the wheel, why not go for the whole wheel?</p>

Solution
CloudNativePG</a> seems to be most mature and feature complete out there. It provides an operator that does a lot of the heavy lifting. Backups are handled by the Barman Cloud</a> plugin. It handles aspects like WAL Log archiving, taking regular snapshots and uploading them a cloud object storage, like S3 1</a></sup>. Seems to meet all the needs I need for my project.</p>

Setup

Setting up a Cloud Native PG database

Using the instructions on their website</a>, we'll need to install the operator. We can do it with the following command:</p>

$</span> kubectl apply</span> --server-side -f</span> https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml</span></span></code></pre>
We can now create our database.
The Barman Cloud Plugin we'll be using later assumes that the DB is in the cnpg-system</code> namespace.
To simply this experiment, we'll work with that assumption, and we'll start by creating the namespace:</p>
$</span> kubectl create namespace cnpg-system</span></span></code></pre>
Then we can define our cluster configuration, with one user so we can connect to it later:</p>
apiVersion</span>:</span> v1</span></span>
type</span>:</span> kubernetes.io/basic-auth</span></span>
kind</span>:</span> Secret</span></span>
metadata</span>:</span></span>
  name</span>:</span> postgres-secret</span></span>
  namespace</span>:</span> cnpg-system</span></span>
stringData</span>:</span></span>
  username</span>:</span> user1</span></span>
  password</span>:</span> supersecretpassword</span></span>
---</span></span>
apiVersion</span>:</span> postgresql.cnpg.io/v1</span></span>
kind</span>:</span> Cluster</span></span>
metadata</span>:</span></span>
  name</span>:</span> test</span></span>
  namespace</span>:</span> cpgn-system</span></span>
spec</span>:</span></span>
  instances</span>:</span> 1</span></span>
  storage</span>:</span></span>
    size</span>:</span> 1Gi</span></span></code></pre>
And when we apply this, we have a new cluster with 1 instance.
We can forward the port, and connect to it like we normally would to a Postgres instance running locally.</p>
$</span> kubectl port-forward</span> -n</span> cnpg-system service/test-restore-rw 5432:5432</span></span></code></pre>Backups#</span></a>
</h2>
Installing#</span></a>
</h3>
Now, we can configure backups for our new Postgres cluster.</p>
First, let's install the prerequisites that the Barman Cloud plugin requires.
We will need to install Certificate Manager2</a></sup>.</p>
$</span> kubectl apply</span> -f</span> https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml</span></span></code></pre>
Then, we can install the plugin:</p>
$</span> kubectl apply</span> -f</span> https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/v0.9.0/manifest.yaml</span></span></code></pre>Configuration#</span></a>
</h3>
We can now define the backup configuration.
For this example, I'll use S3 as the storage target for the backups.</p>
First, we'll need to store a set AWS credentials with access to the right bucket3</a></sup>.
We'll use an Opaque Secret</a> to store the access and secret keys:</p>
apiVersion</span>:</span> v1</span></span>
kind</span>:</span> Secret</span></span>
metadata</span>:</span></span>
  name</span>:</span> s3-credentials</span></span>
  namespace</span>:</span> cnpg-system</span></span>
type</span>:</span> Opaque</span></span>
stringData</span>:</span></span>
  access-key-id</span>:</span> <redacted></span></span>
  secret-key-id</span>:</span> <redacted></span></span></code></pre>
Next, we'll define the storage configuration to our S3 Bucket:</p>
apiVersion</span>:</span> barmancloud.cnpg.io/v1</span></span>
kind</span>:</span> ObjectStore</span></span>
metadata</span>:</span></span>
  name</span>:</span> s3-store</span></span>
  namespace</span>:</span> cnpg-system</span></span>
spec</span>:</span></span>
  configuration</span>:</span></span>
    destinationPath</span>:</span> s3://<bucket>/postgres/</span></span>
    s3Credentials</span>:</span></span>
      accessKeyId</span>:</span></span>
        name</span>:</span> s3-credentials</span></span>
        key</span>:</span> access-key-id</span></span>
      secretAccessKey</span>:</span></span>
        name</span>:</span> s3-credentials</span></span>
        key</span>:</span> secret-key-id</span></span>
    wal</span>:</span></span>
      compression</span>:</span> gzip</span></span></code></pre>
Finally, we'll need to tell our Postgres cluster to use this configuration, and enable WAL archiving.
We'll add the following to the Cluster spec</code> field:</p>
plugins</span>:</span></span>
  -</span> name</span>:</span> barman-cloud.cloudnative-pg.io</span></span>
    isWALArchiver</span>:</span> true</span></span>
    parameters</span>:</span></span>
      barmanObjectName</span>:</span> s3-store</span></span></code></pre>
The final piece of the puzzle is setup regular "base" backups.
These will backup the entire dataset, and give us a "base" for the WAL logs to be applied to in order to get our Point-In-Time Restore.</p>
apiVersion</span>:</span> postgresql.cnpg.io/v1</span></span>
kind</span>:</span> ScheduledBackup</span></span>
metadata</span>:</span></span>
  name</span>:</span> pg-backup</span></span>
  namespace</span>:</span> cnpg-system</span></span>
spec</span>:</span></span>
  cluster</span>:</span></span>
    name</span>:</span> test</span></span>
  schedule</span>:</span> '0 0 * * * *'</span> # hourly</span></span>
  backupOwnerReference</span>:</span> self</span></span>
  method</span>:</span> plugin</span></span>
  pluginConfiguration</span>:</span></span>
    name</span>:</span> barman-cloud.cloudnative-pg.io</span></span></code></pre>Results#</span></a>
</h3>
Now that everything is configured, we can list our S3 bucket, and sure enough, we have backups.
The top level structure has our base and WAL logs:</p>
$ aws s3 ls s3://<redacted>/postgres/test/</span></span>
                           PRE base/</span></span>
                           PRE wals/</span></span></code></pre>
Digging in deeper, we have our base backups, nicely named by timestamp, one every hour, as we'd expect:</p>
$ aws s3 ls s3://<redacted>/postgres/test/base/</span></span>
                           PRE 20251227T030000/</span></span>
                           PRE 20251227T040000/</span></span>
                           PRE 20251227T050000/</span></span>
                           PRE 20251227T060000/</span></span>
                           PRE 20251227T070000/</span></span>
                           ...</span></span></code></pre>
And finally, we have our WAL logs archived:</p>
$ aws s3 ls s3://<redacted>/postgres/test/wals/0000000100000000/</span></span>
2025-12-26 21:00:02      16944 000000010000000000000013.gz</span></span>
2025-12-26 21:00:04        210 000000010000000000000014.00000028.backup.gz</span></span>
2025-12-26 21:00:03      16513 000000010000000000000014.gz</span></span>
2025-12-26 21:05:03      17139 000000010000000000000015.gz</span></span>
2025-12-26 21:30:03      17276 000000010000000000000016.gz</span></span>
2025-12-26 22:00:02      16416 000000010000000000000017.gz</span></span>
2025-12-26 22:00:05        209 000000010000000000000018.00000028.backup.gz</span></span>
2025-12-26 22:00:04      16510 000000010000000000000018.gz</span></span>
...</span></span></code></pre>
So we should have all the pieces needed to perform a PITR.
We'll tacke this in the next section.</p>
Restoring#</span></a>
</h2>
For testing the restore, I've created a simple table, with timestamps for easy reasoning:</p>
CREATE TABLE</span> test</span>(</span></span>
  id </span>int</span>,</span></span>
  created_at </span>timestamp</span>(</span>6</span>)</span></span>
);</span></span></code></pre>
And we inserted different values, and this is the end state of the table:</p>
test=> select * from test;</span></span>
 id |         created_at         </span></span>
----+----------------------------</span></span>
 16 | 2025-12-27 03:00:17.601392</span></span>
 17 | 2025-12-27 03:00:20.438822</span></span>
 18 | 2025-12-27 03:28:06.64914</span></span>
 19 | 2025-12-27 20:42:25.563207</span></span>
 20 | 2025-12-27 20:42:32.992066</span></span>
 21 | 2025-12-27 20:45:58.634257</span></span>
(6 rows)</span></span></code></pre>
We'll restore the table to 2025-12-27, at 20:43:00 UTC.
For this, we'll create a new cluster, and we'll point it at the backups we have.
We'll also need to give it the target time we want the cluster restored to.
We arrive at this configuration:</p>
apiVersion</span>:</span> postgresql.cnpg.io/v1</span></span>
kind</span>:</span> Cluster</span></span>
metadata</span>:</span></span>
  name</span>:</span> test-restore</span></span>
  namespace</span>:</span> cnpg-system</span></span>
spec</span>:</span></span>
  instances</span>:</span> 1</span></span>
  imagePullPolicy</span>:</span> IfNotPresent</span></span>
  bootstrap</span>:</span></span>
    recovery</span>:</span></span>
      source</span>:</span> source</span></span>
  externalClusters</span>:</span></span>
  -</span> name</span>:</span> source</span></span>
    plugin</span>:</span></span>
      name</span>:</span> barman-cloud.cloudnative-pg.io</span></span>
      parameters</span>:</span></span>
        barmanObjectName</span>:</span> s3-store</span></span>
        serverName</span>:</span> test</span></span>
        targetTime</span>:</span> "2025-12-27T20:43:00Z"</span></span>
  storage</span>:</span></span>
    size</span>:</span> 1Gi</span></span></code></pre>
Once the restore is done (it was pretty much instant for this example), we con connect and check our test table:</p>
test=> select * from test;</span></span>
 id |         created_at         </span></span>
----+----------------------------</span></span>
 16 | 2025-12-27 03:00:17.601392</span></span>
 17 | 2025-12-27 03:00:20.438822</span></span>
 18 | 2025-12-27 03:28:06.64914</span></span>
 19 | 2025-12-27 20:42:25.563207</span></span>
 20 | 2025-12-27 20:42:32.992066</span></span>
(5 rows)</span></span></code></pre>
As we'd expect, we're missing row with id</code> 21, as it's after</em> the target restore time.</p>
Conclusions and Final Remarks#</span></a>
</h1>
All in all, this was an easy setup, and it works fine for at least the basic use case.
The true test is once this sees some "production" loads, and testing with an actual live data base.</p>
A note on S3 cots#</span></a>
</h2>
For this example, I used S3 as the backup target destination.
The amount of data stored is small, however, WAL archiving could end up writing a lot of objects.
This could incur significant S3 API charges, so it's something I'm keeping an eye on.
With hourly base backups, I didn't see any cost increases for my AWS account.
But inserting 21 records, and deleting a few is not exactly a representative use case, but at least the "baseline" cost is not absurd.</p>
Retention policies#</span></a>
</h2>
Barman has the option of specifying retention policies</a>.
However, for this experiment, I've gone with specifying a lifecycle policy on the S3 bucket.
Everything under postgres/</code> will be deleted after 7 days.
This will give me a one week recovery window.</p>
Using the Barman retention policy will cause the plugin to list S3, and then delete the objects.
This also will incur some S3 API charges, and I think that using the S3 lifecycle rule is probably good enough.</p>
Footnotes#</span></a>
</h1>
^1</sup>The plugin also supports Google Cloud Storage, or Azure Blobs or some other services that implementation a compatible API</a>.</p>
</div>
^{2</sup>
You can skip this step if your cluster already has it installed on the cluster. My test cluster did not.</p>
</div>
^{3</sup>
For reference, I granted the user full access to the S3 bucket where the backups are stored.</p>
</div>}}



Setting up the DX Commander Expedition Antenna
Caius Brindescu — Mon, 21 Apr 2025 00:00:00 +0000
Recently I got a new DXCommander Expedition Antenna</a> for Parks on the Air (POTA) use.
After some experimentations, this week I decided to finish the tuning, and make a few contacts with it</p>
Initial thoughts#</span></a>
</h2>
It's a large antenna!
See in context with a large pine tree.</p>

It took a while to set up, with a couple of saw horses it's not too bad.
Having the antenna at a reasonble height avoids all be bending over to cut and measure things.
Once it was clear where everything went, and had the clamps trimmed to size, the assembly went smooth.</p>
I also tried tryting to extend the antenna while it's vertical.
I don't recomment this approach.
It doesn't work and it will come crashing down and "colapse" quite fast.</p>
The best option for deploying in the field is to lay it down, assemble everything, then walk it up.
It's light enough that it's easy to do with a single person.</p>
The good#</span></a>
</h2>
The tuning! 40 and 20 meters are spot on, with barely any noticeable movement of the SWR meter while transmitting.</p>
20 meters is well below 2.0 SWR across the entire band.

</p>
For 40 meters, the story is the same.

</p>
The 40 meters element ended up a lot longer than I expected.
So long, in fact, that I don't need any shockcord at the top.
It reaches the top of the pole, and I use the little clear platic tubing to hold the element in place.
A loop of shockcork keeps me from loosing the little plastic tube.</p>
I opted for a "perfect" 40 meter tune, and this probably lead to the long element, and the not so great 15 meter performance (more on that later).</p>
The OK#</span></a>
</h2>
Tuning the 10 meter band was a bit more finicky than I liked.
I was able to get it under 3.0 across the whole band, and I was able to use it fine without using the internal ATU of the radio.</p>
(Sorry, no image of the 10 meter turning.
I closed the software and didn't save the image, and I only realized this after the antenna was down.
I'm not going to stand it back up, in the rain, for one image.
You'll have to trust me on this one)</p>
The meh#</span></a>
</h2>
15 meters.
It's tuning is not great, see below.</p>

In practice, I get under 2.0 with the Icom 7300 (very brief testing).
It's usable without an ATU, and well within ATU limits if I'm using a radio that has one built in.</p>
It's possible the "overtunning" the 40 meter band got me worse performance here.
But it's a compromise I made on purpose.
I use 40 meters a lot more often than 15, and I'm happy with the overall result.</p>
Also, the elements are a bit loose than I'd like.
The tensioning loops ended up very close to the spreader plates.
This might be my error in assembly, but for future reference, having the loops a few inches down is OK, as there's pleny of shockcord to accomodate this.</p>
Conclusions#</span></a>
</h2>
It's a great antenna!</p>
It's larger than I expected.
But it did deliver the performance I was expecting.
It's now in the back of the truck, and I'm looking forward to trying out in the field on the next POTA activation!</p>


Decoding Meshtastic Channel Links
Caius Brindescu — Sat, 25 Jan 2025 00:00:00 +0000
Introduction#</span></a>
</h2>
If you don't know what Meshtastic is, this video has a great introduction</a>.
The TL;DR: is that it's a communication protocol using 900 MHz (in the US) LORA Radios</a>.</p>
Communication is done either via direct messages (DMs), or via channels.
The channels are encrypted, so for 2 parties to communicate, they need to know the encryption key (pre-shared key or PSK, for short) for that channel.
Sharing the chaneel name, key etc. is done via QR codes or URLs</a>.
In this blog post, we'll look at what information is encoded when sharing channel settings, and we can decode it using a "simple" Python script.</p>
The channel link#</span></a>
</h2>
We'll use the following link as an example:</p>
https://meshtastic.org/e/#CjQSIOsfCkgIpGY_8iW02ad-4QPaCSBISJqzIVoZKHdqKXd8GgtCbG9nQ2hhbm5lbCUEAAAAEg4IATgBQANIAVAeWBRoAQ</span></span></code></pre>
The part that we are interested in is the fragment:</p>
CjQSIOsfCkgIpGY_8iW02ad-4QPaCSBISJqzIVoZKHdqKXd8GgtCbG9nQ2hhbm5lbCUEAAAAEg4IATgBQANIAVAeWBRoAQ</span></span></code></pre>
This is a URL safe base64</a> encoded string that has the information we are looking for.</p>
Structure#</span></a>
</h2>
The message is encoded using protobuf</a>.
The structure we are interested in is defined in this file</a>.
It's reasonably well documented, so I will not get into all the details here.
But the main properties we are interested in are the channel name, and the PSK.
They are encoded as the psk</code> and name</code> properties in the top level ChannelSettings</code> message.</p>
For the rest of this post, we'll ignore the remainder of the properties, but they can be extracted using the same approach.</p>
Protobuf and Python#</span></a>
</h2>
Generating Python code from the protobuf structure#</span></a>
</h3>
The first setup is installing all the prerequisites.
There are 2 parts: the protobuf compiler and the Python protobuf library.</p>
sudo</span> apt install protobuf-compiler</span></span>
pip</span> install protobuf==</span>3.20.1</span></span></code></pre>

Note: I recommend using a virtual enviroment</a> for your python setup.
Here's a good resource for setting it up</a>.</p>
</blockquote>
Next, we'll need to get the protobuf definition "compiled" into python code, so we can the deserialize the configuration from the URL.
The protobuf definition lives in GitHub</a>, so we'll need to clone it.</p>
git</span> clone git@github.com:meshtastic/protobufs.git</span></span></code></pre>
We'll need to compile a total of four proto files to get this working.
First, let's create a new folder for our generated files to live in:</p>
mkdir</span> meshtastic</span></span></code></pre>
Then, cd</code> into the protobuf</code> folder, and run the following commands.
(You can compile all of them if you want to, but it's not needed for this use case.)</p>
protoc</span> --python_out=..</span> meshtastic/apponly.proto</span></span>
protoc</span> --python_out=..</span> meshtastic/channel.proto</span></span>
protoc</span> --python_out=..</span> meshtastic/device_ui.proto</span></span>
protoc</span> --python_out=..</span> meshtastic/config.proto</span></span></code></pre>
Finally, we need to make the meshtastic</code> folder a python "module", we we'll create an empty __init__.py</code> file inside:</p>
touch</span> meshtastic/__init__.py</span></span></code></pre>Decoding#</span></a>
</h3>
How that have all the prerequisites, let's get decoding!</p>
To start with we'll need to import the required pacakges:</p>
from</span> meshtastic.apponly_pb2</span> import</span> ChannelSet</span></span>
import</span> base64</span></span></code></pre>
We'll see the string we want to decode as a constant (for now):</p>
TO_DECODE</span> =</span> 'CjESIMC70tNI5vkpQpHZGeg0WV7y6KqEoD0_t74fM1_jCaMkGghCbG9nVGVzdCUEAAAAEg4IATgBQANIAVAeWBRoAQ'</span></span></code></pre>
Next, we'll create a new, empty object to populate with the deserialized data:</p>
channelSet</span> =</span> ChannelSet()</span></span></code></pre>
Finally, let's decode and display the channel name and PSK:</p>
channelSet.ParseFromString(base64.urlsafe_b64decode(</span>TO_DECODE</span> +</span> "=="</span>))</span></span>
</span>
for</span> s</span> in</span> channelSet.settings:</span></span>
    print</span>(</span>"Channel name: "</span> +</span> s.name)</span></span>
    print</span>(</span>"Psk: "</span> +</span> base64.b64encode(s.psk).decode())</span></span></code></pre>
A few notes on the implementation.
The settings are encoded in a "URL Safe" base64 encoding.
However, Python still expects the padding to be there, so we're adding the maximum of 2 padding characters to get around this.
If that's too many, any extras will be ignored by the decoder.
"Proper" URL Safe encoding explictly omits padding, but the Python library still requires it, so here we are.</p>
Results#</span></a>
</h2>
Running the above code, we'll get the settings we expect:</p>
$ python decode.py </span></span>
Channel name: BlogTest</span></span>
Psk: wLvS00jm+SlCkdkZ6DRZXvLoqoSgPT+3vh8zX+MJoyQ=</span></span></code></pre>
We can extract other properties if we want to, using the same approach.</p>
The End#</span></a>
</h2>