DEV Community: Max

Build an Unusual Options Activity Scanner With Python and Free Data

Max — Wed, 15 Apr 2026 18:12:49 +0000

Last month I noticed something odd: SMCI options volume spiked to 8x its 20-day average on a random Tuesday afternoon. No news. No earnings. Three days later, the stock jumped 14% on a surprise partnership announcement. Someone knew.

Unusual options activity (UOA) — when volume on a specific contract explodes beyond normal levels — is one of the most reliable signals that informed money is positioning. Services like Unusual Whales and Cheddar Flow charge $40-80/month to show you this data. I built my own scanner for free in about 200 lines of Python.

What Counts as "Unusual"

Before writing code, you need a working definition. I use three filters:

Volume/Open Interest ratio > 3.0 — When daily volume on a contract is 3x or more the existing open interest, that’s new money entering, not existing positions rolling.
Premium > $25,000 — Filters out noise. A retail trader buying 5 contracts of a cheap OTM option isn’t a signal.
Days to expiration between 7-90 — Too short means gamma scalping. Too long means it’s likely a hedge, not a directional bet.

These aren’t perfect — no filter is. But they eliminate about 95% of the noise and leave you with 10-30 actionable alerts per day instead of thousands.

The Data Problem (and Three Free Solutions)

Options data is expensive. Real-time feeds from OPRA cost thousands per month. But for a daily scanner that runs after market close, you don’t need real-time. Here are three approaches I tested:

Option 1: Tradier Sandbox API (My Pick)

Tradier offers a free sandbox API that includes delayed options chains with volume and open interest. The delay is 15 minutes, which is fine for an end-of-day scanner. Rate limit: 120 requests/minute on the free tier.

import requests

TRADIER_TOKEN = "YOUR_SANDBOX_TOKEN"  # Free at developer.tradier.com
BASE = "https://sandbox.tradier.com/v1"
HEADERS = {
    "Authorization": f"Bearer {TRADIER_TOKEN}",
    "Accept": "application/json"
}

def get_options_chain(symbol: str) -> list[dict]:
    # First get expiration dates
    exp_url = f"{BASE}/markets/options/expirations"
    resp = requests.get(exp_url, headers=HEADERS, params={"symbol": symbol})
    dates = resp.json()["expirations"]["date"]

    all_contracts = []
    for exp_date in dates[:6]:  # Next 6 expirations
        chain_url = f"{BASE}/markets/options/chains"
        params = {"symbol": symbol, "expiration": exp_date}
        resp = requests.get(chain_url, headers=HEADERS, params=params)
        options = resp.json().get("options", {}).get("option", [])
        all_contracts.extend(options)

    return all_contracts

Each contract in the response includes volume, open_interest, last, and option_type. That’s everything you need.

Option 2: Yahoo Finance (yfinance)

The yfinance library pulls options data directly. No API key needed. The catch: it’s slow (one request per ticker) and Yahoo occasionally rate-limits aggressive scraping.

import yfinance as yf

ticker = yf.Ticker("AAPL")
for exp_date in ticker.options[:6]:
    chain = ticker.option_chain(exp_date)
    calls = chain.calls  # DataFrame with volume, openInterest, etc.
    puts = chain.puts

I used this initially but switched to Tradier. Yahoo’s data occasionally has gaps — missing volume on contracts that clearly traded — and the rate limiting makes scanning 100+ symbols painful.

Option 3: Polygon.io Free Tier

Polygon.io gives you 5 API calls/minute on the free tier. That’s rough for options scanning since you need one call per expiration per symbol. I’d only recommend this if you’re scanning fewer than 20 symbols.

The Scanner: 200 Lines That Actually Work

Here’s the core logic. I run this daily at 4:30 PM ET via cron.

from datetime import datetime, timedelta

def scan_unusual(contracts: list[dict], min_vol_oi: float = 3.0,
                 min_premium: float = 25000, max_dte: int = 90) -> list[dict]:
    """Filter options contracts for unusual activity."""
    today = datetime.now()
    unusual = []

    for c in contracts:
        volume = c.get("volume", 0) or 0
        oi = c.get("open_interest", 0) or 0
        last_price = c.get("last", 0) or 0

        # Skip dead contracts
        if volume == 0 or last_price == 0:
            continue

        # Calculate days to expiration
        exp = datetime.strptime(c["expiration_date"], "%Y-%m-%d")
        dte = (exp - today).days
        if dte  max_dte:
            continue

        # Volume/OI ratio (handle zero OI)
        vol_oi = volume / max(oi, 1)
        if vol_oi  dict:
    by_symbol = defaultdict(lambda: {"call_premium": 0, "put_premium": 0})
    for a in alerts:
        key = "call_premium" if a["type"] == "call" else "put_premium"
        by_symbol[a["symbol"]][key] += a["premium"]

    summary = {}
    for sym, data in by_symbol.items():
        total = data["call_premium"] + data["put_premium"]
        if total > 0:
            bull_pct = data["call_premium"] / total * 100
            summary[sym] = {
                "bullish_pct": round(bull_pct),
                "total_premium": total
            }
    return summary

2. Delivery. I push the top alerts to a Telegram channel using a bot. You could also use ntfy.sh (free, self-hostable) or plain email via smtplib.

What I Learned Running This for 6 Months

A few hard-earned observations:

UOA predicts direction roughly 60% of the time. That’s better than a coin flip, but it’s not magic. Don’t bet the farm on any single alert.
Sector clustering matters more than individual signals. When you see unusual call activity across 5 semiconductor names on the same day, that’s more meaningful than a single NVDA spike.
Earnings week is noise. I exclude any ticker with earnings within 5 trading days. The UOA around earnings is mostly people buying lottery tickets, not informed positioning.
Friday afternoon sweeps are the best signals. Big money placing bets late Friday when retail has checked out? That often moves Monday-Tuesday.

The Full Setup on a Raspberry Pi

My scanner runs on a Raspberry Pi 5 that also handles my other homelab scripts. Total resource usage: ~40MB RAM, finishes in under 10 minutes. Cron triggers it at 4:30 PM ET, and I get a Telegram notification with the day’s unusual activity by 4:40 PM.

If you want a more portable development environment, a Samsung T7 portable SSD makes it easy to carry your full dev setup between machines — I keep my Python environments and data on one so I can plug into any workstation.

For going deeper on the quantitative side, Python for Finance by Yves Hilpisch is the best resource I’ve found for turning signals like these into a backtestable strategy. It covers everything from data handling to options pricing models.

Should You Actually Trade on UOA?

Honestly? Maybe. I use it as one input alongside technicals and macro. The signals are real — informed money does move through the options market before news drops. But “informed” doesn’t mean “always right,” and options flow data is increasingly gamed by sophisticated players who know retail is watching.

The real value for me has been understanding market sentiment. When I see aggressive call buying across financials before an FOMC meeting, that tells me something about positioning — even if I don’t trade it directly.

If you want daily market intelligence covering signals like these, I run a free Telegram channel: Join Alpha Signal for free market analysis, sector rotation tracking, and macro breakdowns.

The full scanner code is about 200 lines. I’m considering open-sourcing it — if there’s interest, I’ll throw it on GitHub. For now, the snippets above give you everything you need to build your own.

Full disclosure: Amazon links above are affiliate links.

Full Stack Monitoring: A Security-First Approach

Max — Wed, 15 Apr 2026 16:46:34 +0000

TL;DR: Full stack monitoring is essential for modern architectures, encompassing infrastructure, applications, and user experience. A security-first approach ensures that monitoring not only detects performance issues but also safeguards against threats. By integrating DevSecOps principles, you can create a scalable, resilient, and secure monitoring strategy tailored for Kubernetes environments.

Quick Answer: Full stack monitoring is the practice of observing every layer of your system, from infrastructure to user experience, with a focus on performance and security. It’s critical for detecting issues early and maintaining a secure, reliable environment.

Introduction to Full Stack Monitoring

Imagine your application stack as a high-performance race car. The engine (infrastructure), the driver (application), and the tires (user experience) all need to work in harmony for the car to perform well. Now imagine trying to diagnose a problem during a race without any telemetry—no speedometer, no engine diagnostics, no tire pressure readings. That’s what running a modern system without full stack monitoring feels like.

Full stack monitoring is the practice of observing every layer of your system, from the underlying infrastructure to the end-user experience. It’s not just about ensuring uptime; it’s about understanding how each component interacts and identifying issues before they escalate. In today’s threat landscape, a security-first approach to monitoring is non-negotiable. Attackers don’t just exploit vulnerabilities—they exploit blind spots. (For network-layer visibility, see Kubernetes Network Policies and Service Mesh Security.) Monitoring every layer ensures you’re not flying blind.

Key components of full stack monitoring include:

Infrastructure Monitoring: Observing servers, networks, and cloud resources.
Application Monitoring: Tracking application performance, APIs, and microservices.
User Experience Monitoring: Measuring how end-users interact with your application.

But here’s the kicker: monitoring without a security-first mindset is like locking your front door while leaving the windows wide open. Let’s explore why security-first monitoring is critical and how it integrates seamlessly with Kubernetes and DevSecOps principles.

Full stack monitoring also provides the foundation for proactive system management. By collecting and analyzing data across all layers, teams can identify trends, predict potential failures, and optimize performance. For example, if your application experiences a sudden spike in database queries, monitoring can help pinpoint whether the issue lies in the application code, database configuration, or user behavior.

Additionally, full stack monitoring is invaluable for compliance. Many industries, such as finance and healthcare, require detailed logs and metrics to demonstrate adherence to regulations. A robust monitoring strategy ensures you have the necessary data to pass audits and maintain trust with stakeholders.

💡 Pro Tip: Start by mapping out your entire stack and identifying the most critical components to monitor. This will help you prioritize resources and avoid being overwhelmed by data.

Here’s a simple example of setting up a basic monitoring script using Python to track CPU and memory usage:

import psutil
import time

def monitor_system():
    while True:
        cpu_usage = psutil.cpu_percent(interval=1)
        memory_info = psutil.virtual_memory()
        print(f"CPU Usage: {cpu_usage}%")
        print(f"Memory Usage: {memory_info.percent}%")
        time.sleep(5)

if __name__ == "__main__":
    monitor_system()

This script provides a starting point for understanding system resource usage, which can be extended to include additional metrics or integrated with a larger monitoring framework.

Another practical example is using a cloud-based monitoring service like AWS CloudWatch or Google Cloud Operations Suite. These tools provide built-in integrations with your cloud infrastructure, making it easier to monitor resources like virtual machines, databases, and storage buckets. For instance, you can set up alarms in AWS CloudWatch to notify your team when CPU utilization exceeds a certain threshold, helping you respond to performance issues before they impact users.

⚠️ Common Pitfall: Avoid overloading your monitoring system with unnecessary metrics. Too much data can obscure critical insights and overwhelm your team.

To address edge cases, consider scenarios where your monitoring tools fail or produce incomplete data. For example, if your monitoring system relies on a single server and that server crashes, you lose visibility into your stack. Implementing redundancy and failover mechanisms for your monitoring infrastructure ensures continuous observability.

The Role of Full Stack Monitoring in Kubernetes

If you're hardening your cluster alongside monitoring, check out the Kubernetes Security Checklist for Production.

Kubernetes is a game-changer for modern application deployment, but it’s also a monitoring nightmare. Pods come and go, nodes scale dynamically, and workloads are distributed across clusters. Traditional monitoring tools struggle to keep up with this level of complexity.

Full stack monitoring in Kubernetes involves tracking:

Cluster Health: Monitoring nodes, pods, and resource utilization.
Application Performance: Observing how services interact and identifying bottlenecks.
Security Events: Detecting unauthorized access, privilege escalations, and misconfigurations.

Tools like Prometheus and Grafana are staples for Kubernetes monitoring. Prometheus collects metrics from Kubernetes components, while Grafana visualizes them in dashboards. But these tools are just the start. For a security-first approach, you’ll want to integrate solutions like Falco for runtime security and Open Policy Agent (OPA) for policy enforcement.

In a real-world scenario, consider a Kubernetes cluster running a microservices-based e-commerce application. Without proper monitoring, a sudden increase in traffic could overwhelm the payment service, causing delays or failures. By using Prometheus to monitor pod resource usage and Grafana to visualize trends, you can identify the issue and scale the affected service before it impacts users.

Another critical aspect is monitoring Kubernetes API server logs. These logs can reveal unauthorized access attempts or misconfigured RBAC (Role-Based Access Control) policies. For example, if a developer accidentally grants admin privileges to a service account, monitoring tools can alert you to the potential security risk.

⚠️ Security Note: The default configurations of many Kubernetes monitoring tools are not secure. Always enable authentication and encryption for Prometheus endpoints and Grafana dashboards.

Here’s an example of setting up Prometheus to scrape metrics securely:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes-nodes'
    scheme: https
    tls_config:
      ca_file: /etc/prometheus/ssl/ca.crt
      cert_file: /etc/prometheus/ssl/prometheus.crt
      key_file: /etc/prometheus/ssl/prometheus.key
    kubernetes_sd_configs:
      - role: node

This configuration ensures that Prometheus communicates securely with Kubernetes nodes using TLS.

When implementing monitoring in Kubernetes, it’s essential to account for the ephemeral nature of containers. Logs and metrics should be centralized to prevent data loss when pods are terminated. Tools like Fluentd and Elasticsearch can help aggregate logs, while Prometheus handles metrics collection.

💡 Pro Tip: Use Kubernetes namespaces to organize monitoring resources. For example, create a dedicated namespace for Prometheus, Grafana, and other observability tools to simplify management.

To further enhance security, consider using network policies to restrict communication between monitoring tools and other components. For example, you can use Calico or Cilium to define policies that allow Prometheus to scrape metrics only from specific namespaces or pods.

DevSecOps and Full Stack Monitoring: A Perfect Match

DevSecOps is the philosophy of integrating security into every phase of the development lifecycle. When applied to monitoring, it means embedding security checks and alerts into your observability stack. This approach not only improves security but also enhances reliability and performance.

Here’s how DevSecOps principles enhance full stack monitoring:

Shift Left: Monitor security metrics during development, not just in production.
Automation: Use CI/CD pipelines to deploy and update monitoring configurations.
Collaboration: Share monitoring insights across development, operations, and security teams.

For example, integrating SonarQube into your CI/CD pipeline can help identify code vulnerabilities early. Similarly, tools like Datadog and New Relic can provide real-time insights into application performance and security.

💡 Pro Tip: Use Infrastructure as Code (IaC) tools like Terraform to manage your monitoring stack. This ensures consistency across environments and makes it easier to audit changes.

Here’s an example of using Terraform to deploy a Prometheus and Grafana stack:

resource "helm_release" "prometheus" {
  name       = "prometheus"
  chart      = "prometheus"
  repository = "https://prometheus-community.github.io/helm-charts"
  namespace  = "monitoring"
}

resource "helm_release" "grafana" {
  name       = "grafana"
  chart      = "grafana"
  repository = "https://grafana.github.io/helm-charts"
  namespace  = "monitoring"
}

This Terraform configuration deploys Prometheus and Grafana using Helm charts, ensuring a consistent setup across environments.

Another key aspect of DevSecOps is integrating security scanning into your monitoring pipeline. Tools like Aqua Security and Trivy can scan container images for vulnerabilities, while Falco can detect runtime anomalies. For example, if a container starts running an unexpected process, Falco can trigger an alert and even terminate the container to prevent further damage.

🔒 Security Note: Always use signed container images from trusted sources to minimize the risk of deploying compromised software.

Advanced Monitoring Techniques

While traditional monitoring focuses on metrics and logs, advanced techniques like distributed tracing and anomaly detection can take your observability to the next level. Distributed tracing tools such as Jaeger and Zipkin allow you to track requests as they flow through microservices, providing insights into latency and bottlenecks.

Anomaly detection, powered by machine learning, can identify unusual patterns in your metrics. For example, if your application suddenly experiences a spike in error rates during off-peak hours, anomaly detection tools can flag this as a potential issue. Tools like Elastic APM and Dynatrace provide built-in anomaly detection capabilities. For a deeper dive into open-source security monitoring, see our guide on setting up Wazuh and Suricata for enterprise-grade detection.

💡 Pro Tip: Combine distributed tracing with metrics and logs for a comprehensive observability strategy. This triad ensures you capture every aspect of your system’s behavior.

Here’s an example of configuring Jaeger for distributed tracing in Kubernetes:

apiVersion: v1
kind: ConfigMap
metadata:
  name: jaeger-config
  namespace: monitoring
data:
  config.yaml: |
    collector:
      zipkin:
        http-port: 9411
    storage:
      type: memory

This configuration sets up Jaeger to collect traces and store them in memory, suitable for development environments.

Advanced monitoring also includes synthetic monitoring, where simulated user interactions are used to test application performance. For example, you can use tools like Selenium or Puppeteer to simulate user actions such as logging in or making a purchase. These tests can be scheduled to run periodically, ensuring your application remains functional under various conditions.

Future Trends in Full Stack Monitoring

As technology evolves, so does the field of monitoring. Emerging trends include the use of AI and predictive analytics to anticipate issues before they occur. For example, AI-driven monitoring tools can analyze historical data to predict when a server might fail or when traffic spikes are likely to occur.

Another trend is the integration of observability with chaos engineering. Tools like Gremlin allow you to simulate failures in your system, testing its resilience and ensuring your monitoring tools can detect and respond to these events effectively.

Finally, edge computing is reshaping monitoring strategies. With data being processed closer to users, monitoring tools must adapt to decentralized architectures. Tools like Prometheus and Grafana are evolving to support edge deployments, ensuring visibility across distributed systems.

💡 Pro Tip: Stay ahead of the curve by experimenting with AI-driven monitoring tools and chaos engineering practices. These approaches can significantly enhance your system’s resilience and observability.

🛠️ Recommended Resources:

Tools and books mentioned in (or relevant to) this article:

Kubernetes in Action, 2nd Edition — The definitive guide to deploying and managing K8s in production ($45-55)
Learning Helm — Managing apps on Kubernetes with the Helm package manager ($35-45)
Hacking Kubernetes — Threat-driven analysis and defense of K8s clusters ($40-50)
GitOps and Kubernetes — Continuous deployment with Argo CD, Jenkins X, and Flux ($40-50)

Frequently Asked Questions

What is full stack monitoring?

Full stack monitoring is the practice of observing every layer of a system, including infrastructure, applications, and user experience. It ensures optimal performance and security by identifying issues early and understanding how different components interact.

Why is a security-first approach important in monitoring?

A security-first approach ensures that monitoring not only detects performance issues but also safeguards against potential threats. Attackers often exploit blind spots, so monitoring every layer of the system helps prevent vulnerabilities from being overlooked.

What are the key components of full stack monitoring?

The key components include infrastructure monitoring (servers, networks, cloud resources), application monitoring (performance, APIs, microservices), and user experience monitoring (how end-users interact with the application).

How does full stack monitoring integrate with DevSecOps principles?

By integrating DevSecOps principles, full stack monitoring becomes a proactive tool for security and performance. It ensures that monitoring strategies are scalable, resilient, and tailored for environments like Kubernetes, aligning development, security, and operations teams.

TrueNAS Setup Guide: Enterprise Security at Home

Max — Tue, 14 Apr 2026 16:47:13 +0000

TL;DR: TrueNAS is a powerful storage solution for homelabs, offering enterprise-grade features like ZFS, encryption, and snapshots. This guide walks you through setting up TrueNAS securely, from hardware selection to implementing firewalls and VPNs. By following these steps, you’ll ensure your data is safe, accessible, and future-proof.

Quick Answer: TrueNAS is the best choice for secure, scalable storage in a homelab. With proper setup, including encryption, access controls, and regular updates, you can achieve enterprise-level security at home.

Introduction to TrueNAS and Homelab Security

It started with a simple question: “Why am I trusting a random cloud provider with my personal data?” That thought led me down the rabbit hole of homelab storage solutions, and eventually to TrueNAS. TrueNAS, with its ZFS foundation, enterprise-grade features, and open-source roots, quickly became my go-to choice for secure, reliable storage.

TrueNAS is more than just a NAS (Network Attached Storage); it’s a full-fledged storage operating system. Whether you’re running TrueNAS CORE or SCALE, you get features like snapshots, replication, and encryption—tools you’d typically find in enterprise environments. But here’s the catch: with great power comes great responsibility. Misconfiguring TrueNAS can leave your data vulnerable to attacks or corruption.

In this guide, I’ll show you how to set up TrueNAS in your homelab with a security-first mindset. We’ll cover everything from hardware selection to implementing firewalls and VPNs. By the end, you’ll have a robust, secure storage solution that rivals enterprise setups—scaled down for personal use.

Homelab security is often overlooked, but it’s just as critical as the security of enterprise systems. Cyberattacks, ransomware, and data breaches are no longer limited to large corporations. Even personal setups can be targeted, especially if they’re improperly configured or exposed to the internet. TrueNAS provides a solid foundation for securing your data, but it’s up to you to implement best practices and maintain vigilance.

One of the key benefits of TrueNAS is its ability to scale with your needs. Whether you’re a hobbyist storing family photos or a developer managing terabytes of project data, TrueNAS can adapt to your requirements. However, scaling also introduces complexity, which makes proper planning and configuration even more important. This guide will help you navigate these challenges and build a system that’s both secure and scalable.

Planning Your TrueNAS Setup

Before diving into installation, you need to plan your setup. A well-thought-out plan will save you headaches later, especially when it comes to scaling or troubleshooting. Here’s what you need to consider:

Hardware Requirements and Recommendations

TrueNAS can run on a variety of hardware, but not all setups are created equal. For 2025 and beyond, here are my recommendations:

CPU: At least a quad-core processor. Intel Xeon or AMD Ryzen are excellent choices for ECC memory support.
RAM: Minimum 16GB, but 32GB+ is recommended for ZFS deduplication and caching.
Storage: Use enterprise-grade HDDs (e.g., Seagate IronWolf Pro or WD Red Pro) for reliability. SSDs are great for caching or fast datasets.
NIC: A 1GbE NIC is sufficient for most homelabs, but consider 10GbE if you’re dealing with large data transfers.

💡 Pro Tip: Always use ECC (Error-Correcting Code) memory if your motherboard supports it. ZFS relies heavily on RAM, and ECC ensures data integrity by preventing bit-flipping errors.

When selecting hardware, consider future-proofing your setup. For example, if you anticipate needing more storage in the future, choose a motherboard with additional SATA or NVMe slots. Similarly, if you plan to run virtual machines or containers on TrueNAS SCALE, invest in a CPU with higher core counts and better multi-threading capabilities.

Another important consideration is power consumption. Homelabs often run 24/7, so energy-efficient components can save you money in the long run. Look for CPUs and drives with low power draw, and consider using a power-efficient PSU (Power Supply Unit) with an 80 Plus Gold or Platinum rating.

Choosing the Right TrueNAS Version

TrueNAS comes in two flavors: CORE and SCALE. Here’s a quick comparison to help you decide:

TrueNAS CORE: Based on FreeBSD, it’s stable and battle-tested. Ideal for traditional NAS use cases.
TrueNAS SCALE: Linux-based with Kubernetes support. Perfect for running containers and virtual machines alongside your storage.

If you’re planning to integrate your NAS with Docker or Kubernetes, go with SCALE. Otherwise, CORE is a solid choice for pure storage needs.

💡 Pro Tip: If you’re unsure which version to choose, start with TrueNAS CORE. You can always migrate to SCALE later if your needs evolve. The TrueNAS community forums are also a great resource for advice and troubleshooting.

It’s worth noting that TrueNAS SCALE is relatively new compared to CORE, so some features may still be in development. If you require cutting-edge functionality like container orchestration, SCALE is the way to go. However, if you prioritize stability and a proven track record, CORE is the safer bet.

Network Considerations

Your network setup plays a critical role in both performance and security. Here are some best practices:

Use VLANs to segment your NAS traffic from other devices.
Set up a dedicated management interface for TrueNAS.
Enable jumbo frames if your network supports it for better performance.

⚠️ Security Note: Never expose your TrueNAS web interface directly to the internet. Always use a VPN or reverse proxy with authentication.

For homelabs with multiple devices, consider using a managed switch to create VLANs (Virtual Local Area Networks). VLANs allow you to isolate your NAS from less secure devices, such as IoT gadgets, reducing the risk of lateral movement in case of a breach. For example, you could place your NAS on VLAN 10 and your IoT devices on VLAN 20, ensuring they can’t communicate directly.

Another important aspect of network planning is IP addressing. Assign a static IP to your TrueNAS server to avoid issues with DHCP leases expiring or changing. This is especially important if you plan to access your NAS remotely or integrate it with other services like Proxmox or Plex.

Installation and Initial Configuration

With your hardware and network plan in place, it’s time to install TrueNAS. Here’s a step-by-step guide:

Installing TrueNAS

Download the latest ISO from the official TrueNAS website. Use a tool like Rufus to create a bootable USB drive. Boot your server from the USB and follow the installation wizard. Choose the boot drive carefully—it should be a small SSD or USB stick, separate from your storage drives.

# Example: Creating a bootable USB on Linux
sudo dd if=truenas.iso of=/dev/sdX bs=4M status=progress

During installation, you’ll be prompted to configure basic settings like timezone and network interfaces. Take your time to review these options, as they can impact your system’s performance and accessibility. For example, if you’re using multiple NICs, ensure the correct one is selected for management purposes.

💡 Pro Tip: If you’re using a USB stick as your boot drive, consider creating a backup of the installation. USB drives can fail over time, so having a backup will save you from having to reinstall and reconfigure everything.

Configuring Storage Pools and Datasets

Once installed, log in to the TrueNAS web interface. The first step is setting up your storage pool. Use RAID-Z for redundancy and performance. For example, RAID-Z2 offers a good balance of fault tolerance and usable space.

# Example: Creating a ZFS pool via CLI (if needed)
zpool create -f mypool raidz2 /dev/sd[b-e]

Next, create datasets for organizing your data. Datasets allow you to apply specific settings like compression, quotas, and permissions at a granular level.

💡 Pro Tip: Enable compression (e.g., LZ4) on all datasets. It improves performance and saves space without noticeable overhead.

When setting up datasets, think about how you’ll use your storage. For example, you might create separate datasets for media, backups, and personal files. This not only helps with organization but also allows you to apply different settings to each dataset. For instance, you could enable deduplication for backups but disable it for media files to save on system resources.

Setting Up User Accounts

TrueNAS supports multiple user accounts, each with specific permissions. Avoid using the root account for daily tasks. Instead, create individual accounts for each user and assign them to groups for easier management.

To enhance security, use strong, unique passwords for each account. If you’re managing multiple users, consider enabling two-factor authentication (2FA) for added protection. TrueNAS also supports SSH key-based authentication, which is more secure than password-based logins.

💡 Pro Tip: Use groups to manage permissions more efficiently. For example, create a “Media” group for users who need access to your media dataset, and assign permissions at the group level instead of individually.

Implementing Enterprise-Grade Security Practices

Now that your TrueNAS is up and running, let’s secure it. These steps will help you implement enterprise-grade security practices:

Enabling Encryption

TrueNAS supports encryption at the dataset level. Enable it during dataset creation and store the encryption keys securely. For added security, use a hardware security module (HSM) or a password-protected key file.

# Example: Encrypting a dataset via CLI
zfs create -o encryption=on -o keyformat=passphrase mypool/securedata

Encryption is a critical feature for protecting sensitive data, but it’s only effective if the keys are managed properly. Avoid storing encryption keys on the same device as your TrueNAS server. Instead, use a secure external device or a dedicated key management system.

💡 Pro Tip: Regularly back up your encryption keys and store them in a secure location. Losing your keys means losing access to your encrypted data.

Configuring Firewalls and VPNs

Use a firewall like OPNsense to restrict access to your TrueNAS server. Set up rules to allow only trusted IPs or VPN connections. For remote access, configure a VPN (e.g., WireGuard or OpenVPN) to securely tunnel into your network.

When configuring your firewall, consider using geo-blocking to restrict access from countries you don’t expect traffic from. Additionally, enable logging to monitor access attempts and identify potential threats. For VPNs, WireGuard is a lightweight and modern option that offers excellent performance and security.

⚠️ Security Note: Avoid using outdated VPN protocols like PPTP, as they are no longer considered secure.

Regular Updates and Patching

Keeping your system updated is critical. TrueNAS provides a built-in updater for applying patches and updates. Schedule regular maintenance windows to ensure your system stays secure.

⚠️ Security Note: Always test updates in a staging environment before applying them to production systems.

Updates often include security patches that address newly discovered vulnerabilities. Delaying updates can leave your system exposed to attacks. If possible, enable email notifications for update availability so you’re always informed.

Maintenance and Best Practices

Maintaining your TrueNAS setup is just as important as the initial configuration. Here are some best practices:

Monitoring System Health

Enable email alerts to stay informed about system events. Use tools like Grafana and Prometheus to monitor metrics like disk usage, CPU load, and network traffic.

Regularly check the SMART status of your drives to identify potential failures before they occur. TrueNAS includes built-in tools for monitoring drive health, but you can also use third-party solutions for more detailed insights.

💡 Pro Tip: Set up a dashboard in Grafana to visualize key metrics at a glance. This makes it easier to identify trends and spot issues early.

Automating Backups

Set up automated snapshots and replication tasks to back up your data. Store backups offsite or in a separate location within your homelab.

For critical data, consider using a 3-2-1 backup strategy: three copies of your data, stored on two different media types, with one copy offsite. This ensures you’re protected against hardware failures, accidental deletions, and disasters like fires or floods.

💡 Pro Tip: Use cloud storage services like Backblaze B2 or Wasabi for offsite backups. TrueNAS supports integration with these services for seamless replication.

Periodic Security Audits

Review logs and access records regularly. Look for unusual activity and address potential vulnerabilities promptly.

Security audits should include checking for unused accounts, outdated permissions, and unpatched vulnerabilities. Use tools like Nessus or OpenVAS to scan your network for potential issues.

Scaling Up: Future-Proofing Your Homelab

As your storage needs grow, you’ll need to scale your TrueNAS setup. Here’s how to prepare:

Add more drives to your pool or create additional pools for specific workloads.
Integrate TrueNAS with other homelab services like Proxmox or Kubernetes.
Stay informed about emerging security trends and adapt your setup accordingly.

Scaling up often involves adding more hardware, which can introduce new challenges. For example, adding drives to an existing pool may require rebalancing data, which can be time-consuming. Plan for these scenarios in advance to minimize downtime.

💡 Pro Tip: Use hot-swappable drive bays for easier hardware upgrades. This allows you to replace or add drives without shutting down your server.

New Section: Integrating TrueNAS with Other Services

TrueNAS can be integrated with a variety of services to enhance its functionality. Here are some popular integrations:

Media Servers

TrueNAS works seamlessly with media servers like Plex and Emby. Store your media files on a dedicated dataset and configure your media server to access them. This setup allows you to stream movies, TV shows, and music directly from your NAS.

💡 Pro Tip: Use SSDs for your media dataset if you frequently access large files. This improves performance and reduces buffering.

Virtualization Platforms

If you’re running a virtualization platform like Proxmox or VMware, you can use TrueNAS as a shared storage solution. Configure iSCSI or NFS shares to provide high-performance storage for your virtual machines.

💡 Pro Tip: Use separate datasets for each VM to simplify management and improve performance.

New Section: Advanced Troubleshooting

Even with the best planning, issues can arise. Here’s how to troubleshoot common problems:

Performance Issues

If your TrueNAS server is running slowly, check the following:

Disk health: Use SMART tools to identify failing drives.
Network configuration: Ensure your NICs are configured correctly and aren’t overloaded.
Resource usage: Monitor CPU and RAM usage to identify bottlenecks.

💡 Pro Tip: Use the built-in reporting tools in TrueNAS to visualize performance metrics over time.

Access Problems

If users can’t access their data, check the following:

Permissions: Ensure the correct permissions are set on datasets and shares.
Network connectivity: Verify that the server is reachable and the correct IP is being used.
Authentication: Check user accounts and passwords for errors.

Frequently Asked Questions

What’s the difference between TrueNAS CORE and SCALE?

CORE is FreeBSD-based and ideal for traditional NAS use. SCALE is Linux-based and supports containers and VMs.

Can I use consumer-grade hardware for TrueNAS?

You can, but enterprise-grade hardware (e.g., ECC RAM, server-grade drives) is recommended for reliability and data integrity.

How do I secure remote access to TrueNAS?

Use a VPN like WireGuard or OpenVPN. Avoid exposing the TrueNAS web interface directly to the internet.

What’s the best way to back up TrueNAS data?

Use ZFS snapshots and replication tasks. Store backups offsite or on a separate server for redundancy.

🛠️ Recommended Resources:

Tools and books mentioned in (or relevant to) this article:

Crucial 64GB DDR4 ECC SODIMM Kit — ECC RAM for data integrity in your NAS or hypervisor ($150-200)
WD Red Plus 8TB NAS HDD — CMR drive designed for 24/7 NAS operation with RAID support ($140-180)
Beelink EQR6 Mini PC (Ryzen 7 6800U) — Compact powerhouse for Proxmox or TrueNAS virtualization ($350-500)
APC UPS 1500VA — Battery backup to protect your homelab from power outages ($170-200)

Key Takeaways

TrueNAS offers enterprise-grade features for homelabs, but proper configuration is essential for security.
Use ECC memory, RAID-Z, and VLANs to ensure data integrity and network segmentation.
Enable encryption, configure firewalls, and use VPNs for secure access.
Regular updates, backups, and security audits are non-negotiable.

References

Track Congressional Stock Trades with Python and Free SEC Data

Max — Mon, 13 Apr 2026 18:12:52 +0000

Last month I noticed something odd: a senator sold $2M in hotel stocks three days before a travel industry report tanked the sector. Coincidence? Maybe. But it got me wondering — is there an easy way to track what members of Congress are buying and selling?

Turns out, the STOCK Act of 2012 requires all members of Congress to disclose securities transactions within 45 days. These filings are public. And you can pull them programmatically. I built a Python script that checks for new congressional trades daily, flags the interesting ones, and sends me alerts. Here’s exactly how.

Why Congressional Trades Matter

Members of Congress sit on committees that regulate industries, receive classified briefings, and vote on bills that move markets. Whether they’re trading on insider knowledge is a debate I’ll leave to lawyers. What I care about is this: as a group, congressional traders have historically outperformed the S&P 500 by 6-12% annually, depending on the study you reference. A 2022 paper from the University of Georgia put the figure at 8.9% annualized excess returns for Senate trades.

Even if you think it’s all luck, following these trades is a free signal you can add to your research process. At worst, it shows you where politically-connected money is flowing.

Where the Data Lives

Congressional financial disclosures are filed through two systems:

Senate: efdsearch.senate.gov — the Electronic Financial Disclosures database
House: disclosures-clerk.house.gov — the Clerk of the House system

Both are publicly searchable, but neither offers a clean API. The Senate site has a search form that returns HTML results. The House site recently added a JSON search endpoint, which is nicer to work with. Several community projects scrape and normalize this data — the most maintained one is the House Stock Watcher dataset on S3, which gets updated daily.

For this project, I combined the House Stock Watcher dataset (free, updated daily, clean JSON) with direct scraping of the Senate EFD search for the freshest possible data.

The Python Script

Here’s the core of what I run. It pulls House transactions from the public S3 dataset, filters for trades above $15,000 (the minimum reporting threshold is $1,001, but small trades are noise), and flags any trades in the last 7 days:

import json
import urllib.request
from datetime import datetime, timedelta

HOUSE_DATA_URL = (
    "https://house-stock-watcher-data.s3-us-west-2"
    ".amazonaws.com/data/all_transactions.json"
)

def fetch_house_trades(days_back=7, min_amount="$15,001 - $50,000"):
    req = urllib.request.Request(HOUSE_DATA_URL)
    with urllib.request.urlopen(req) as resp:
        trades = json.loads(resp.read())

    cutoff = datetime.now() - timedelta(days=days_back)
    amount_tiers = [
        "$15,001 - $50,000",
        "$50,001 - $100,000",
        "$100,001 - $250,000",
        "$250,001 - $500,000",
        "$500,001 - $1,000,000",
        "$1,000,001 - $5,000,000",
        "$5,000,001 - $25,000,000",
        "$25,000,001 - $50,000,000",
    ]
    tier_idx = amount_tiers.index(min_amount)
    valid_tiers = set(amount_tiers[tier_idx:])

    recent = []
    for t in trades:
        try:
            tx_date = datetime.strptime(
                t["transaction_date"], "%Y-%m-%d"
            )
        except (ValueError, KeyError):
            continue
        if tx_date >= cutoff and t.get("amount") in valid_tiers:
            recent.append(t)

    return sorted(
        recent,
        key=lambda x: x.get("transaction_date", ""),
        reverse=True,
    )

Each transaction record includes the representative’s name, ticker, transaction type (purchase/sale), amount range, and disclosure date. The amount ranges are annoying — Congress doesn’t disclose exact figures, just brackets — but even the brackets tell you a lot when someone drops $500K+ on a single stock.

Filtering for Signal

Raw congressional trade data is noisy. Most trades are mutual fund purchases or routine portfolio rebalancing. The interesting stuff is when you see:

Committee-relevant trades — A member of the Armed Services Committee buying defense stocks, or a Finance Committee member trading bank shares
Cluster buys — Multiple members buying the same ticker within a short window
Large single-stock positions — Anything above $250K in one company
Timing around legislation — Trades made shortly before committee votes or bill introductions

I added a scoring function that flags trades matching these patterns:

COMMITTEE_SECTORS = {
    "Armed Services": ["LMT", "RTX", "NOC", "GD", "BA"],
    "Energy": ["XOM", "CVX", "COP", "SLB", "EOG"],
    "Finance": ["JPM", "BAC", "GS", "MS", "C"],
    "Health": ["UNH", "JNJ", "PFE", "ABBV", "MRK"],
    "Technology": ["AAPL", "MSFT", "GOOGL", "AMZN", "META"],
}

def score_trade(trade, member_committees):
    score = 0
    ticker = trade.get("ticker", "")
    amount = trade.get("amount", "")

    # Large position = more interesting
    if "$250,001" in amount or "$500,001" in amount:
        score += 30
    elif "$1,000,001" in amount:
        score += 50

    # Committee relevance
    for committee, tickers in COMMITTEE_SECTORS.items():
        if committee in member_committees and ticker in tickers:
            score += 40
            break

    # Purchase vs sale (purchases are more actionable)
    if trade.get("type") == "purchase":
        score += 10

    return min(score, 100)

The committee mapping is simplified here — in production I maintain a fuller list pulled from congress.gov. But even this basic version catches the most egregious cases.

Setting Up Daily Alerts

I run this on a Raspberry Pi 4 (affiliate link) sitting in my closet. A cron job runs the script every morning at 7 AM, checks for new trades filed since the last run, and sends me a notification via ntfy (a free, self-hosted push notification tool).

import urllib.request

def send_alert(message, topic="congress-trades"):
    req = urllib.request.Request(
        f"https://ntfy.sh/{topic}",
        data=message.encode(),
        headers={"Title": "Congressional Trade Alert"},
    )
    urllib.request.urlopen(req)

# In main loop:
for trade in fetch_house_trades(days_back=1, min_amount="$50,001 - $100,000"):
    msg = (
        f"{trade['representative']}: "
        f"{trade['type']} {trade['ticker']} "
        f"({trade['amount']})"
    )
    send_alert(msg)

The Raspberry Pi draws about 5 watts, costs nothing to run, and handles this job without breaking a sweat. If you don’t want to run your own hardware, a $5/month VPS from any provider works too. I wrote about setting up a homelab for projects like this if you want to go the self-hosted route.

What I’ve Learned Running This for 6 Months

A few patterns jumped out after collecting data since late 2025:

Disclosure delays are the real problem. The 45-day filing window means by the time you see a trade, the move may already be priced in. The most useful trades are the ones filed quickly — within 10-15 days. Some members consistently file within a week; those are the ones I weight highest.

Cluster signals beat individual trades. One senator buying Nvidia means nothing. Three members from different parties all buying Nvidia in the same two-week window? That’s worth investigating. My script tracks cluster buys — 3+ distinct members trading the same ticker within 14 days — and those have been the most actionable signals.

Sales matter more than purchases for timing. Purchases can be routine investment. But when several members suddenly sell the same sector? That’s been a leading indicator for bad news more often than purchases predict good news.

I won’t claim this is a trading strategy on its own — it’s one data point I check alongside technicals, fundamentals, and corporate insider trades from SEC Form 4 filings. The congressional data adds a political risk dimension that most retail traders ignore entirely.

Alternatives and Paid Tools

If you don’t want to build your own, several paid services track this data:

Quiver Quantitative (free tier + paid) — best visualization, shows committee-trade correlations. The free tier covers delayed data.
Capitol Trades (free) — clean interface, basic filtering. No alerts or scoring.
Unusual Whales ($30-100/mo) — includes congressional data alongside options flow. Worth it if you want both in one platform.

I prefer my DIY version because I can customize the scoring, add my own committee mappings, and cross-reference against other datasets I already collect. But if you just want to glance at the data without writing code, Capitol Trades is solid and free.

Extending It

The basic script above gets you 80% of the value. If you want to go further:

Add Senate data — the EFD search site requires a bit more scraping work since it returns HTML, but BeautifulSoup handles it. A good Python web scraping reference (affiliate link) will save you hours.
Cross-reference with Polygon.io — I use Polygon’s market data API to check price action after each disclosed trade. This lets you backtest whether following congressional trades would have been profitable.
Build a dashboard — Grafana + SQLite gives you a clean visual history. Run it on the same Pi.
Track state-level trades — Some states have their own disclosure requirements for governors and state legislators. Less data, but less competition from other trackers too.

The full source code for my version is about 400 lines of Python with zero paid dependencies — just stdlib plus BeautifulSoup for the Senate scraping. I might open-source it if there’s interest; drop a comment below if that’d be useful.

I publish daily market intelligence — including congressional trade alerts — on our free Telegram channel. Join Alpha Signal for daily signals, trade analysis, and macro context. No fluff, no paywalls on the basics.

CSS Gradient Builder: Fixing Annoyances of Existing Tools

Max — Mon, 13 Apr 2026 16:47:44 +0000

Last Tuesday I needed a conic gradient. Not a linear one, not a radial one — specifically a conic gradient for a loading spinner I was building. I opened three different gradient generators. None of them supported conic gradients. The ones that did were buried under ads, tracking scripts, and cookie consent banners that took longer to dismiss than the actual gradient took to build.

TL;DR: GradientForge is a free browser-based CSS gradient builder that fixes the annoyances of existing tools — it supports linear, radial, and conic gradients, provides real-time preview with no ads or tracking, outputs clean CSS with vendor prefixes, and includes preset collections for common design patterns.

So I spent my afternoon building GradientForge instead.

The Problem With Existing Gradient Tools

I tested the three most popular gradient generators before writing a single line of code. Here's what I found:

cssgradient.io is the go-to recommendation on Stack Overflow answers from 2019. It handles linear and radial gradients well enough, but it's slow. The page loads with trackers, analytics, and display ads competing for bandwidth. When I tested on a throttled 3G connection, first meaningful paint took over four seconds. For a tool that should generate a CSS property in under a second, that's unacceptable.

Grabient looks beautiful — I'll give it that. But it's primarily a preset gallery with limited customization. Want to add a third color stop? That's buried in the interface. Want conic gradients? Not available. Want to export as SVG for a design file? Nope.

uiGradients follows the same preset-only pattern. Pick from a curated list, copy the CSS. No custom stop positions, no angle fine-tuning, no easing control. It's a gradient menu, not a gradient builder.

Every single one of these tools was missing at least one thing I needed: conic gradient support, easing between color stops, SVG export, or just basic speed. I wanted all of those in one place.

What GradientForge Actually Does

GradientForge supports all three CSS gradient types: linear, radial, and conic. You pick your type, adjust the parameters, and see the result update in real-time on a full-screen canvas preview. The CSS code appears below, ready to copy with one click or keyboard shortcut (Ctrl+C when nothing is selected).

The color stop system works the way it should. Click a color picker, drag the position handle along the gradient bar, or type an exact percentage. Double-click the bar to add a new stop at that position — the tool interpolates the correct color automatically. You can have up to 10 stops per gradient, which covers every practical use case I've encountered.

The feature I'm most proud of is the easing system. Standard CSS gradients transition linearly between color stops, which often produces muddy middle zones where colors mix in ugly ways. GradientForge generates additional intermediate stops that follow an easing curve — ease-in, ease-out, ease-in-out, or stepped transitions. The result is smoother, more visually pleasing gradients without manual fine-tuning of each stop position.

Here's what happens technically: when you select an easing function, the tool interpolates 8 additional color stops between each pair of your original stops, positioning them along the chosen easing curve. The browser sees a gradient with many stops, but the transitions follow a cubic or stepped curve instead of a linear one. The output CSS is longer, but the visual result is noticeably better, especially for gradients spanning complementary colors.

How I Built It

GradientForge is a single HTML file with inline CSS and JavaScript — zero dependencies. No React, no Tailwind, no build step, no node_modules. The entire tool is about 36KB — smaller than most hero images. It loads in under 100ms on any modern connection.

The architecture is straightforward state management. A single JavaScript object holds the current gradient configuration: type, angle, color stops, easing mode, and type-specific parameters. Every time any control changes, the entire UI re-renders from that state object. It sounds wasteful, but with only a few DOM elements to update, each render cycle takes under 2ms.

The color stop bar uses pointer events for drag handling. Each stop is a positioned div inside the bar container. On mousedown, I capture the element, switch to mousemove tracking on the document (not the bar — that prevents losing the drag when the cursor moves fast), and compute the percentage position from the cursor's X coordinate relative to the bar's bounding rect. Touch events follow the same pattern for mobile support.

For color interpolation, I convert hex colors to RGB components, interpolate each channel independently, and convert back. This happens in sRGB space, which isn't perceptually uniform — I'd like to add OKLCH interpolation in a future version for even smoother results. But for most practical gradients, sRGB interpolation is indistinguishable from perceptual to human eyes.

The SVG export translates CSS gradient parameters into SVG gradient elements. Linear gradients map directly to <linearGradient> with computed x1/y1/x2/y2 coordinates derived from the CSS angle. Radial gradients use <radialGradient> with center positions. Conic gradients don't have a native SVG equivalent, so the tool falls back to a linear approximation — not perfect, but useful enough for most design workflows.

The URL State Trick

Every gradient configuration is encoded in the URL query parameters. Change a color, move a stop, switch the type — the URL updates silently via history.replaceState. This means you can share a gradient by sharing the URL. No accounts, no saving to a database, no server-side state. The recipient opens the link and sees your exact gradient configuration ready to use.

The encoding is compact: gradient type is a single character (l/r/c), stops are comma-separated hex:position pairs, and type-specific parameters use short keys. A three-stop linear gradient with easing encodes to about 120 characters in the URL — short enough to paste in a Slack message without it looking intimidating.

Privacy and Performance

Everything runs in your browser. There's no server processing, no analytics tracking your color choices, no data leaving your machine. The tool works completely offline once loaded — I included a service worker that caches all assets. Install it as a PWA and you've got a native-feeling gradient builder that works on a plane.

I ran Lighthouse on the deployed version: 100 across all four categories. Performance, accessibility, best practices, SEO — all perfect scores. That's what happens when your entire app is 36KB of self-contained HTML with proper ARIA labels and semantic markup.

12 Built-In Presets

Sometimes you don't want to build from scratch. GradientForge includes 12 presets — Sunset, Ocean, Forest, Flame, Night, Peach, Arctic, Berry, Candy, Mint, Dusk, and Neon. Click one to load it, then customize from there. They're starting points, not endpoints.

The presets also serve as a discovery tool. If you're not sure what conic gradients look like, hit the Random button. It generates a random type, random angle, random colors, and random number of stops. Hit it ten times and you'll have a better intuition for what each gradient type does than reading any tutorial could give you.

Dark Mode and Mobile

The interface respects your system color scheme preference automatically. No toggle needed — though I might add one in a future update for users who want to test their gradient against both backgrounds. On mobile, the layout shifts from a side-by-side view (preview + controls) to a stacked view with the preview on top and controls scrollable below. Touch targets are 44px minimum for comfortable thumb navigation.

I tested at 320px width (iPhone SE), 768px (iPad), and 1440px (desktop). The gradient preview always takes up as much space as possible — that's the point of the tool, after all. Controls compress but remain usable at every breakpoint.

What's Next

I have a short list of features I want to add: OKLCH color interpolation for perceptually smoother gradients, a gradient animation builder (because CSS can animate gradient positions), multi-gradient layering (stack multiple gradients on one element), and an accessibility checker that warns when your gradient doesn't meet contrast requirements for text overlays.

For now, GradientForge does exactly what I needed: build any CSS gradient, with any number of stops, with smooth easing, in any of the three gradient types, and copy the result in one click. No ads, no tracking, no signup. Just gradients.

Try GradientForge →

FAQ

Does GradientForge support conic gradients?

Yes — this was the primary motivation for building it. Most existing CSS gradient generators only support linear and radial gradients. GradientForge supports all three types: linear, radial, and conic, with full control over angle, color stops, and positioning.

Is GradientForge free to use?

Completely free, with no ads, tracking scripts, or account requirements. It runs entirely in your browser — no data is sent to any server.

What browsers support conic gradients?

All modern browsers support conic gradients: Chrome 69+, Firefox 83+, Safari 12.1+, and Edge 79+. GradientForge includes vendor prefix options for broader compatibility and shows a browser support indicator for each gradient type you create.

References

MDN Web Docs. "CSS conic-gradient()." Mozilla, 2026.
Can I Use. "CSS Conic Gradients browser support." Can I Use, 2026.
W3C. "CSS Images Module Level 4." W3C, 2024.

OpenClaw Setup: Zero to Autonomous AI Mastery

Max — Sun, 12 Apr 2026 16:49:30 +0000

Setting up OpenClaw is easy. Setting it up right so your AI agent actually does useful work autonomously takes some know-how.

What Makes OpenClaw Different

Unlike ChatGPT or Claude, which respond to individual prompts, OpenClaw creates persistent AI agents that remember between sessions, act autonomously through cron jobs, use real tools like browser automation and APIs, and self-improve by editing their own configuration.

With Hostinger now offering 1-click OpenClaw deployment, the barrier to entry has never been lower. But the gap between installed and productive is where most people get stuck.

The 3 Mistakes New OpenClaw Users Make

1. Generic SOUL.md

Your SOUL.md file is your agent's personality and decision-making framework. A generic "you are a helpful assistant" produces generic results. A well-crafted SOUL.md with specific principles, boundaries, and communication style creates an agent that feels like a capable teammate.

2. No Memory Protocol

Without structured memory, every session starts from scratch. The 3-layer memory system (State, Journal, Knowledge) gives your agent continuity. It remembers what worked, what failed, and what it learned — across sessions and days.

3. Manual-Only Operation

The real power of OpenClaw is autonomous operation via cron jobs. An agent that only responds to messages is using 10% of its potential. Cron jobs let your agent monitor, create, publish, and optimize while you sleep.

Quick Start Checklist

If you're setting up OpenClaw for the first time, here's what actually matters:

Edit SOUL.md — give your agent a specific personality and principles, not generic instructions
Edit USER.md — tell it who you are and what you need done
Edit TOOLS.md — add your local services (Home Assistant, NAS, etc.)
Create the data/ directory with state.json, knowledge.md, and journal/
Set up 3 starter crons: email check (every 2h), weather (morning), RSS monitor (every 4h)
Configure browser-agent for web automation tasks
Test a heartbeat cycle to verify autonomous operation works end-to-end
Create HEARTBEAT.md with your periodic task checklist

The difference between a toy setup and a useful one is usually about 30 minutes of configuration. The memory protocol alone transforms the experience from "stateless chatbot" to "AI that actually knows what happened yesterday."

What I Learned Running This in Production

I've been running an OpenClaw agent with 31 skills and 25+ daily cron jobs since March 2026. A few things surprised me:

Memory matters more than model choice. Switching from GPT-4o to Claude Opus made less difference than implementing proper state persistence. An agent that remembers its failures and learns from them outperforms a smarter agent that starts fresh every time.

Cron patterns need iteration. My first cron jobs ran too frequently and produced noise. The sweet spot was fewer jobs that batch related checks together. One heartbeat that checks email + calendar + weather beats three separate crons.

Skills compound. Each new skill makes existing ones more useful. Browser automation + RSS monitoring = automatic content research. Trading data + newsletter publishing = daily market intelligence on autopilot.

The full setup guide with templates, 30 production-tested cron patterns, and SOUL.md examples is available at orthogonal.info.

Questions about OpenClaw setup? Drop them in the comments — I've probably hit the same wall.

GitOps vs GitHub Actions: Security-First in Production

Max — Sat, 11 Apr 2026 18:17:34 +0000

Last month I migrated two production clusters from GitHub Actions-only deployments to a hybrid GitOps setup with ArgoCD. The trigger? A misconfigured workflow secret that exposed an AWS key for 11 minutes before our scanner caught it. Nothing happened — this time. But it made me rethink how we handle the boundary between CI and CD.

Here’s what I learned about running both tools securely in production, and when each one actually makes sense.

GitOps: Let Git Be the Only Way In

GitOps treats Git as the single source of truth for your cluster state. You define what should exist in a repo, and an agent like ArgoCD or Flux continuously reconciles reality to match. No one SSHs into production. No one runs kubectl apply by hand.

The security model here is simple: the cluster pulls config from Git. The agent runs inside the cluster with the minimum permissions needed to apply manifests. Your developers never need direct cluster access — they open a PR, it gets reviewed, merged, and the agent picks it up.

This is a massive reduction in attack surface. In a traditional CI/CD model, your pipeline needs credentials to push to the cluster. With GitOps, those credentials stay inside the cluster.

Here’s a basic ArgoCD Application manifest:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/my-org/my-app-config
    targetRevision: HEAD
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app-namespace
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

The selfHeal: true setting is important — if someone does manage to modify a resource directly in the cluster, ArgoCD will revert it to match Git. That’s drift detection for free.

One gotcha: make sure you enforce branch protection on your GitOps repos. I’ve seen teams set up ArgoCD perfectly, then leave the main branch unprotected. Anyone with repo write access can then deploy anything. Always require reviews and status checks.

GitHub Actions: Powerful but Exposed

GitHub Actions is a different animal. It’s event-driven — push code, open a PR, hit a schedule, and workflows fire. That flexibility is exactly what makes it harder to secure.

Every GitHub Actions workflow that deploys to production needs some form of credential. Even with OIDC federation (which you should absolutely be using), there are still risks. Third-party actions can be compromised. Workflow files can be modified in feature branches. Secrets can leak through step outputs if you’re not careful.

Here’s a typical deployment workflow:

name: Deploy to Kubernetes
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Configure kubectl
        uses: azure/setup-kubectl@v3
      - name: Deploy application
        run: kubectl apply -f k8s/deployment.yaml

Notice the environment: production — that enables environment protection rules, so deployments require manual approval. Without it, any push to main goes straight to prod. I always set this up, even on small projects.

The bigger issue is that GitHub Actions workflows are imperative. You’re writing step-by-step instructions that execute on a runner with network access. Compare that to GitOps where you declare “this is what should exist” and an agent figures out the rest. The imperative model has more moving parts, and more places for things to go wrong.

Where Each One Wins on Security

After running both in production, here’s how I’d break it down:

Access control — GitOps wins. The agent pulls from Git, so your CI system never needs cluster credentials.

Secret handling — GitOps is cleaner. You pair it with External Secrets Operator or Sealed Secrets and your Git repo never contains actual credentials. GitHub Actions has encrypted secrets, but they’re injected into the runner environment at build time.

Audit trail — GitOps. Every change is a Git commit with an author, timestamp, and review trail.

Flexibility — GitHub Actions. Running test suites, building container images, scanning for vulnerabilities — these are CI tasks, and GitHub Actions handles them well.

Speed of setup — GitHub Actions. You can go from zero to deployed in an afternoon.

The Hybrid Approach (What Actually Works)

Most teams end up running both, and it’s the right call. Use GitHub Actions for CI — build, test, scan, push images. Use GitOps for CD — let ArgoCD or Flux handle what’s running in the cluster.

The boundary is important: GitHub Actions should never directly kubectl apply to production. Instead, it updates the image tag in your GitOps repo (via a PR or direct commit to a deploy branch), and the GitOps agent picks it up.

This gives you:

Full Git audit trail for all production changes
No cluster credentials in your CI system
Automatic drift detection and self-healing
The flexibility of GitHub Actions for everything that isn’t deployment

Adding Security Scanning to the Pipeline

Whether you use GitOps, GitHub Actions, or both, you need automated security checks. I run Trivy on every image build and OPA/Gatekeeper for policy enforcement in the cluster.

The exit-code: 1 setting in Trivy means the workflow fails if critical or high vulnerabilities are found. No exceptions. It’s caught real issues — including supply chain problems in base images that would have made it to prod otherwise.

What I’d Do Starting Fresh

If I were setting up a new production Kubernetes environment today:

ArgoCD for all cluster deployments, with strict branch protection and required reviews
GitHub Actions for CI only — build, test, scan, push to registry
External Secrets Operator for credentials, never stored in Git
OPA Gatekeeper for policy enforcement
Trivy in CI, plus periodic scanning of running images

The investment in GitOps pays off fast once you’re past the initial setup. The first time you need to answer “what changed?” during a 2 AM incident and the answer is right there in the Git log, you’ll be glad you did it.

Originally published at orthogonal.info

Stop Ngrok Tunnels: Enterprise Security Practices for Your Homelab

Max — Sat, 11 Apr 2026 16:46:53 +0000

Ngrok is one of those tools that's dangerously easy to love. Spin up a tunnel, get a public URL, share your local service with the world. But that convenience hides real risk — especially if you're running a homelab where tunnels tend to linger longer than they should.

I've been running a homelab for years, and I'll admit: I've left Ngrok tunnels running overnight more times than I'd like. Each one was an open door I forgot to close. Here's what I've learned about managing them properly.

Why Ngrok Tunnels Are a Security Problem

Every active Ngrok tunnel increases your attack surface. Attackers actively scan public Ngrok URLs for exposed services — databases without auth, admin panels, development APIs. If you're not monitoring your tunnels, you're essentially leaving a backdoor open.

The bigger issue: Ngrok tunnels bypass your firewall rules. That carefully configured pfSense or OPNsense setup? Ngrok sidesteps it entirely by tunneling outbound through HTTPS. Your IDS/IPS won't see the inbound traffic because it arrives through Ngrok's infrastructure.

Temporary tunnels created for "quick testing" are the worst offenders. They stay active long after you've moved on to something else.

Enterprise Practices That Work at Home

You don't need Splunk or a SOC team to manage tunnels properly. Here's what actually works:

Least Privilege

Only expose what's absolutely necessary. If you're testing a webhook, limit access to the IP ranges of the service provider. Use Ngrok's built-in access control rather than leaving tunnels wide open.

Monitoring

Ngrok exposes a local API at http://localhost:4040/api/tunnels. Use it. A simple script can check for active tunnels and alert you:

import requests

API_URL = "http://localhost:4040/api/tunnels"
response = requests.get(API_URL)
tunnels = response.json()["tunnels"]

for tunnel in tunnels:
    if tunnel["status"] == "active":
        print(f"Stopping tunnel: {tunnel['name']}")
        requests.delete(f"{API_URL}/{tunnel['name']}")

Automated Cleanup

Schedule tunnel termination so you don't rely on remembering. A systemd timer or cron job works fine:

# Crontab: check every hour, kill active tunnels
0 * * * * ngrok api tunnels list | grep -q 'active' && ngrok api tunnels stop --all

I prefer systemd timers over cron for this — they're easier to debug and give you better logging.

Scaling Down Enterprise Tools

You don't need Datadog. Here's what works for a homelab:

Prometheus + Grafana for monitoring tunnel activity and setting alerts
OAuth2 Proxy in front of exposed services for authentication
VLANs to isolate services exposed via Ngrok from the rest of your network
Traefik or Nginx as a reverse proxy for SSL termination, auth, and rate limiting

The goal is layers. No single tool solves everything, but stacking a few open-source options gives you real protection.

Advanced Configurations Worth Setting Up

Custom domains make your tunnels less predictable and let you apply stricter DNS policies.

Rate limiting prevents abuse:

{
    "rate_limit": {
        "requests_per_second": 10
    }
}

Webhook validation — if you're using Ngrok for webhook testing, always verify HMAC signatures or use token-based auth. Don't trust incoming requests just because they hit your tunnel URL.

Key Takeaways

Every active tunnel is an open door. Close what you're not using.
Ngrok bypasses your firewall — treat tunnels as external access points, not internal tools.
Automate cleanup with cron or systemd. Don't rely on memory.
Use open-source monitoring (Prometheus/Grafana) instead of expensive enterprise tools.
Layer your defenses: VLANs, reverse proxies, authentication, rate limiting.
Consider a zero-trust approach even in your homelab — verify every connection.

Got a Ngrok horror story? I've definitely had my share. Drop a comment — I'm curious what others have run into.

Secure TrueNAS Plex Setup for Your Homelab

Max — Fri, 10 Apr 2026 18:13:44 +0000

Learn how to set up Plex on TrueNAS with enterprise-grade security practices tailored for home use. Protect your data while enjoying smooth media streaming.

TrueNAS and Plex

The error message was cryptic: “Permission denied.” You just wanted to stream your favorite movie, but Plex refused to cooperate. Meanwhile, your TrueNAS server was humming along, oblivious to the chaos. If you’ve ever struggled with setting up a secure and functional Plex server on TrueNAS, you’re not alone.

TrueNAS is a powerful, open-source storage solution designed for reliability and scalability. It’s built on ZFS, a solid file system that offers advanced features like snapshots, compression, and data integrity checks. For homelab enthusiasts, TrueNAS is often the backbone of their setup, providing centralized storage for everything from personal files to virtual machines.

Plex, on the other hand, is the go-to media server for streaming movies, TV shows, and music across devices. Combining TrueNAS and Plex allows you to use enterprise-grade storage for your media library while enjoying smooth streaming. But here’s the catch: without proper security measures, you’re leaving your data—and potentially your network—vulnerable to attacks.

TrueNAS and Plex are popular choices for homelab setups because they complement each other perfectly. TrueNAS ensures your data is stored securely and efficiently, while Plex provides a user-friendly interface for accessing your media. However, combining these two requires careful planning to avoid common pitfalls such as permission issues, performance bottlenecks, and security vulnerabilities.

For example, many users encounter issues with Plex not being able to access their media files due to incorrect permissions on the TrueNAS side. This is often caused by a misunderstanding of how TrueNAS handles datasets and user permissions. Also, without proper network isolation, your Plex server could inadvertently expose your TrueNAS system to external threats.

💡 Pro Tip: Before starting, map out your homelab architecture on paper or with a tool like draw.io. This will help you visualize how Plex and TrueNAS will interact within your network.

Preparing Your Homelab for Secure Deployment

Before diving into the installation, let’s talk about the foundation: your homelab’s hardware and network setup. A secure deployment starts with the right infrastructure.

Hardware Requirements: TrueNAS requires a machine with ECC (Error-Correcting Code) RAM for data integrity, multiple hard drives for ZFS pools, and a CPU with virtualization support if you plan to run additional services. Plex, while less demanding, benefits from a CPU with good transcoding capabilities, especially if you stream to multiple devices simultaneously.

For example, if you plan to stream 4K content to multiple devices, a CPU with hardware transcoding support (such as Intel Quick Sync or an NVIDIA GPU) can significantly improve performance. On the storage side, using SSDs for your ZFS cache can speed up access to frequently used files.

Network Isolation: Your homelab should be isolated from your main network. This is where VLANs (Virtual LANs) come into play. By segmenting your network, you can ensure that devices in your homelab don’t have unrestricted access to the rest of your network.

For instance, you can configure your router or managed switch to create a VLAN specifically for your homelab. This VLAN can include your TrueNAS server, Plex server, and any other devices you use for testing or development. By applying firewall rules, you can control which devices can communicate with each other and with the internet.

⚠️ Security Note: Always configure your firewall to block unnecessary inbound and outbound traffic. Open ports are an open invitation for attackers.

Also, consider using a dedicated firewall like OPNsense to manage traffic between VLANs. This gives you granular control over what devices can communicate with your homelab. For example, you can allow Plex to access the internet for updates but block it from communicating with other devices outside its VLAN.

# Example: Creating a VLAN in OPNsense
vlan create 10
vlan set description "Homelab VLAN"
vlan assign interface em0

Installing and Configuring TrueNAS

With your hardware and network ready, it’s time to install TrueNAS. The process is straightforward, but there are a few critical steps to ensure a secure setup.

Step 1: Installation
Download the TrueNAS ISO from the official website and create a bootable USB drive using tools like Rufus or BalenaEtcher. Boot your server from the USB and follow the installation wizard. Choose a strong root password during setup—this is your first line of defense.

During installation, you’ll be prompted to configure your network settings. Make sure to assign a static IP address to your TrueNAS server. This makes it easier to access the web interface and ensures that your server remains accessible even if your router reboots.

Step 2: ZFS Pools
Once TrueNAS is installed, log into the web interface and navigate to the Storage section. Create ZFS pools using your hard drives. For Plex, it’s best to create a dedicated dataset for your media library. This allows you to set specific permissions and quotas.

# Example: Creating a dataset for Plex media
zfs create tank/plex_media
zfs set quota=500G tank/plex_media
zfs set compression=on tank/plex_media
zfs set acltype=posixacl tank/plex_media

Step 3: User Permissions
Create a dedicated user for Plex with restricted access. Assign this user permissions to the Plex dataset only. This prevents Plex from accessing other parts of your storage.

To do this, navigate to the Users section in the TrueNAS web interface and create a new user. Assign this user to a group specifically created for Plex. Then, use ACLs (Access Control Lists) to grant the group read/write access to the Plex dataset.

💡 Pro Tip: Use ACLs (Access Control Lists) for fine-grained permission control. TrueNAS makes this easy via its web interface.

If you encounter issues with permissions, check the dataset’s ACL settings and ensure that the Plex user has the necessary access. A common mistake is forgetting to apply changes after modifying ACLs.

Setting Up Plex with Enterprise Security Practices

With TrueNAS configured, it’s time to install Plex. While Plex is relatively simple to set up, securing it requires extra effort.

Step 1: Installation
TrueNAS SCALE users can install Plex via the built-in Apps section. For TrueNAS CORE, you’ll need to create a jail and install Plex manually.

# Example: Installing Plex in a TrueNAS jail
pkg install plexmediaserver
sysrc plexmediaserver_enable=YES
service plexmediaserver start

Step 2: Securing Plex
Enable SSL for Plex to encrypt traffic between your server and clients. You can use a self-signed certificate or integrate with Let’s Encrypt for a trusted certificate. Also, set a strong password for your Plex account and enable two-factor authentication.

⚠️ Security Note: Disable remote access unless absolutely necessary. If you must enable it, use a VPN to secure the connection.

Step 3: Minimizing Attack Vectors
Restrict Plex’s network access using firewall rules. For example, block Plex from accessing the internet except for updates. This reduces the risk of data leaks.

Another way to secure Plex is by using a reverse proxy like Nginx or Traefik. This allows you to manage SSL certificates and enforce additional security measures such as rate limiting and IP whitelisting.

# Example: Configuring Nginx as a reverse proxy for Plex
server {
    listen 443 ssl;
    server_name plex.example.com;

    ssl_certificate /etc/nginx/ssl/plex.crt;
    ssl_certificate_key /etc/nginx/ssl/plex.key;

    location / {
        proxy_pass http://localhost:32400;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Ongoing Maintenance and Security Monitoring

Setting up Plex and TrueNAS is only half the battle. Maintaining their security requires regular updates and monitoring.

Regular Updates: Both TrueNAS and Plex release updates to patch vulnerabilities. Schedule regular update checks and apply patches promptly. For TrueNAS SCALE, updates can be applied directly from the web interface.

Log Monitoring: TrueNAS and Plex generate logs that can help you identify suspicious activity. Set up log forwarding to a centralized logging solution like Graylog or ELK for easier analysis.

# Example: Forwarding logs from TrueNAS
syslogd -a graylog.local:514

Disaster Recovery: Automate backups of your Plex dataset and TrueNAS configuration. Store backups on a separate device or cloud storage to ensure recovery in case of hardware failure.

💡 Pro Tip: Test your backups periodically. A backup is useless if it doesn’t work when you need it.

Also, consider implementing a snapshot schedule for your ZFS pools. Snapshots allow you to roll back to a previous state in case of accidental data deletion or corruption.

Advanced Networking for Plex and TrueNAS

For users looking to take their homelab to the next level, advanced networking configurations can improve both security and performance.

Using VLANs: As mentioned earlier, VLANs are essential for network isolation. However, you can also use VLANs to prioritize traffic. For example, you can assign a higher priority to Plex traffic to ensure smooth streaming even during heavy network usage.

Implementing QoS: Quality of Service (QoS) settings on your router or switch can help manage bandwidth allocation. This is particularly useful if you have multiple users accessing Plex simultaneously.

# Example: Configuring QoS for Plex traffic
qos set priority high plex_vlan

💡 Pro Tip: Use tools like Wireshark to analyze network traffic and identify bottlenecks.

🛠️ Recommended Resources:

Tools and books mentioned in (or relevant to) this article:

Crucial 64GB DDR4 ECC SODIMM Kit — ECC RAM for data integrity in your NAS or hypervisor ($150-200)
WD Red Plus 8TB NAS HDD — CMR drive designed for 24/7 NAS operation with RAID support ($140-180)
Protectli Vault FW4B — Fanless mini PC perfect for pfSense/OPNsense firewall ($300-400)
UniFi Dream Machine Pro — All-in-one network appliance with IDS/IPS and VLAN support ($379-399)

main points

TrueNAS and Plex make a powerful combination for homelabs, but security must be a priority.
Isolate your homelab using VLANs and firewall rules to protect your main network.
Use ZFS datasets and ACLs to control access to your media library.
Secure Plex with SSL, strong passwords, and restricted network access.
Regular updates, log monitoring, and automated backups are essential for ongoing security.
Advanced networking configurations like VLANs and QoS can improve performance and security.

Have questions or tips about securing your homelab? Drop a comment or reach out on Twitter. Next week, we’ll explore setting up OPNsense with VLANs for advanced network segmentation. Stay tuned!

Build a Free VPN with Cloudflare Tunnel & WARP (2026 Guide)

Max — Fri, 10 Apr 2026 16:47:24 +0000

TL;DR: Cloudflare offers two free VPN solutions: WARP (consumer privacy VPN using WireGuard) and Cloudflare Tunnel + Zero Trust (self-hosted VPN replacement for accessing your home network). This guide covers both approaches step-by-step, with Docker Compose configs, split-tunnel setup, and security hardening. Zero Trust is free for up to 50 users — enough for any homelab or small team.

Why Build Your Own VPN in 2026?

Commercial VPN providers make bold promises about privacy, but their centralized architecture creates a fundamental trust problem. You’re routing all your traffic through servers you don’t control, operated by companies whose revenue model depends on subscriber volume — not security audits. ExpressVPN, NordVPN, and Surfshark have all faced scrutiny over logging practices, jurisdiction shopping, and opaque ownership structures.

Cloudflare offers a different model. Instead of renting someone else’s VPN, you build your own using Cloudflare’s global Anycast network (330+ data centers in 120+ countries) as the transport layer. The result is a VPN that’s faster than most commercial alternatives, costs nothing, and gives you full control over access policies.

There are two distinct approaches, and you might want both:

Cloudflare WARP — A consumer VPN app that encrypts your device traffic using WireGuard. Install, toggle on, done. Best for: browsing privacy on public Wi-Fi.
Cloudflare Tunnel + Zero Trust — A self-hosted VPN replacement that lets you access your home network (NAS, Proxmox, Pi-hole, Docker services) from anywhere without opening a single firewall port. Best for: homelabbers, remote workers, small teams.

Part 1: Cloudflare WARP — The 5-Minute Privacy VPN

What WARP Actually Does

WARP is built on the WireGuard protocol — the same modern, lightweight VPN protocol that replaced IPSec and OpenVPN in most serious deployments. When you enable WARP, your device establishes an encrypted tunnel to the nearest Cloudflare data center. From there, your traffic exits onto the internet through Cloudflare’s network.

Key technical details:

Protocol: WireGuard (via Cloudflare’s BoringTun implementation in Rust)
DNS: Queries routed through 1.1.1.1 (Cloudflare’s privacy-first DNS resolver, audited by KPMG)
Encryption: ChaCha20-Poly1305 for data, Curve25519 for key exchange
Latency impact: Typically 1-5ms added (vs. 20-50ms for most commercial VPNs) because traffic routes to the nearest Anycast PoP
No IP selection: WARP doesn’t let you choose exit countries — it’s a privacy tool, not a geo-unblocking tool

Installation

WARP runs on every major platform through the 1.1.1.1 app:

Platform
Install Method

Windows
one.one.one.one → Download

macOS
one.one.one.one → Download

iOS
App Store → search “1.1.1.1”

Android
Play Store → search “1.1.1.1”

Linux
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-archive-keyring.gpg && echo "deb [signed-by=/usr/share/keyrings/cloudflare-archive-keyring.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list && sudo apt update && sudo apt install cloudflare-warp

After installing, launch the app and toggle WARP on. That’s it. Your DNS queries now go through 1.1.1.1 and your traffic is encrypted to Cloudflare’s edge.

WARP vs. WARP+ vs. Zero Trust

Feature
WARP (Free)
WARP+ ($)
Zero Trust WARP

Price
$0
~$5/month
Free (50 users)

Encryption
WireGuard
WireGuard
WireGuard

Speed optimization
Standard routing
Argo Smart Routing
Standard routing

Private network access
No
No
Yes

Access policies
No
No
Full ZTNA

DNS filtering
No
No
Gateway policies

For most people, free WARP is sufficient for everyday privacy. If you need remote access to your homelab, keep reading — Part 2 is where it gets interesting.

Part 2: Cloudflare Tunnel + Zero Trust — The Self-Hosted VPN Replacement

This is the setup that replaces WireGuard, OpenVPN, or Tailscale for accessing your home network. The architecture is elegant: a lightweight daemon called cloudflared runs inside your network and maintains an outbound-only encrypted tunnel to Cloudflare. Remote clients connect through Cloudflare’s network using the WARP client. No inbound ports. No dynamic DNS. No exposed IP address.

Architecture Overview

javascript
┌─────────────────┐ ┌──────────────────────┐ ┌─────────────────┐ │ Remote Device │ │ Cloudflare Edge │ │ Home Network │ │ (WARP Client) │◄───────►│ 330+ PoPs globally │◄───────►│ (cloudflared) │ │ │ WireGuard│ │ Outbound │ │ │ Phone/Laptop │ Tunnel │ Zero Trust Policies │ Tunnel │ NAS/Docker/LAN │ └─────────────────┘ └──────────────────────┘ └─────────────────┘


### Prerequisites

- A **Cloudflare account** (free tier works)

- A **domain name** with DNS managed by Cloudflare (required for tunnel management)

- A server on your home network — any Linux box, Raspberry Pi, Synology NAS, or even a Docker container on TrueNAS

- **Docker + Docker Compose** (recommended) or bare-metal `cloudflared` installation

### Step 1: Create a Tunnel in the Zero Trust Dashboard

- Go to [one.dash.cloudflare.com](https://one.dash.cloudflare.com/) → Networks → Tunnels

- Click **Create a tunnel**

- Select **Cloudflared** as the connector type

- Name your tunnel (e.g., `homelab-tunnel`)

- Copy the **tunnel token** — you’ll need this for the Docker config

### Step 2: Deploy cloudflared with Docker Compose

Create a `docker-compose.yml` on your home server:

sql

`version: "3.8"
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared-tunnel
    restart: unless-stopped
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    network_mode: host   # Required for private network routing

  # Example: expose a local service
  whoami:
    image: traefik/whoami
    container_name: whoami
    ports:
      - "8080:80"`

Create a .env file alongside it:

`TUNNEL_TOKEN=eyJhIjoiYWJj...your-token-here`

Start the tunnel:

`docker compose up -d
docker logs cloudflared-tunnel  # Should show "Connection registered"`

Critical note: Use network_mode: host if you want to route traffic to your entire LAN subnet (192.168.x.0/24). Without it, cloudflared can only reach services within the Docker network.

Step 3: Expose Services via Public Hostnames

Back in the Zero Trust dashboard, under your tunnel’s Public Hostnames tab:

Click Add a public hostname
Set subdomain: nas, domain: yourdomain.com
Service type: HTTP, URL: localhost:5000 (or wherever your service runs)
Save

Cloudflare automatically creates a DNS record. Your NAS is now accessible at https://nas.yourdomain.com — with automatic SSL, DDoS protection, and Cloudflare WAF.

Step 4: Enable Private Network Routing (Full VPN Mode)

This is what turns a simple tunnel into a full VPN replacement. Instead of exposing individual services, you route an entire IP subnet through the tunnel.

In Zero Trust dashboard → Networks → Tunnels → your tunnel → Private Networks
Add your LAN CIDR: 10.0.0.x/24 (adjust to your subnet)
Go to Settings → WARP Client → Split Tunnels
Switch to Include mode and add 10.0.0.x/24

Now, any device running the WARP client (enrolled in your Zero Trust org) can access 192.168.1.x addresses as if they were on your home network. SSH into your server, access your NAS web UI, reach your Pi-hole dashboard — all without port forwarding.

Step 5: Enroll Client Devices

Install the 1.1.1.1 / WARP app on your phone or laptop
Go to Settings → Account → Login to Cloudflare Zero Trust
Enter your team name (set during Zero Trust setup)
Authenticate with the method you configured (email OTP, Google SSO, GitHub, etc.)
Enable Gateway with WARP mode

Test it: connect to mobile data (not your home Wi-Fi) and try accessing a LAN IP like http://10.0.0.x. If the router admin page loads, your VPN is working.

Step 6: Lock It Down — Zero Trust Access Policies

The “Zero Trust” part of this setup is what separates it from a traditional VPN. Instead of “anyone with the VPN key gets full network access,” you define granular policies:

bash
`Zero Trust Dashboard → Access → Applications → Add an Application

Application type: Self-hosted
Application domain: nas.yourdomain.com

Policy: Allow
Include: Emails ending in @yourdomain.com
Require: Country equals United States (optional geo-fence)

Session duration: 24 hours`


You can create different policies per service. Your Proxmox admin panel might require hardware key (FIDO2) authentication, while your Jellyfin media server only needs email OTP. This is **Zero Trust Network Access (ZTNA)** — the same architecture that Google BeyondCorp and Microsoft Entra use internally.

## Cloudflare Tunnel vs. Alternatives: Honest Comparison

Feature
Cloudflare Tunnel
WireGuard
Tailscale
OpenVPN

Price
Free (50 users)
Free
Free (100 devices)
Free

Open ports required
None
1 UDP port
None
1 UDP/TCP port

Setup complexity
Medium
Medium-High
Low
High

Works behind CG-NAT
Yes
Needs port forward
Yes
Needs port forward

Access control
Full ZTNA policies
Key-based only
ACLs + SSO
Cert-based

DDoS protection
Yes (Cloudflare)
No
No
No

SSL/TLS termination
Automatic
N/A
N/A
Manual

Trust model
Trust Cloudflare
Self-hosted
Trust Tailscale
Self-hosted

Best for
Web services + LAN
Pure privacy
Mesh networking
Enterprise legacy

**The honest tradeoff**: Cloudflare Tunnel routes your traffic through Cloudflare’s infrastructure. If you fundamentally distrust any third party touching your packets, self-hosted WireGuard is the purist choice. But for most homelabbers, the convenience of zero open ports + free DDoS protection + granular access policies makes Cloudflare Tunnel the pragmatic winner.

## Advanced: Multi-Service Docker Stack

Here’s a production-grade Docker Compose that exposes multiple services through a single tunnel:

sql

`version: "3.8"

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    networks:
      - tunnel
    depends_on:
      - nginx

  nginx:
    image: nginx:alpine
    container_name: nginx-proxy
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    networks:
      - tunnel

  # Add your services here — they just need to be on the 'tunnel' network
  # Configure public hostnames in the CF dashboard to point to nginx

networks:
  tunnel:
    name: cf-tunnel`

Map each service to a subdomain in the Zero Trust dashboard: grafana.yourdomain.com → http://nginx:3000, code.yourdomain.com → http://nginx:8443, etc.

Troubleshooting Common Issues

Tunnel shows “Disconnected” in the dashboard

Check Docker logs: docker logs cloudflared-tunnel
Verify your token hasn’t been rotated
Ensure outbound HTTPS (port 443) isn’t blocked by your router/ISP
If behind a corporate firewall, cloudflared also supports HTTP/2 over port 7844

Private network routing doesn’t work

Confirm network_mode: host in Docker Compose (or use macvlan)
Check that the CIDR in “Private Networks” matches your actual subnet
Verify Split Tunnels are set to Include mode (not Exclude)
On the client, run warp-cli settings to verify the private routes are active

WARP client won’t enroll

Double-check your team name in Zero Trust → Settings → Custom Pages
Ensure you’ve created a Device enrollment policy under Settings → WARP Client → Device enrollment permissions
Allow email domains or specific emails that can enroll

Security Hardening Checklist

☐ Enable Require Gateway in device enrollment — forces all enrolled devices through Cloudflare Gateway for DNS filtering
☐ Set session duration to 24h or less for sensitive services
☐ Require FIDO2/hardware keys for admin panels (Proxmox, router, etc.)
☐ Enable device posture checks: require screen lock, OS version, disk encryption
☐ Use Service Tokens (not user auth) for machine-to-machine tunnel access
☐ Monitor Access audit logs: Zero Trust → Logs → Access
☐ Never put your tunnel token in a public Git repository — use .env files and .gitignore
☐ Rotate tunnel tokens periodically via the dashboard

FAQ

Is Cloudflare Tunnel really free?

Yes. Cloudflare Zero Trust offers a free plan that includes tunnels, access policies, and WARP client enrollment for up to 50 users. There are no bandwidth limits on the free tier. Paid plans (starting at $7/user/month) add features like logpush, extended session management, and dedicated egress IPs.

Can Cloudflare see my traffic?

Cloudflare terminates TLS at their edge, so they technically could inspect unencrypted HTTP traffic passing through the tunnel. For HTTPS services, end-to-end encryption between your browser and origin server means Cloudflare sees metadata (domain, timing) but not content. If this is a concern, use WireGuard for a fully self-hosted solution where no third party touches your packets.

Does this work with Starlink / CG-NAT / mobile hotspots?

Yes — this is one of Cloudflare Tunnel’s biggest advantages. Since the tunnel is outbound-only, it works behind any NAT, including carrier-grade NAT (CG-NAT) used by Starlink, T-Mobile Home Internet, and most 4G/5G connections. No port forwarding needed.

Can I use this for site-to-site VPN?

Yes, using WARP Connector (currently in beta). Install cloudflared with WARP Connector mode on a device at each site, and Cloudflare routes traffic between subnets. This replaces traditional IPSec site-to-site tunnels.

Cloudflare Tunnel vs. Tailscale — which should I use?

Use Tailscale if your primary need is device-to-device mesh networking (see also our guide on home network segmentation with OPNsense) (accessing any device from any other device). Use Cloudflare Tunnel if you want to expose web services with automatic HTTPS and DDoS protection, or if you need granular ZTNA policies. Many homelabbers use both: Tailscale for device mesh, Cloudflare Tunnel for public-facing services.

References

Cloudflare. “Connect private networks.” Cloudflare One Documentation, 2026.
Cloudflare. “Cloudflare Tunnel setup guide.” Cloudflare Developers, 2026.
Donenfeld, Jason A. “WireGuard: Next Generation Kernel Network Tunnel.” NDSS Symposium, 2017.
Cloudflare. “Introducing WARP: Fixing Mobile Internet Performance and Security.” Cloudflare Blog, 2019.
Ward, Brendan and Harris, Rustam. “BoringTun: a userspace WireGuard implementation in Rust.” Cloudflare Blog, 2019.
Google. “BeyondCorp: A New Approach to Enterprise Security.” Google Cloud, 2014.

Pod Security Standards: A Security-First Guide

Max — Thu, 09 Apr 2026 16:49:44 +0000

Kubernetes Pod Security Standards

TL;DR: I enforce PSS restricted on all production namespaces: runAsNonRoot: true, allowPrivilegeEscalation: false, all capabilities dropped, read-only root filesystem. Start with warn mode to find violations, then switch to enforce. This single change blocks the majority of container escape attacks.

Imagine this: your Kubernetes cluster is humming along nicely, handling thousands of requests per second. Then, out of nowhere, you discover that one of your pods has been compromised. The attacker exploited a misconfigured pod to escalate privileges and access sensitive data. If this scenario sends chills down your spine, you're not alone. Kubernetes security is a moving target, and Pod Security Standards (PSS) are here to help.

PSS is Kubernetes' answer to the growing need for solid, declarative security policies. They provide a framework for defining and enforcing security requirements for pods, ensuring that your workloads adhere to best practices. But PSS isn't just about ticking compliance checkboxes — it's about aligning security with DevSecOps principles, where security is baked into every stage of the development lifecycle.

From PodSecurityPolicy (deprecated in Kubernetes 1.21) to Pod Security Standards, the focus has shifted toward simplicity and usability. PSS is designed to be developer-friendly while still offering powerful controls to secure your workloads.

At its core, PSS enables teams to adopt a "security-first" mindset — protecting your cluster from external threats while mitigating risks posed by internal misconfigurations. By enforcing security policies at the namespace level, PSS ensures that every pod deployed adheres to predefined standards.

From experience: Run kubectl label ns YOUR_NAMESPACE pod-security.kubernetes.io/warn=restricted first. This logs warnings without blocking deployments. Review the warnings for 1-2 weeks, fix the pod specs, then switch to enforce. I've migrated clusters with 100+ namespaces using this process with zero downtime.

Key Challenges in Securing Kubernetes Pods

Securing Kubernetes pods is easier said than done. Pods are the atomic unit of Kubernetes, and their configurations can be a goldmine for attackers if not properly secured. Common vulnerabilities include overly permissive access controls, unbounded resource limits, and insecure container images.

The core tension: developers want their pods to "just work," and adding runAsNonRoot: true or dropping capabilities breaks applications that assume root access. I've seen teams disable PSS entirely because one service needed NET_BIND_SERVICE. The fix isn't to weaken the policy — it's to grant targeted exceptions via a namespace with Baseline level for that specific workload, while keeping Restricted everywhere else.

Remember the Tesla Kubernetes breach in 2018? Attackers exploited a misconfigured pod to mine cryptocurrency. The pod had access to sensitive credentials stored in environment variables, and the cluster lacked proper monitoring. This incident underscores the importance of securing pod configurations from the outset.

Common Pitfall: Ignoring resource limits in pod configurations can lead to denial-of-service attacks. Always define resources.limits and resources.requests in your pod manifests to prevent resource exhaustion.

Implementing Pod Security Standards in Production

How do you implement Pod Security Standards effectively? Here's the breakdown:

Understand the PSS levels: Kubernetes defines three levels — Privileged, Baseline, and Restricted. Each represents a stricter set of security controls.
Apply labels to namespaces:

apiVersion: v1
kind: Namespace
metadata:
  name: secure-apps
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

Audit and monitor: Use Kubernetes audit logs to monitor compliance. The audit and warn labels identify pods that violate policies without blocking them.
Supplement with OPA/Gatekeeper: PSS covers the basics, but you'll need Gatekeeper for custom policies like "no images from Docker Hub" or "all pods must have resource limits." I run 12 custom Gatekeeper constraints on top of PSS.

My migration path: Week 1: apply warn=restricted to all production namespaces. Week 2: collect and triage warnings. Week 3: move fixed namespaces to enforce=restricted, exceptions to enforce=baseline. Week 4: add CI validation with kube-score.

For dev namespaces, I use enforce=baseline (not privileged). Even in dev, you want to catch the most dangerous misconfigurations.

CI integration is non-negotiable: run kubectl --dry-run=server against a namespace with enforce=restricted in your pipeline. If the manifest would be rejected, fail the build.

Battle-Tested Strategies

Integrate PSS into CI/CD pipelines: Shift security left by validating pod configurations during build. Tools like kube-score and kubesec analyze your manifests for security risks.
Monitor pod activity: Use Falco to detect suspicious activity in real-time — shell commands, sensitive file access, unexpected network connections.
Limit permissions: Follow least privilege. Avoid running pods as root and restrict access to sensitive resources using RBAC.

Use network policies to control traffic between pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-traffic
  namespace: secure-apps
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: trusted-app

Real incident: I've audited clusters where every pod was running as root with all capabilities because nobody set a SecurityContext. The default is insecure. PSS Restricted mode makes the secure configuration the default, not the exception.

Future Trends

Emerging security features: Kubernetes is introducing ephemeral containers and runtime security profiles to enhance pod security, reducing attack surfaces and improving isolation.

seccomp and AppArmor profiles are graduating from beta. I'm already running custom seccomp profiles that restrict system calls per workload type — web servers get a different profile than batch processors. This is the next layer beyond PSS.

Strengthening Security with RBAC

RBAC is a cornerstone of Kubernetes security. Define roles and bind them to users or service accounts to control access:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: secure-apps
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

From experience: Run kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:default for every namespace. If the default ServiceAccount can list secrets or create pods, you have a problem. I strip all permissions from default ServiceAccounts and create dedicated ones per workload.

Key Takeaways

Pod Security Standards provide a declarative way to enforce security policies in Kubernetes
Common pod vulnerabilities include excessive permissions, insecure images, and unbounded resource limits
Use OPA, Gatekeeper, and Falco to automate enforcement and monitoring
Integrate PSS into CI/CD pipelines to shift security left
Start with warn mode, then move to enforce — never skip the audit phase

Have you implemented Pod Security Standards in your clusters? Share your experiences or horror stories — I'd love to hear them.

Originally published at orthogonal.info

The Google Play 12-Tester Wall: A Solo Dev's Guide (and a Plea for Help)

Max — Tue, 07 Apr 2026 18:41:50 +0000

The Problem Every Solo Dev Hits

You build your app. You polish it. You upload it to Google Play Console. And then... you discover the 12-tester requirement.

Google requires new developer accounts to have at least 12 unique testers opted into your internal testing track for 14 continuous days before you can publish to production. For big companies with QA teams, this is nothing. For solo devs? It's a wall.

I'm currently stuck behind that wall with two apps and just 1 tester (myself). I've been stuck for two weeks.

What I Built

FocusForge 🎯

A minimal focus timer. No account required, no cloud sync, no ads. Just a clean Pomodoro-style timer that tracks your deep work sessions locally. I built it because every other focus app wanted me to create an account and pay $5/month for what is essentially a countdown timer.

NoiseLog 🔊

Measures and logs ambient noise levels using your phone's microphone. I originally built this to document a noisy neighbor situation, but it turned out useful for:

Finding the quietest seat in coffee shops
Tracking if construction noise exceeds legal limits
Understanding your daily noise exposure patterns

Both apps are free, no ads, no data collection, no weird permissions.

What I'm Asking

If you have an Android phone (any recent version), joining takes about 60 seconds:

Click one of the internal testing links below
Sign in with your Google account
Install the app from the Play Store page
Keep it installed for ~14 days

That's it. You don't even need to actively use it (though feedback is welcome). You're just helping me get past Google's gatekeeper.

Join links:

Tips for Other Devs in the Same Boat

If you're also stuck at the 12-tester wall, here's what I've learned:

Start recruiting testers early — don't wait until your app is "ready." The 14-day clock only starts when people opt in.
Family and friends are your fastest path — but many won't have Android.
r/betatesting and r/playmyapp on Reddit are purpose-built for this.
FeatureGate.de is a free mutual-testing platform — test 3 apps, earn the right to post your own.
TestersCommunity.com charges $15 for 25 testers with a production access guarantee if you want the fast track.
Dev.to and IndieHackers — you're reading this, so you know these communities exist. Post your story.

The requirement exists to filter spam, and I get that. But it's one of those things where the cure is worse than the disease for legitimate solo devs.

Help a Dev Out

If you joined one of the tests above: thank you. Seriously. Every tester gets me one step closer to actually shipping these apps.

If you've been through the same struggle, drop a comment — I'd love to hear how you solved it.

DEV Community: Max

Build an Unusual Options Activity Scanner With Python and Free Data

What Counts as "Unusual"

The Data Problem (and Three Free Solutions)

Option 1: Tradier Sandbox API (My Pick)

Option 2: Yahoo Finance (yfinance)

Option 3: Polygon.io Free Tier

The Scanner: 200 Lines That Actually Work

What I Learned Running This for 6 Months

The Full Setup on a Raspberry Pi

Should You Actually Trade on UOA?

Full Stack Monitoring: A Security-First Approach

Introduction to Full Stack Monitoring

The Role of Full Stack Monitoring in Kubernetes

DevSecOps and Full Stack Monitoring: A Perfect Match

Advanced Monitoring Techniques

Future Trends in Full Stack Monitoring

Frequently Asked Questions

What is full stack monitoring?

Why is a security-first approach important in monitoring?

What are the key components of full stack monitoring?

How does full stack monitoring integrate with DevSecOps principles?

TrueNAS Setup Guide: Enterprise Security at Home

Introduction to TrueNAS and Homelab Security

Planning Your TrueNAS Setup

Hardware Requirements and Recommendations

Choosing the Right TrueNAS Version

Network Considerations

Installation and Initial Configuration

Installing TrueNAS

Configuring Storage Pools and Datasets

Setting Up User Accounts

Implementing Enterprise-Grade Security Practices

Enabling Encryption

Configuring Firewalls and VPNs

Regular Updates and Patching

Maintenance and Best Practices

Monitoring System Health

Automating Backups

Periodic Security Audits

Scaling Up: Future-Proofing Your Homelab

New Section: Integrating TrueNAS with Other Services

Media Servers

Virtualization Platforms

New Section: Advanced Troubleshooting

Performance Issues

Access Problems

Frequently Asked Questions

What’s the difference between TrueNAS CORE and SCALE?

Can I use consumer-grade hardware for TrueNAS?

How do I secure remote access to TrueNAS?

What’s the best way to back up TrueNAS data?

Key Takeaways

References

Related Reading

Track Congressional Stock Trades with Python and Free SEC Data

Why Congressional Trades Matter

Where the Data Lives

The Python Script

Filtering for Signal

Setting Up Daily Alerts

What I’ve Learned Running This for 6 Months

Alternatives and Paid Tools

Extending It

CSS Gradient Builder: Fixing Annoyances of Existing Tools

The Problem With Existing Gradient Tools

What GradientForge Actually Does

How I Built It

The URL State Trick

Privacy and Performance

12 Built-In Presets

Dark Mode and Mobile

What's Next

FAQ

Does GradientForge support conic gradients?

Is GradientForge free to use?

What browsers support conic gradients?

References

OpenClaw Setup: Zero to Autonomous AI Mastery

What Makes OpenClaw Different