标签：#DevOps

Grafana Labs has announced general availability for two tools that let AI coding agents query live observability data during development: the gcx CLI and the Grafana MCP server. Both allow agents to pull metrics, logs, traces, SLOs, and Synthetic Monitoring results from Grafana Cloud or a self-hosted stack By Claudio Masolo

The Quest Begins (The “Why”) Honestly, I used to stare at my CI/CD yaml files like they were ancient runes. Every push felt like a gamble: “Will the build pass this time?” I’d spend Friday nights hunting down a missing node_modules cache in Jenkins, only to realize the agent had run out of disk space because I’d forgotten to add a cleanup step. The pain was real, and the feedback loop was slower than a dial‑up modem. I kept asking myself: Why does this feel like wrestling a dragon every time I want to ship a feature? The answer was simple—I hadn’t yet found a pipeline that just worked out of the box. I wanted something that gave me confidence, not anxiety. So I embarked on a quest to compare the three big contenders: GitHub Actions, GitLab CI, and good ol’ Jenkins. Spoiler: the treasure wasn’t in the tool itself, but in how you shape the pipeline around your team’s flow. The Revelation (The Insight) The big “aha!” moment came when I stopped treating CI/CD as a one‑size‑fits‑all script and started seeing it as a contract between my code and my environment. The contract says: Every commit gets a clean slate. Dependencies are restored, not guessed. Tests run in parallel, not sequentially. Artifacts are published only if the gate passes. When I wrote that contract down, the yaml stopped looking like magic incantations and started looking like a checklist. The tools differ in syntax, but the underlying principles are the same. Here’s the secret: cache wisely, fail fast, and keep the pipeline short enough to give you feedback before you’ve even finished your coffee. Wielding the Power (Code & Examples) Below are three pipelines—one for each platform—that embody the contract above. I’ll first show a “struggle” version (the common pitfalls) and then the victorious version. 1. GitHub Actions – The Struggle name : CI on : [ push , pull_request ] jobs : build : runs-on : ubuntu-latest steps : - uses : actions/checkout@v3 - name : Install deps run : npm install # <-- no cache,

Hard-coding credentials, API keys, or access tokens in automated test suites is one of the most common security risks in software engineering. Ensuring that sensitive variables remain isolated across local developer environments and CI/CD pipelines is critical for keeping your code repositories secure. Here is a practical guide and best-practices workflow for managing secrets cleanly in test automation frameworks. Core Recommendations for Secure Test Suites Zero Source Control Leakage: Always add .env and .env.local files to your .gitignore. Never commit raw tokens or passcodes to git. Use Managed CI Secret Stores : In build pipelines, leverage platform native secret managers such as GitHub Secrets, Harness Secrets, Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault. Dynamic Injection via Environment Variables: Read sensitive data dynamically inside tests using standard environment variables (e.g., process.env.API_KEY or process.env.API_BASE_URL). Enforce Least Privilege: Scope test credentials strictly to non-production environments and configure them to expire periodically. Implementation Examples Local Development Usage: Create a non-committed local environment file (.env.local): API_BASE_URL = https://staging.example.com/api API_TOKEN = your_secret_token_here Execute your test suite while passing or overriding variables inline: # Setting environment variables directly before execution $env :API_BASE_URL = 'https://staging.example.com/api' npm run test :api CI Pipeline Integration (e.g., GitHub Actions): Store API_TOKEN under your repository's Settings > Secrets and variables > Actions, then pass it into your execution job step: - name : Run API Tests run : npm run test:api env : API_TOKEN : ${{ secrets.API_TOKEN }} API_BASE_URL : ${{ secrets.API_BASE_URL }}

Having a clear runbook speeds up onboarding for new team members and provides a standardized execution reference for CI/CD environments. Here is a quick-start automation runbook covering prerequisites, environment variables, execution commands, and output artifacts for a Playwright test suite. Prerequisites Node.js: 24.x (configured via package.json engines) Package Manager: npm Optional: Docker (for containerized pipeline runs) Quick Setup # 1. Install project dependencies cd <repo-root> npm ci # 2. Install Playwright browsers and dependencies npx playwright install --with-deps Execution Commands Full Test Suite: npm test (executes run-all-tests.js) API Suite Only: npm run test:api (executes run-api-tests.js) UI Suite Only: npm run test:ui (executes run-ui-tests.js) Generate Reports: npm run generate:reports Core Environment Variables Configure these keys inside your local .env file or CI secrets: API_BASE_URL — Base endpoint URL for API testing BASE_URL — Target website base URL for UI testing RETRY_COUNT — Maximum retry limit for flaky scenario reruns CUCUMBER_PARALLEL — Number of parallel workers for Cucumber execution Test Artifacts & Outputs Allure Execution Results: reports/allure-results Cucumber JSON Reports: reports/cucumber_report.json Failure Media (Videos/Screenshots): test-results/ (configured via config.js)

1. Retomando: da aplicação funcionando ao container pronto para produção Esta série cobriu, até aqui, o suficiente para desenvolver com Docker no dia a dia: conceitos fundamentais, comandos essenciais, Dockerfiles eficientes, rede, volumes e Compose para orquestrar múltiplos serviços. Este último artigo fecha a lacuna entre "funciona no meu Compose local" e "pronto para rodar em produção": imagens menores via multi-stage builds, segurança básica e não negociável, e como tudo isso se integra a um pipeline de CI/CD. 2. O problema que multi-stage builds resolve Compilar ou empacotar uma aplicação frequentemente exige ferramentas que a aplicação não precisa em tempo de execução : compiladores, headers de desenvolvimento, o próprio código-fonte antes de ser transpilado/buildado. Um Dockerfile ingênuo carrega tudo isso para a imagem final: # Ruim: ferramentas de build viajam junto para produção FROM node:20 WORKDIR /app COPY . . RUN npm install && npm run build CMD ["node", "dist/server.js"] Essa imagem inclui o npm , todo o node_modules (incluindo dependências de desenvolvimento), o código-fonte original e as ferramentas de build — frequentemente centenas de MBs de peso morto que nunca são usados depois que npm run build termina, e que ainda aumentam a superfície de ataque da imagem (mais binários, mais coisa que pode ter vulnerabilidade). Multi-stage builds resolvem isso permitindo múltiplos blocos FROM no mesmo Dockerfile, onde estágios posteriores copiam seletivamente apenas o que precisam dos anteriores — o restante do estágio de build simplesmente não existe na imagem final: # Estágio 1: build, com todas as ferramentas necessárias FROM node:20 AS build WORKDIR /app COPY package*.json . RUN npm ci COPY . . RUN npm run build # Estágio 2: produção, só com o resultado do build FROM node:20-slim WORKDIR /app COPY --from=build /app/dist ./dist COPY --from=build /app/node_modules ./node_modules COPY package*.json . CMD ["node", "dist/server.js"] A imagem final não contém o

Part of an ongoing series on model routing and trust tiering for agentic coding tools. This one's the boring, working half — no bug hunt, just a setup that's been running clean across two machines. The problem Claude Code does one thing well: careful, scoped edits with a real plan-then-execute loop behind them, backed by a subscription you're already paying for. Not every task needs that. Exploratory reads, "summarize this directory," draft-and-discard scratch work — most of that doesn't need the most capable model watching every token. The fix is a second, cheaper backend for that category of work. The catch: Claude Code only speaks Anthropic's Messages API. It has no built-in notion of "same tool, different model." So the question is how to point it somewhere else without giving up the interface. The stack Trusted agent: claude — real Anthropic subscription, default session Cheap agent: claude-cheap — same CLI, routed through a self-hosted proxy Proxy: LiteLLM, translating Anthropic-format requests to DeepSeek V4 (pro for Sonnet-tier calls, flash for Haiku-tier) served through an OpenRouter API Transport: a persistent SSH tunnel from a small VPS back to each machine The proxy itself wasn't new. It's the same LiteLLM instance already routing a separate content pipeline I run. The actual work here was wiring Claude Code to it: a shell function and a few environment variables. The core trick and it took me a few week to learn this is to point ANTHROPIC_BASE_URL at LiteLLM's /v1/messages endpoint, not the OpenAI-compatible path LiteLLM also exposes. Claude Code only understands the Anthropic shape, so the OpenAI-shaped endpoint fails in ways that look like a client bug and aren't. Once LiteLLM sits on the right endpoint and translates underneath, Claude Code has no idea it isn't talking to Anthropic. The one bug worth flagging Claude Code's Plan Mode attaches a context_management parameter to its requests. Anthropic's API handles it. Most other backends don't recogniz

We run about 283 scheduled jobs across a handful of machines. Each one is a shell script that declares its own schedule in a header comment, ships its own --test , and gets wired into cron automatically once that test passes. It is a tidy arrangement and it has a hole in it that took us five separate incidents to see, because every one of those incidents looked healthy from every angle we had built. Every number, command and file listing below was re-measured on one 16-core Ubuntu 24.04 box while writing this, not quoted from the commit that fixed it. Two of the numbers came out different, and one of the mechanisms did not reproduce at all. Those are the interesting parts. The hole is that "green" is a conjunction pretending to be a single fact. For a scheduled job to be doing its work, at least four things have to be true at once: the test passes, the test asserts the thing the job does, the job is actually scheduled, it is scheduled where its consumer exists . We had instrumentation for (1). We had a habit — a good one — of insisting on (2). We had nothing whatsoever for (4), and it turns out (4) is the one that runs silently for weeks. 1. The edge detector that compared the state against itself The first one is almost embarrassing in the diff and was invisible for six weeks in production. We have a job that fuses four inputs into one node health label — HEALTHY , DEGRADED , CRITICAL — writes it to a state file, and with --edge prints a line only when the label changes . Cron runs it every five minutes; a separate log records the transitions. The --edge path did this: write_state " $label " # $STATE now holds the new label prev = $( cat " $STATE " ) # ...and prev is read from it [ " $prev " = " $label " ] && exit 0 prev is read after the write. It equals $label by construction. The equality test held on every single run, --edge exited 0 with empty output on every real transition, and the transition log could not append. What makes it worth writing about is not the

Performance testing is essential for ensuring your applications can handle expected user loads without bottlenecks or failures. Apache JMeter remains one of the most popular open-source tools for load, stress, and performance testing. Here is a quick guide to getting your JMeter environment set up and executing your first load test. 1. Prerequisites JMeter requires Java to execute. Ensure you have JDK 11 or higher installed on your system. Verify your Java installation: java -version 2. Download and Installation Download the latest binary zip/tgz file from the Official Apache JMeter Site. Extract the archive into your preferred local directory. Launch JMeter from the bin directory: Windows: Double-click jmeter.bat macOS/Linux: Open terminal and run ./jmeter.sh 3. Install the Plugins Manager The Plugins Manager simplifies adding listeners, graph generators, and custom samplers. Download jmeter-plugins-manager.jar from JMeter Plugins. Move the file into your JMeter lib/ext directory. Restart JMeter. Access the Plugins Manager under Options > Plugins Manager. 4. Building Your First Test Plan Set up a basic HTTP test using the GUI interface: Thread Group: Right-click Test Plan > Add > Threads (Users) > Thread Group. Configure your target virtual users, ramp-up time, and loop count. HTTP Request Defaults: Right-click Thread Group > Add > Config Element > HTTP Request Defaults. Set your target server domain/IP and port. HTTP Sampler: Right-click Thread Group > Add > Sampler > HTTP Request. Define the API path and request method. Listeners: Right-click Thread Group > Add > Listener > View Results Tree or Summary Report (use these GUI listeners primarily for test script validation). 5. Running Tests in Non-GUI Mode Never run actual heavy load tests through the JMeter GUI as it consumes significant local system resources. Use CLI mode for accuracy: jmeter -n -t /path/to/testplan.jmx -l /path/to/results.jtl -e -o /path/to/html-report-folder -n: Non-GUI execution -t: Path to y

Here is a step-by-step guide to configuring your Playwright/Cucumber test suite to run on LambdaTest Cloud via Azure DevOps pipelines, returning test results directly to Azure. 1. Prerequisites A GitHub repository containing your Playwright, Cucumber, and JavaScript automation code. An active Azure DevOps account with a project created. A LambdaTest account (you will need your username and access key). 2. Connect GitHub to Azure DevOps In Azure DevOps, navigate to Pipelines > New Pipeline. Select GitHub as the source and authenticate your account. Choose your repository and target branch (e.g., main). 3. Create LambdaTest Credentials Variable Group Go to Pipelines > Library in Azure DevOps. Click + Variable group and name it LambdaTest-Credentials. Add the following key-value pairs: LAMBDATEST_USERNAME = your_lambdatest_username LAMBDATEST_ACCESS_KEY = your_lambdatest_access_key (toggle "Keep this value secret") Save the group. 4. Add/Update Your azure-pipelines.yml Place this configuration file in your repository root directory: trigger : - main pool : vmImage : ' windows-latest' variables : - group : LambdaTest-Credentials - name : BASE_URL value : ' https://your-app-url.com' - name : LT_BROWSER value : ' chrome' - name : ENABLE_LAMBDATEST value : ' true' stages : - stage : Test jobs : - job : UITestsLambdaTest displayName : ' UI Tests (LambdaTest Cloud)' steps : - task : NodeTool@0 inputs : versionSpec : ' 20.x' displayName : ' Install Node.js 20.x' - script : npm ci displayName : ' Install Dependencies' - script : npm run test:ui:smoke displayName : ' Run UI Smoke Tests on LambdaTest' env : ENABLE_LAMBDATEST : ' true' LT_USERNAME : $(LAMBDATEST_USERNAME) LT_ACCESS_KEY : $(LAMBDATEST_ACCESS_KEY) LT_BROWSER : $(LT_BROWSER) BASE_URL : $(BASE_URL) - task : PublishTestResults@2 condition : always() inputs : testResultsFormat : ' JUnit' testResultsFiles : ' reports/junit-report.xml' testRunTitle : ' UI Tests - LambdaTest Cloud' 5. Update Your Test Code Ensure your tes

A comprehensive, production-ready checklist for reviewing data validation, ETL testing, and automated reconciliation codebases. Code reviews for data engineering tools need more rigor than standard web apps. A subtle bug in a data validation framework can cause silent pipeline failures, false positive test passes, or accidental execution of unbounded SQL queries on production warehouses. Whether you are building a custom data framework or maintaining automated ETL tests, use this generalized checklist during code reviews to keep your test suites secure, performant, and reliable. 1. Test Case Configuration (YAML / JSON) TC ID Matching: Ensure the tc_id value matches the configuration filename exactly. Schema Validity: Verify that type (e.g., count, data, recon, file) and source/target drivers are valid and supported. Explicit Enablers: Confirm the enabled field is explicitly set (true or false) rather than omitted. Relative File Paths: For file-based validation, ensure paths are relative to defined source/target data directories. Non-Empty Queries: Confirm SQL sources and targets include non-empty query strings or valid template paths. Unique Case IDs: Ensure test case identifiers are unique across the test suite directory. Documented Rationale: If a test case has enabled: false or uses numeric tolerance thresholds (validation_tolerance), ensure a comment explains the business reason. Dependency Order: Verify that basic structural checks (COUNT) run prior to deep comparisons (DATA / RECON). 2. SQL & Query Logic Explicit Projections: No SELECT *. All columns must be explicitly listed to avoid schema drift breaks. Alignment: Source and target queries must return compatible data types and matching column ordering. Environment Isolation: Check that query strings contain zero hardcoded hostnames, schema names, or environment paths. Secret Hygiene: Ensure queries contain no hardcoded credentials or connection strings. Warehouse Pushdown: Confirm filtering and heavy aggrega

Building software in 2026 feels surreal. With LLMs handling boilerplate, we ship features in hours that used to take weeks. But fast shipping has a nasty side effect: it breeds overconfidence. A few days ago, we ran an automated check against our own live marketing site ( vergate.dev ). We build security and diagnostic tools for a living, so we expected a clean bill of health. We were wrong. Our scanner flagged 8 real issues in production—including missing security headers that left us exposed to basic cross-site attacks. Dogfooding your own tool isn't a marketing gimmick. Sometimes, it's just plain embarrassing. But it taught us a crucial lesson: you can’t fix what you don't automatically measure. What our scan actually found Here is the exact breakdown of what slipped past us into production (and what probably exists in your current deployment right now): 1. Zero Security Headers Enabled Our hosting provider’s default CDN edge rules didn't set baseline headers. We were shipping without: Content-Security-Policy (CSP): Left us open to inline script injection. Strict-Transport-Security (HSTS): Didn't force browsers to enforce HTTPS strictly. X-Content-Type-Options : Allowed MIME-type sniffing on static assets. X-Frame-Options : Rendered our pages vulnerable to clickjacking IFrames. Why this happens: Framework defaults (like Next.js, Nuxt, or Astro) often expect your proxy or CDN edge (Vercel, Cloudflare, Nginx) to handle headers. If you forget to configure the edge, your app runs bare. 2. Sensitive Meta & Server Leakage Our response headers explicitly broadcast our server stack and proxy details. Attackers use automated scanners like Shodan or Censys to query these specific signatures and exploit target-specific CVEs in seconds. 3. Cookie Missing SameSite & Secure Flags A tracking cookie set on a subroute wasn't explicitly flagged as SameSite=Lax or HttpOnly , leaving a window open for CSRF-style cross-domain requests. How we fixed it (in under 10 minutes) Fixing the

✓ Human-authored analysis; AI used for formatting and proofreading. Kelsey Hightower gave a talk at PlatformCon 2026 that was about the arc of a career, from running commands in SharePoint to writing Go tools that play music on your terminal. The stories has an architecture principle that applies to how security verification should work. Solve the problem once, encode the solution as a reusable artifact, and never solve that problem again. The Jira loop He joined a company where deployments were driven by Jira tickets. Someone opens a ticket with deployment parameters. An engineer would read the ticket, copy the parameters, run the commands, paste the output back into the ticket, close it, and wait for the next one. Every hour, another ticket. Same process, commands and manual steps. The engineer became the loop. He wrote a Puppet manifest that watches the tickets, extracts the parameters, runs the deployment, posts the output, and closes the ticket. The loop ran once as automation and then it was over. No engineer in the loop or ticket waiting for a human. The problem was solved, permanently, by encoding the solution into a reusable artifact. Doing a repetitive manual process faster is not the right thing to do. Eliminate the loop by recognizing the abstraction hiding in the repetition and encoding it into an artifact that makes the manual steps unnecessary. The substrate This is the pattern that runs through every transition he describes. It's missed by most people when they talk about automation. System administrators ran deploy.sh manually. Docker didn't automate typing apt-get install . Docker recognized that "application + dependencies + environment" was a repeatable unit. The container image became the substrate. Deployment stopped being a sequence of commands and became a declaration. The commands didn't get faster. They became unnecessary. Operators placed workloads on servers manually. Kubernetes didn't automate SSH-ing into machines to check available mem

Today I did something I've wanted to do for a while — I took an app running on my own laptop and put it "live" on the internet using AWS. It sounds scary when you read about it online, but once I actually did it, it was just a bunch of small, simple steps, one after another. This post is me writing down everything I did, in plain, easy words, so that if you're a beginner like me, you can follow along without getting confused by fancy tech terms. What is AWS, in simple words? AWS (Amazon Web Services) is basically Amazon renting out computers over the internet. Instead of buying your own physical server and keeping it running 24/7 at home, you "rent" a computer from Amazon. That computer runs your app, and anyone with the internet can visit it. The specific service I used is called EC2 . Think of EC2 as one virtual computer that lives in Amazon's data center, and you get to control it like it's your own. Step 1: Set up IAM first Before touching any servers, I went to IAM (Identity and Access Management). This is AWS's way of managing "who is allowed to do what" in your account. In simple words: instead of using your main AWS login for everything (which is risky), IAM lets you create a separate user with its own permissions. It's like giving someone a spare key instead of your master key. I set this up first so my account stays safer. Step 2: Launch an EC2 instance Next, I went to the EC2 section and launched a new instance (a fancy word for "a virtual computer"). During this step, AWS also lets you create a .pem file — this is basically a secret key file. It's like a digital key to a lock. Only someone with this file can get into the server. I downloaded it and kept it safe, because if you lose it, you can't easily get back in. Step 3: Login to the server using SSH Once the server (EC2 instance) was ready, I needed a way to "log in" to it from my own laptop. For that, I used something called SSH, along with the .pem key file I downloaded earlier. In simple words: SSH

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