标签：#DevOps

1. Retomando: do docker run repetido a um arquivo único No artigo anterior, subir uma API e um Postgres conectados exigiu dois comandos docker run longos, com flags de rede, volume e variáveis de ambiente para lembrar (e digitar) toda vez. Em um projeto real, com mais serviços — cache, fila, worker em background — isso rapidamente vira inviável de manter na cabeça ou em um script solto. O Docker Compose resolve isso descrevendo toda a aplicação multi-container em um único arquivo declarativo, versionado junto com o código. 2. O arquivo compose.yaml Compose lê um arquivo YAML (por convenção compose.yaml , ou o nome legado docker-compose.yml , ainda amplamente usado) descrevendo serviços (cada um vira um ou mais containers), redes e volumes: # compose.yaml services : api : build : . ports : - " 8000:8000" environment : DATABASE_URL : postgresql://postgres:segredo@banco:5432/postgres depends_on : - banco banco : image : postgres:16 environment : POSTGRES_PASSWORD : segredo volumes : - pg-dados:/var/lib/postgresql/data volumes : pg-dados : Isso substitui inteiramente os dois docker run do artigo anterior. Uma diferença importante já aparece aqui: por padrão, Compose cria uma rede própria para o projeto e conecta todos os serviços a ela automaticamente — não é preciso um docker network create manual, nem declarar --network em cada serviço. Cada serviço já é acessível pelos demais pelo nome declarado em services: (aqui, banco resolve para o container do Postgres), exatamente como as redes definidas pelo usuário do artigo anterior. 3. Comandos essenciais do Compose docker compose up -d # sobe todos os serviços em segundo plano docker compose ps # lista os containers do projeto e seu status docker compose logs -f api # segue os logs de um serviço específico docker compose logs -f # segue os logs de todos os serviços, intercalados docker compose exec api bash # abre um shell dentro do container de um serviço docker compose stop # para os containers sem removê-los docker comp

Dario Amodei Is Right. But He Is Missing the Hard Part. Dario Amodei said the first billion-dollar company with one employee would appear in 2026. He put 70-80% probability on it. I am not building a billion-dollar company. But I am running something that does the work of several teams: 86 containers, 24 databases, 240 cron jobs, two servers, one person. Amodei is right that this is now possible. The tools exist. The costs dropped. A full AI stack costs me between $3,000 and $12,000 per year. The equivalent in human headcount would run $80,000 to $120,000 per month. But the headline version of the "one-person company" story skips the hard part. It sounds like you hire an AI, fire your team, and go make money. That is not what happened for me. What actually happened was eighteen months of building a system that makes "one person" sustainable at 3 AM when something breaks and nobody is awake to fix it. Here is what that system looks like in practice. The Stack Is Not the System Most people stop at the stack. They pick Claude or GPT, wire up a few automations, and call it an AI-powered business. That works until the first thing breaks in a way the model did not anticipate. The stack I run includes SaaS apps for golf clubs, a school management platform, an auth provider, a CRM, a community platform, and several tools for my own operations. Each of these runs in Docker containers managed by Coolify, spread across two Hetzner servers in Germany. That part is table stakes. Any competent developer can set up containers. The system is what sits on top. It is what makes the difference between "one person with a lot of tools" and "one person running a business that actually works." Guard Rules: The Thing That Catches What You Miss I wrote about this in detail in Runs Without Me : the biggest risk in a one-person setup is not that the AI does something wrong. It is that you do not notice until hours or days later. My setup uses 177 guard files that intercept operations before t

Cómo solucionar docker run con Exited (1) en Raspberry Pi ¿Por qué ocurre este error? El código de salida 1 indica que el proceso principal del contenedor terminó con un error genérico. En Raspberry Pi, los casos más comunes son: Arquitectura incompatible : La imagen fue construida para amd64 (x86_64), pero Raspberry Pi usa arm32v7 o arm64v8 . Falta de binarios compatibles : El ENTRYPOINT o CMD del contenedor intenta ejecutar un binario compilado para otra arquitectura. Problemas de permisos o dependencias faltantes en el entorno embebido (especialmente en Raspberry Pi OS Lite sin GUI). Uso incorrecto de --net=host : En algunas versiones de Docker en Raspberry Pi, el flag --net=host puede causar fallos si el sistema no lo soporta correctamente. 🔍 Nota crítica : En tu comando original docker run --net = host -d -t myimage , hay un error de sintaxis: --net = host tiene espacios alrededor del = . Docker lo interpreta como un nombre de red literal " = host" , lo que probablemente falla. Pasos para solucionarlo Paso 1: Corrige la sintaxis del comando # ❌ Incorrecto (con espacios en `--net`) docker run --net = host -d -t myimage # ✅ Correcto (sin espacios) docker run --net host -d -t myimage ⚠️ Importante : En Docker CLI, los flags con valores no deben tener espacios entre el = . Usa --net=host o --net host , pero nunca --net = host . Paso 2: Verifica la arquitectura de la imagen Ejecuta en tu Raspberry Pi: docker inspect myimage --format '{{.Architecture}}' Si el resultado es amd64 , la imagen no es compatible con Raspberry Pi . Solución: Reconstruir la imagen para ARM Si tienes el Dockerfile , usa multi-arch build: # Al inicio del Dockerfile (antes de FROM) # syntax=docker/dockerfile:1 FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder ... O construye explícitamente para ARM: # En tu máquina de desarrollo (x86_64) docker buildx create --use docker buildx build --platform linux/arm/v7 -t myimage:armv7 . --push # o para Pi 4 (64-bit): docker buildx build --platf

Forbes Called It a Playbook. I Call It a Production Log. Forbes published a piece recently calling AI agent startups "the new solo-founder playbook." I read it twice. The framing bothered me both times. A playbook implies steps. A sequence. Something you can hand to someone and say: follow this, and you will get the result. What Forbes described is not that. It is a description of an outcome, written by people who did not have to fix anything at 2 AM when the agent broke. Let me tell you what it actually looks like. The Night 871 Emails Went to the Wrong People Fourteen months ago I built my first agent that could send emails on behalf of the system. It was an outreach automation, nothing exotic. The agent would identify leads, draft a message, and send it after a human approval step. Except the approval step had a race condition. Two concurrent jobs both read "pending" from the database, both approved, and both dispatched. One lead received 871 emails over 40 minutes before I caught it. No company, no legal team, no PR buffer. Just me and an inbox full of angry replies. That night I wrote my first hard guardrail: #!/bin/bash # email-dedup-guard.sh LEAD_ID = " $1 " LOCK_FILE = "/tmp/email-lock- ${ LEAD_ID } " if [ -f " $LOCK_FILE " ] ; then echo "BLOCK: email already dispatched for lead ${ LEAD_ID } " > &2 exit 1 fi touch " $LOCK_FILE " # proceed with send Embarrassingly simple. But I did not know I needed it until I needed it. This is what Forbes leaves out. The playbook is written in retrospect, after someone else absorbed the cost of learning. The Model Is Not the Problem Every conversation about AI agents eventually becomes a conversation about which model to use. GPT-4 versus Claude versus Gemini. Benchmarks and context windows and reasoning scores. Here is what I learned: the model is the easy part. My current system runs 86 containers across two Hetzner servers. 240 automated jobs. Every day, these jobs do things: post content, process leads, trigger builds,

Nikolay Samokhvalov has developed PGSimCity, an open-source educational tool that visualises PostgreSQL mechanics as a 3D spatial simulation in the browser. It assists backend developers and site reliability engineers in understanding SQL and the dynamics of kernel execution. The project is available on GitHub and aims to enhance understanding of database architecture through interactive elements. By Olimpiu Pop

GitHub Actions is GitHub's built-in CI/CD system — it spins up a fresh virtual machine, runs whatever commands you tell it to, and tears the machine down when it's done. It supports Linux, Windows, and macOS runners. The macOS runners are the interesting part here, because they're actual macOS machines with Xcode's command-line build tools available, which means they can build and sign iOS apps — not just run tests. The headline rule: public repos are free On a public repository, standard GitHub-hosted runner minutes — including macOS — don't cost anything, on any plan, including the free plan. It's a genuine free tier, not a trial or a limited allowance that runs out. One nuance: this covers standard runners. GitHub also offers "larger runners" (more CPU/RAM) — those are billed regardless of repo visibility. A default macOS build for signing and archiving a typical app doesn't need one, so this rarely matters in practice. What changes on a private repo If your repository is private, you get a monthly allowance of free minutes instead of unlimited free usage: Plan Included minutes / month Free 2,000 Pro 3,000 Team 3,000 The number that actually matters for iOS builds is how fast macOS runners burn through that allowance. macOS minutes cost roughly 10x GitHub applies a multiplier against your included minutes: Linux runners run at the baseline rate, macOS runners run at roughly 10x that rate. A 6-minute macOS build eats through the same allowance as roughly 60 minutes of Linux CI. Applied to the table above, a Free-plan private repo effectively gets around 200 macOS-runner-minutes worth of free build time per month before you're billed per minute past it (Pro/Team works out to roughly 300). The practical upshot: if you're fine building in the open, a public repo gets you unlimited macOS build minutes at zero cost, indefinitely. If you'd rather keep the code private, everything about the pipeline still works the same way — you're just drawing from a metered allowance

Watch a developer start an agent session on real enterprise work and you will see a ritual. Before the first useful prompt, they gather. They paste the deployment standard, link the runbook, and explain what the criticality tiers mean. Then they correct the agent's first confident guess about a naming convention the team retired two years ago. Tomorrow they will do it all again, because the agent will not remember. We have quietly decided that this gathering is the developer's job. Every guide to working with AI repeats some version of the same advice: give the model good context. So developers hunt for it, one session at a time, across systems that were never designed to answer an agent's questions. I think that framing is backwards, and I think fixing it is platform work. In Your Platform Has a New User: The Agent , I argued that internal platforms now serve two personas: the developer and the developer's agent. Near the end, I wrote that context is becoming part of the platform. I called it one of the most important developer experience problems of the next few years. That idea got four paragraphs. It deserves an essay, so here is the longer version. The gathering is the tax Agents can remember more than they used to. What they cannot reliably accumulate on their own is organizational truth. A new engineer pays the onboarding cost once, then amortizes it over years of context, hallway conversations, and scar tissue. An agent may retain instructions, memory, or project state. None of those automatically tell it which standard is authoritative, which exception still applies, or which decision was reversed six months ago. Whatever it needs to know about your organization still has to come from somewhere. Now multiply that across hundreds of engineers. People rediscover the same standards, fork the same repo, re-paste the same runbooks, and retype the same corrections, day after day. Quality varies too. Your strongest engineers assemble excellent context and get exce

When a build breaks, the bug fixes itself We stopped babysitting CI failures. Now a red build files its own bug — and an AI agent picks it up and ships the fix. PROBLEM — A failed build told no one Our CI would fail, and then… nothing would happen. The failure sat quietly in a build console that nobody keeps open. Eventually someone would notice a change hadn't gone out, go digging, and realize the build had been red for hours. And noticing was the easy part. Actually resolving it meant a whole code session: pull up the logs, find the failing step, reproduce it, and have an engineer sit down and personally shepherd the fix from broken to green. Every red build cost real human hours — plus the invisible tax of the delay before anyone even knew there was a problem. The true cost of a broken build was never the build. It was a person having to find it, understand it, and hand-fix it. SOLUTION — The failure files its own ticket — and an agent takes it from there Now nobody watches a console and nobody triages. The moment a build fails, it automatically files a bug in Shipeasy — our ops platform — as a real, prioritized ticket with the failing step, the branch, and a link to the logs already attached. From there it leaves human hands entirely. Shipeasy hands the bug to an AI agent, which investigates the failure, writes the patch, and opens a pull request against it. The loop that used to be "human notices → human reads logs → human fixes" is now "build fails → bug appears → agent fixes." The engineer's job shrank to reviewing a PR that already exists. DESIGN — How the whole thing hangs together The pipeline is deliberately boring — every hop is either something the cloud already does for free, or a service we already run: Cloud Build — build fails: a red deploy on main publishes automatically Pub/Sub topic → push subscription: filters to FAILURE · TIMEOUT · INTERNAL_ERROR HTTPS POST /webhooks/cloud_build Webhooks::CloudBuildController: verify token · decode · dedupe by

Gate your CI on a dollar ceiling, not a percentage — the number your finance team actually asks for Most cost gates for agent/LLM workflows check a delta : did this PR make the run more expensive than the last one, by more than X%? That's a good regression alarm. But it answers a developer's question ("did I make it worse?"), not a budget owner's question ("are we going to blow the monthly number?"). Those are genuinely different gates, and a team that only has the percentage one keeps getting surprised. A workflow can pass every percentage check — each PR adds a harmless-looking 3% — and still cross the line where the absolute monthly spend stops being okay. Percentages compound quietly; dollars are what shows up on the invoice. So the second gate I want on any agent workflow is an absolute ceiling : "a single run of this job must not cost more than $N," full stop, regardless of whether it went up or down since yesterday. Three things make that gate actually usable rather than theater: 1. The ceiling is priced, not token-counted. "Under 2M tokens" is meaningless to the person who signs off on spend, because a token of Opus output and a token of cached Haiku input differ by ~100× in price. The gate has to multiply each token bucket (input, output, cache-write at ~1.25×, cache-read at ~0.1×) by that model's real per-token price and sum to an actual dollar figure. If your gate reports tokens and makes a human convert, nobody converts, and the ceiling drifts. 2. The ceiling is per-run and per-workflow, not global. A nightly full-repo audit and a per-PR lint agent have wildly different legitimate costs; one global number is either too loose for the small job or too tight for the big one. You want to set max-usd on the specific workflow, so each job carries the ceiling that matches what it's for . 3. It shows the headroom, not just pass/fail. "$0.43 of a $0.50 ceiling — 86%" on every run is the line that lets you move the limit before it starts failing builds, instead of

The difference between a good infrastructure troubleshooter and someone who restarts services and hopes is a mental model. When "HTTPS times out" lands in your inbox, you don't guess — you know exactly which layer to interrogate first, and in what order. The network is a stack, so treat it like one Every request rides through the same layers, top to bottom: Application → TLS → Port → DNS → Gateway → Route → Interface That's the dependency order — TLS can't work if the port is closed, the port is meaningless if DNS resolved to the wrong host, and none of it matters if your interface has no IP. So you verify in the inverse order, from the ground up: Interface → IP → Route → Gateway → DNS → Port → TLS → Application Start at the bottom because a broken lower layer produces confusing symptoms higher up. Confirm each layer is healthy before you climb. The moment a layer fails, you've found your problem — everything above it is a red herring. Walk it: "HTTPS to api.example.com times out" 1. Interface — do we have a link and an address? ip addr show Look for your primary interface (say eth0 ) in state UP with an inet line like 192.168.1.20/24 . No inet ? DHCP failed or the link is down — stop here, nothing above will work. If the address is present and sane, climb. 2. Route — is there a path to the destination? ip route get 93.184.216.34 This shows the exact route the kernel would pick, including the source IP and gateway ( via 192.168.1.1 dev eth0 src 192.168.1.20 ). If you get "Network is unreachable" or no default route, you've found it. This is also the signature behind the classic curl error "No route to host." 3. Gateway — can we reach the first hop? ping -c3 192.168.1.1 ip neigh show ping tests reachability; ip neigh shows the ARP table. A gateway entry in state REACHABLE with a MAC address means L2 is fine. FAILED or INCOMPLETE means the gateway isn't answering ARP — a VLAN, cabling, or firewall problem. Note that many hosts drop ICMP, so treat a failed ping as a hi

The Quest Begins (The "Why") I remember the first time I tried to take a weekend side‑project from my laptop to something that felt “real”. I had a cute Express API that talked to Postman, a PostgreSQL container spun up with docker-compose up , and a React front‑end that lived in its own dev server. Everything worked beautifully … until I hit Ctrl+C on my laptop and the whole thing vanished. I needed a way to say, “Hey, keep this running even if I close my laptop, and if something crashes, bring it back up automatically.” I started poking at Docker Swarm, then Nomad, but the docs felt like reading ancient runes. That’s when a coworker slid over a Slack message: “Just try a Kind cluster. It’s K8s locally, and you’ll see why everyone talks about it.” Spoiler: it felt like discovering the secret level in a classic arcade game. Suddenly I could describe what I wanted my system to look like, and the cluster would make it happen — no more babysitting containers. The Revelation (The Insight) Kubernetes isn’t a mystical black box; it’s a declarative orchestrator . You tell it the desired state of your application (how many replicas, which image, what ports to expose) and it works relentlessly to match reality to that state. If a pod dies, Kubernetes spins up a new one. If you ask for three replicas and only two are running, it creates the missing pod. If you update the image tag, it rolls out the change pod‑by‑pod, keeping traffic flowing. Think of it like the save‑game system in a RPG: you define the story you want to experience, and the engine handles the gritty details of loading, saving, and recovering from crashes. The core objects you’ll meet early on are: Pod – the smallest deployable unit (one or more tightly coupled containers). Deployment – manages a set of identical pods, handles updates and rollbacks. Service – a stable network endpoint that load‑balances traffic to a set of pods. Ingress (optional) – exposes HTTP/HTTPS routes from outside the cluster to service

1. Retomando: de imagens bem construídas a containers que conversam entre si Os artigos anteriores desta série cobriram como criar imagens eficientes e rodar containers isolados. Mas uma aplicação real raramente é um único container: normalmente há uma API, um banco de dados, um cache, talvez uma fila de mensagens — cada um em seu próprio container, precisando se comunicar. E containers, por padrão, são efêmeros: qualquer dado escrito dentro deles some quando são removidos. Este artigo cobre as duas peças que resolvem isso: redes (comunicação entre containers) e volumes (persistência de dados). 2. O problema do isolamento de rede por padrão Cada container recebe seu próprio namespace de rede, isolado dos demais e do host. Isso é uma característica de segurança, não um bug — mas significa que dois containers rodados de forma independente não conseguem se encontrar automaticamente: docker run -d --name api minha-api docker run -d --name banco postgres De dentro do container api , tentar acessar banco por esse nome simplesmente falha — cada container, isolado, só enxerga localhost como a si mesmo. A solução do Docker para isso é criar uma rede e conectar ambos os containers a ela. 3. Redes definidas pelo usuário (User-Defined Networks) docker network create minha-rede docker run -d --name banco --network minha-rede postgres docker run -d --name api --network minha-rede minha-api A partir daqui, dentro do container api , o hostname banco resolve automaticamente para o IP do container banco — o Docker roda um DNS interno para qualquer rede definida pelo usuário, resolvendo containers pelo nome (ou pelo alias definido com --network-alias , se houver mais de um). Isso é o motivo pelo qual strings de conexão em aplicações containerizadas costumam usar o nome do serviço em vez de um IP fixo: DATABASE_URL = postgresql :// usuario : senha @ banco : 5432 / meudb Comandos úteis para inspecionar redes: docker network ls # lista todas as redes docker network inspect minha-rede # d

How we turned always-on Kafka sinks into on-demand workers that shrug off nightly bombardments — by scaling on the right signal, tuning per-pod drain rate, and keeping autoscaling from sabotaging itself. Every number in this post is measured from a local lab you can run yourself — the full code is on GitHub , and the Appendix has the commands. The problem We run a fleet of Kafka sinks — consumer services that read change events from Kafka, apply business logic, and write the result into a service-local database as a query-friendly materialized view. It keeps reads fast and independent from upstream systems, and it's a great pattern. But the workload has an awkward shape. Most sinks are idle most of the day, then buried in minutes. Traffic isn't steady: changes arrive in bursts, usually from nightly imports or CDC jobs. The rest of the day the topic is quiet. topic activity over 24h msgs ▲ │ ██ nightly import / CDC burst │ ██ │______________██______________ flat, idle ~22h/day └───────────────────────────────▶ time That shape creates two problems at once : Idle waste. When the topic is quiet, each sink still runs — it polls Kafka, holds connections, emits metrics, and occupies CPU and memory. Multiply one "small" sink across dozens of them and several regions, and you're paying around the clock for work that happens for a couple of hours a night. Spike lag. When the burst lands, a backlog builds fast. If consumers can't drain it quickly enough, consumer lag — the gap between what's been produced and what's been processed — climbs, and downstream reads start serving stale data. We want two things that sound contradictory: cost almost nothing when idle , and absorb the spike fast when it hits. Why the obvious autoscaler doesn't help The reflex is a Kubernetes Horizontal Pod Autoscaler (HPA) on CPU or memory. For sinks, that's the wrong signal. Sink work is I/O-bound : the consumer spends its time waiting on Kafka polls and database writes, not burning CPU. So when a ba

A small team shipped a CSV validation service. It passed on a workstation. It died three seconds after starting on a free server. This article reconstructs that failure as a reproducible case. It is not a benchmark and not a product review. The point is to show a workflow for finding display dependencies before they reach production. Two availability points made the loop cheap: free model access to draft a fix and a free server option to run headless checks. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The article does not assert model names, quotas, hardware, or uptime guarantees beyond those availability points. The case began with a small request. The service needed to read a CSV file, reject rows with missing columns, and write a short JSON report. The requirement said nothing about a desktop interface. The generated entry point looked ordinary. def main ( argv = None ): args = parse_args ( argv ) if not args . input : from tkinter import Tk from tkinter.filedialog import askopenfilename root = Tk () root . withdraw () args . input = askopenfilename () validate_csv ( args . input ) The local smoke test passed because it always supplied a file. python csv_check.py --input sample.csv That path never touched the fallback. The application then moved to a free server where the default start command had no file argument. The server process reached the Tk() call and failed. _tkinter.TclError: no display name and no $DISPLAY environment variable The problem was not a hallucinated algorithm. The model added a graphical file picker as a hidden fallback. On the workstation that fallback was harmless. On a headless server it was a startup-time dependency. A code review might have missed it because tkinter is a standard-library module and the fallback looked like convenience logic. The environment mismatch only became visible when the no-argument path ran on a machine without a display. The team turned the failure into a deploy gate. The fi

Your agent reports “done — all tests pass.” Do you believe it? Nothing in that sentence is evidence, and the cost of finding out lands on you, later. I’ve been building with AI coding assistants for years, and the failure that kept costing me time was never that the model wrote bad code. It was that the model told me it was done, and I believed it. This post is the mechanism I built so I don’t have to — written out in enough detail that you can judge whether it would hold up against your own agent. Ranex is a kernel — ordinary, inspectable code — that stays outside the AI’s loop and judges every step of its work. It never asks a model what to do next. Rules an agent can read are suggestions; rules compiled into code are constraints. The problem is not that AI writes bad code An AI writing software is a blindfolded dart thrower with a guide shouting coordinates. Two things go wrong, and they’re separate problems: The thrower is blind. It cannot perceive whether its own dart landed, so it reports success either way. The guide is bad. The coordinates were wrong or vague before the throw. There’s a third failure, and it’s the most common one: Most tools let the thrower paint the bullseye around the dart after it lands. One actor writes the code, writes the test, and declares success. That’s why “all tests pass” from an AI means so little — the target moved to wherever the dart went. Notice that none of this gets fixed by a better model. A more capable agent paints a more convincing bullseye — so upgrading the model you point at your repo does not touch this. That’s why I stopped trying to improve the throw and started working on the scoring. Three ports, and only one produces a verdict The architecture is deliberately boring: Model port — one completion, forced structured output. Intake, review, translating machine state into plain language. Stateless. Worker port — an agent with its own loop and tools, running in an isolated git worktree. Returns a diff. Replaceable by

Container Image Signing & SLSA Provenance Verification with Sigstore Cosign Supply chain security guide on signing OCI container images keylessly and verifying SLSA build provenance using Sigstore Cosign and Rekor. Executive Summary & Key Takeaways Keyless Image Signing: Sign OCI container images in CI/CD using OIDC identity tokens (Fulcio CA) without managing private keys. Immutable Transparency Log: Record signature metadata in the public Rekor transparency log to prevent signature tampering. SLSA Provenance Attestation: Attach cryptographically signed SLSA build provenance attestations to container images. Kyverno Policy Enforcement: Block un-signed or non-compliant container images from running in Kubernetes clusters. 1. Software Supply Chain Risks & Container Image Signing Container registries (Docker Hub, GHCR) store execution binaries for enterprise applications. If an attacker compromises CI/CD credentials or registry access, they can replace legitimate container tags with malicious images containing backdoors. Sigstore Cosign eliminates supply chain tampering by cryptographically signing OCI container images during the CI/CD build process. Using keyless signing powered by Fulcio (certificate authority) and Rekor (transparency log), Cosign binds OIDC identities (e.g., GitHub Actions workflow identity) to container digests without long-lived private keys. This ensures that container images running in Kubernetes can be traced back to exact GitHub workflow runs. Keyless signing eliminates the security liability of storing long-lived signing keys in CI/CD secrets. Cryptographic digest binding guarantees that tag overwrite attacks are detected immediately by container runtimes. Implementing automated continuous monitoring across production nodes ensures that compliance policies remain enforced during infrastructure updates. Regular security audits should be integrated into DevOps CI/CD pipelines to verify that system configurations conform to zero-trust architect

Here is why this article is worth your time: you cannot tell what a generated setup script does by reading the diff. A diff shows you the words that will run, not the files that will be touched, the network connections that will be opened, or the directories that will be wiped at execution time. For a small patch, manual review may be enough. For a server initialization or cleanup script produced by a free model, the danger is in the side effects you never see in the source. This guide turns that problem around. Instead of trying to predict behavior from generated code, you run the code inside a fake root filesystem and record the operating system calls it makes. The technique uses honeypot files, a minimal chroot, and strace to produce a syscall journal. It works especially well when you can generate the script with a free model and run it on a free Linux box that you are allowed to throw away afterward. Disclosure: This article was prepared as part of MonkeyCode's product outreach. If you have MonkeyCode's free model access and free server option available, you can use that server as the throwaway Linux box described in the examples below. The commands assume a Linux host where you can install strace and have root privileges, which is common for a disposable cloud instance or a small virtual machine you control. Build a fake root before you run anything Create a directory that will act as a minimal root filesystem. You do not need a full distribution; you only need enough structure for the script to attempt its operations and for you to watch what it touches. mkdir -p fake_root/bin fake_root/tmp fake_root/var/log fake_root/home/user fake_root/.ssh Inside this fake root, place simple executable stubs so that commands like ls , cat , and rm do not fail immediately. Use /bin/sh from the host in the chroot command later, or copy a static shell into the fake root if available. The important part is not completeness; it is observability. Create executable placeholders f

85 containers. 24 PostgreSQL databases. 67 domains. 232 cron jobs. One developer. 120 EUR/month in Hetzner bills. This is not a startup fantasy pitch. This is my production infrastructure for a SaaS ecosystem serving German golf clubs, a golf school management platform, a community platform, a CRM, and an auth service. Every customer gets their own database. Physical tenant isolation, not software filters. People tell me this cannot work. The containers disagree. The Stack Next.js for all frontends. Single-tenant PostgreSQL per customer (Supabase stacks). Docker on bare metal. Coolify for deployment orchestration. Traefik as the reverse proxy handling 67 domains. Two Hetzner servers in Germany. Total infrastructure cost: 120 EUR/month. The single-tenant architecture is a deliberate trade-off. Multi-tenant saves infrastructure cost, but one RLS bug exposes every customer's data. One compromised tenant enables lateral movement to all others. GDPR Article 17 deletion in multi-tenant requires complex cross-tenant queries. In single-tenant, deletion is DROP DATABASE . No residual risk. The cost is more operational complexity. Which is exactly why automation is not optional. 176 Guard Rules: The Immune System My AI agents (Claude Code with custom hooks) execute roughly 80% of daily development and operations work. That is dangerous without constraints. So I built a guard system: 176 shell scripts that fire on every command, every file edit, every session end. The architecture is simple. Four dispatchers route to context-specific guards: #!/bin/bash # Pre-Bash-Dispatcher: Loads guards based on command profile. # Not all 176 guards fire on every command. Profiling classifies # each command (git, docker, npm, database, deploy, comms) and # loads only relevant guards. set -uo pipefail GUARDS_DIR = " $( dirname " $0 " ) /guards" INPUT = $( cat ) CMD = $( echo " $INPUT " | jq -r '.tool_input.command // ""' ) # 8 security gates fire ALWAYS, non-negotiable: # tabu-gate, pii-gate,

Learn how containers communicate with each other and how to keep data alive even after containers are removed. Modern applications rarely run as a single container. A typical application might include a web application, a database, a cache layer, and background workers. For these services to work together, containers need a reliable way to communicate and share data. In this article, we'll learn: How Docker networking works How containers discover each other Docker network drivers Persistent storage with Docker volumes Essential networking and volume commands A real-world multi-container example By the end, we'll understand two of the most important concepts in Docker: networking and data persistence . Why Docker Networking Matters Every container runs inside its own isolated network namespace. This isolation improves security and prevents conflicts, but it also creates an important challenge: If containers are isolated, how does a web application connect to a database? Imagine a web application running inside one container and MongoDB running inside another. Without networking, they cannot communicate. Docker solves this problem using Docker Networks . A Docker network allows containers to communicate with each other while remaining isolated from unrelated containers. Web App Container | v Docker Network | v Database Container Without a shared network, containers cannot easily find or communicate with each other. Docker Network Drivers Docker supports several network drivers, but most developers primarily use three. Bridge Network A bridge network creates a private virtual network on the Docker host. Containers connected to the same bridge network can communicate with each other securely. Create a custom bridge network: docker network create my-app-network Benefits of bridge networks: Container-to-container communication Isolation from other applications Built-in DNS resolution Easy management For most Docker projects, a user-defined bridge network is the recommend

High-Speed eBPF/XDP Packet Filtering for Linux Server DDoS Mitigation Executive Summary Executive Summary & Key Security Takeaways ← Back to Articles Linux Kernel • XDP DDoS Defense High-Speed eBPF/XDP Packet Filtering for Linux Server DDoS Mitigation By Zyekh Abdul Qadir Jailani Published: 2026-08-04 15 min read (1750+ Words) Share Download .md Download .pdf eBPF/XDP Driver-Level Packet Ingestion & Ultra Fast Packet Dropping Executive Summary & Key Security Takeaways XDP_DROP Early Decision: Drop malicious UDP/SYN floods before allocating sk_buff memory. Kernel Map Invalidation: Dynamic IP blocklists via eBPF BPF_MAP_TYPE_HASH maps. Zero-Copy Performance: Process 10M+ packets per second on commodity server hardware. Clang/LLVM BPF Compilation: Build C programs directly into BPF bytecode targets. Table of Contents Understanding XDP Architecture vs Traditional Linux SKB Allocation XDP Packet Processing Actions (XDP_DROP vs XDP_PASS) Writing a Production XDP Packet Filter in C Compiling & Loading Bytecode Targets via Clang/LLVM Dynamic Blocklist Management via BPF Maps High-Throughput Packet Benchmark Verification Frequently Asked Questions (FAQ) 1. Understanding XDP Architecture vs Traditional Linux SKB Allocation Standard Linux network processing allocates a complex kernel socket buffer data structure (sk_buff) for every incoming packet before firewall rules (iptables/nftables) can evaluate the packet. Under volumetric DDoS attacks (such as 10 Million Packets Per Second UDP floods), the CPU time spent allocating and freeing sk_buff structures exhausts kernel memory and CPU cache lines, causing severe packet drops and server unresponsiveness. eXpress Data Path (XDP) provides a high-performance bare-metal packet processing framework. XDP programs execute eBPF bytecode directly inside the network driver's RX ring buffer before sk_buff memory allocation occurs. # Inspect network interface driver XDP support ip link show eth0 2. XDP Packet Processing Actions (XDP_DROP vs