In this guide, we’ll walk through installing Cilium as the primary CNI and Multus as a secondary CNI meta-plugin on Talos OS. This combination introduces support for advanced features such as eBPF-powered networking, per-pod visibility, and attaching pods to multiple physical or logical networks.

This setup provides declarative infrastructure and immutable operating systems, eliminating the need for traditional Linux administration—no SSH, no shell, and no drifting configuration. The result is a consistent, secure, and maintainable cluster architecture suitable for long-term experimentation or light production use.

The answer depends heavily on infrastructure. In reality, infrastructure decisions come first, and the telemetry stack adapts to support what’s already in place—not the other way around. Observability evolves as a response to growing scale, complexity, and operational maturity.

The configuration is tailored for a single-node homelab using a compact mini-PC, but the principles can be adapted to larger or different environments. All playbooks, templates, and configuration files used in this guide are available in this GitHub repository for reference and reuse.

Structured logging organizes log data into a consistent, machine-readable format. For a primer on telemetry systems and observability fundamentals, see the blog post Introduction to Telemetry Systems.

In this post, we’ll explore the fundamentals of telemetry systems, how they work, the types of data they handle, and why they’re indispensable for achieving observability.

But as your application matures, Lambda’s trade-offs can become limiting:

• Cost scaling with consistent traffic
• Compute/memory coupling and lack of vertical scaling
• Package size limits and cold starts

That’s why many teams adopt a container-based workflow that can run on both Lambda (via container images) and ECS Fargate. With a little planning, you can build once and deploy to either platform with minimal friction.

If you’re considering moving more of your important files, services, or backups off of third-party cloud providers and into a system you control, a NAS can be a great fit. (You can read more about why I personally chose Synology here.

But if you’re like me and deal with a lot of files — especially big ones like videos or high-res photos — you’ve probably hit the same wall I did: cloud storage gets really expensive, really fast.

When it comes to building backend APIs in Python, you have a few great frameworks at your disposal—Django, FastAPI, and Flask—each with its own level of complexity and opinionation. Django is feature-rich and great for full-stack apps, Flask is minimal and flexible, but FastAPI stands out as a modern, async-first framework that makes it incredibly easy to build fast, clean, and production-ready APIs.

For straightforward websites or smaller-scale projects, these platforms can be a convenient choice. However, they often fall short when it comes to flexibility, automation, and cost-effectiveness at scale. Many lack robust CLI (Command Line Interface) support for streamlining tasks, can become expensive as your needs grow, or demand significant management effort and a steep learning curve.

In this blog, we will explore how to organize Terraform projects using Terragrunt, and how it solves common challenges with Terraform’s limitations such as managing backend configurations, large state files, and dependencies between multiple stacks.

While the principles outlined here are generally applicable to most networks, this implementation is specifically designed for UniFi OS version 4.06 and Network Application version 8.4.62.

In most production applications, CloudFront is used to serve static content to users. In this post, we will explore how to implement restricted access when serving content through CloudFront.

You can find the complete example here.

What is CloudFront?

In simple terms, CloudFront is a content delivery network (CDN) managed by AWS. A CDN is a network of servers deployed close to end users, serving as a caching layer to improve content delivery speed and reliability.

We will assume that you have access to at least two AWS accounts: one to hold pipeline resources and one target account where resources will be deployed.

Architecture

We will use two accounts: a pipeline account and a target account. The target account is your dev/staging/prod account. Usually, there is more than one target account in a given pipeline, but we will use one for simplicity. The same approach can be extended to an arbitrary number of target accounts.

In this blog post, we will delve into S3 presigned URLs as an effective method for implementing tiered access to your S3 data. We’ll discuss their benefits, limitations, and provide a straightforward example to illustrate their use.

What are Sealed Secrets?

Sealed Secrets is a set of Kubernetes resources, controller and custom resource definition, that enables secure storage of secrets in your version control system (VCS). Unlike standard Kubernetes Secrets, which are base64-encoded and easily decoded, Sealed Secrets use asymmetric encryption to ensure your secrets remain encrypted until deployed to your Kubernetes cluster. Once deployed, the Sealed Secrets controller decrypts them into regular Kubernetes secrets, making them accessible to your applications.

In this blog post we will explore how to turn your existing local computer/server into a simple ai server.

Today we will focus on properly securing outside-in web communication to our cluster with Cert-Manager and self-signed certificates. We assume that you have access to working kubernetes cluster with ingress controller.