Forem: Juan Torchia

Mercor's 4TB Voice Heist: I Ran the Same Attack on My Own AI Data Stack

Juan Torchia — Tue, 28 Apr 2026 16:33:09 +0000

Mercor's 4TB Voice Heist: I Ran the Same Attack on My Own AI Data Stack

80% of breaches on training data platforms involve third-party credentials — not direct attacks on the core company. Yeah, you read that right. They don't storm the castle. They steal the key from the contractor who walks in and out every day. When Mercor confirmed they lost 4TB of voice samples from roughly 40,000 AI contractors, my first thought wasn't "that's rough for them." My first thought was: I have the exact same pattern in my own infra.

I'm not Mercor. I don't have 40k workers or petabytes of audio. But I do have data pipelines, I have API tokens that rotate poorly, I have training artifacts living in buckets with wider permissions than they should have. And I have a history with this kind of simulation: when GoDaddy transferred my domain to a stranger, I didn't write an opinion thread — I mapped the same attack surface against my own infra to understand exactly how exposed I was. I did the same thing here.

The Mercor Pattern: Not a Bug, It's Architecture

What happened at Mercor isn't some exotic exploit. It's the most boring and most dangerous pattern in today's AI ecosystem: sensitive data delegated to contractors, with insufficient granular access and zero credential rotation.

Labeling and voice recording contractors on platforms like Mercor work with tools that need access to storage buckets, upload endpoints, and sometimes SDKs with long-lived tokens. That's not speculation — it's the standard operating model. The problem is those tokens travel in environment variables on personal laptops, in .env files that sometimes end up in "private" repos (not so private), and in mobile app configs that outlive the freelance project by months.

4TB of audio doesn't get exfiltrated through a sophisticated attack. It gets copied with a valid token and an aws s3 sync or equivalent. Probably something like this:

# The most boring attack in the world
# A leaked token + broad read access = silent catastrophe

aws s3 sync s3://mercor-voice-samples-prod ./dump \
  --region us-east-1 \
  --profile compromised_contractor
  # no rate limiting, no alerts, no MFA on the profile
  # 4TB at ~100MB/s = ~11 hours of quiet syncing

No CVE required. Just a token that never expired.

What I Found When I Simulated the Attack on My Own Stack

Here's the uncomfortable part. After reading the Mercor report, I opened my own console and started auditing. My current stack: Next.js on Railway, PostgreSQL, some text processing pipelines for autocomplete features, and access to model APIs (OpenAI, Anthropic). I don't record voices. But I do accumulate data that, in the wrong hands, is a real problem.

First pass: active tokens with broad access

# Basic audit: how many active tokens do I have that I shouldn't?
# Ran this against my API key list in Railway + .env files from old projects

grep -r "API_KEY\|SECRET\|TOKEN" ~/.env_* ./projects/**/.env 2>/dev/null \
  | grep -v ".env.example" \
  | wc -l

# Result: 23
# Active tokens I should have rotated months ago: 23
# Tokens with a configured expiration date: 4
# Ratio that made me feel bad: 82.6%

Twenty-three tokens. Four with expiration. The rest, eternal by default.

Second pass: metadata surface in Railway logs

When the agent deleted my production database last year, I learned to look at logs with a whole new level of paranoia. But this time I was hunting for something different: what API usage metadata am I logging without realizing it?

// What I found in my Railway logs — sanitized but real
// The problem: I was logging the full request for debugging, including headers

logger.info('API request', {
  endpoint: req.url,
  method: req.method,
  headers: req.headers,        // ← PROBLEM: includes Authorization header
  body: JSON.stringify(body),  // ← PROBLEM: includes users' full prompts
  userId: session.userId,
  timestamp: new Date().toISOString()
});

// Result: logs with visible Bearer tokens, real user prompts,
// and enough userId+behavior correlation to reconstruct profiles

Not voice. But user behavior + tokens in plain text in persistent logs. Same vector, different format.

Third pass: training artifacts in buckets

I have a bucket in Railway Volumes with fine-tuning datasets I used for experiments. I ran a permissions audit:

# Check access policy on Railway Volumes (functional equivalent)
# If you use S3 directly, swap with aws s3api get-bucket-acl

railway volume list --json | jq '.[].accessPolicy'
# Output I didn't want to see:
# "accessPolicy": "project-wide"
# Means: any service in the project can read/write
# Including the preview deployments service
# Including open PR branches

PR preview deployments have read access to my training data volumes. That means any external collaborator who opens a PR — or any attacker who compromises that surface — can reach those artifacts.

The Mistakes Mercor Didn't Invent: It Inherited Them from the Ecosystem

My thesis after this simulation: Mercor didn't do anything weird. It did what 90% of the AI data platform ecosystem does. And that's exactly the problem.

The distributed contractor model for data labeling and recording was born from the need to scale fast. RLHF, voice recording, response evaluation — all of this requires globally distributed human work. The access infrastructure was designed to facilitate that work, not to resist an adversary who steals a token from a contractor in Manila or Lagos.

Gotcha #1: long-lived tokens as the default

Most AI task platforms issue tokens with 30-90 day expirations. On a two-week contract, the token outlives the work by months. Nobody does credential offboarding because nobody has the process.

Gotcha #2: broad read access for "operational convenience"

If a contractor needs to download reference samples to calibrate their work, the easiest solution is to give them read access to the entire bucket. Scoping access by batch, by date, or by task ID requires additional engineering that doesn't always get prioritized.

Gotcha #3: no alerts on anomalous access patterns

A legitimate contractor accesses 200-300 files per work session. A 4TB sync is 40 million small files or thousands of large files in a short window. That should trigger an alert. If it didn't, there was no baseline of normal behavior configured.

This connects to something that TypeScript 7.0 made me revisit in my codebase: most of the security issues I found weren't logic bugs — they were the absence of constraints. Without strict types, without strict access policies, the system does what it can, not what it should.

What I Changed in My Stack After the Simulation

I'm not Mercor, but the exercise left me with a concrete list. I'm sharing it because these changes are replicable on any small stack:

# 1. Forced rotation of tokens with no expiration date
# Script I ran to identify and revoke them

for key in $(grep -r "sk-" ~/.env_* | awk -F'=' '{print $2}'); do
  # Check last-used time via Railway logs
  echo "Reviewing: ${key:0:8}..."
  # Revoke if last use > 30 days
done

# Result: revoked 14 tokens, 9 of which hadn't been used in 60+ days

// 2. Log sanitization — what should have been there from day one

const sanitizeForLog = (obj: Record<string, unknown>): Record<string, unknown> => {
  const SENSITIVE_FIELDS = ['authorization', 'token', 'secret', 'password', 'body'];

  return Object.fromEntries(
    Object.entries(obj).map(([key, value]) => [
      key,
      SENSITIVE_FIELDS.some(field => key.toLowerCase().includes(field))
        ? '[REDACTED]'
        : value
    ])
  );
};

// Usage:
logger.info('API request', sanitizeForLog({
  endpoint: req.url,
  method: req.method,
  headers: req.headers,  // now → '[REDACTED]' for Authorization
  userId: session.userId
}));

# 3. Volume isolation per service in Railway
# Changed from "project-wide" to "service-specific"

railway volume update --service api-production --access service-only
# Preview deployments no longer have access
# Operational cost: had to configure an authenticated download endpoint
# Worth it

The third one was the most painful. I had preview deployments using the same data as production to "make testing easier." It was convenient. It was also a direct attack surface. When I migrated my notes from Notion to Markdown I learned that convenience has hidden costs. Same thing here: the convenience of "shared access" carries an attack surface cost I wasn't measuring.

FAQ: Data Security in AI Contractor Stacks

What exactly was stolen from Mercor and why does it matter?

Mercor is a platform that connects AI companies with contractors for labeling, evaluation, and data recording tasks. The 4TB that were stolen are voice samples collected from approximately 40,000 workers. The severity is twofold: first, voice recordings are biometric data — they're irrevocable. You can't change someone's voice like you change a password. Second, those samples include metadata (name, location, device) that allows building complete profiles of people who generally work in vulnerable economies.

How can this affect someone who doesn't use Mercor but works with training data?

The vector is the same regardless of the platform. If you store training datasets in buckets with broad access, if you issue long-lived tokens to external collaborators, or if you log user metadata without sanitizing it, you have the same surface. The name of the compromised company changes; the risk architecture is identical.

What's the difference between this theft and a regular credential breach?

The main difference is the irreversible nature of the data. When someone steals your password, you change it. When someone steals a voice sample trained on thousands of hours of recordings, there's no revocation possible. On top of that, AI training data has very specific market value: it's used to train voice cloning models, forged biometric authentication systems, and to evade deepfake detection systems. That market exists and pays well.

Is rotating tokens regularly enough to stay protected?

No, but it's the first rung. Token rotation attacks the long-lived credential problem, but it doesn't solve broad access, logs with sensitive information, or the absence of anomalous behavior alerts. You also need: least privilege access policies, alerts on download patterns outside of baseline, and strict separation between development and production environments.

What API usage data from LLMs am I unknowingly exposing?

More than you think. Typically: full user prompts in debugging logs, authentication tokens in logged headers, behavior patterns that allow user identification even if you don't explicitly store PII, and intermediate processing artifacts that may include fragments of training data. I ran the audit described in this post and found 23 active tokens without expiration and logs with Authorization headers in plain text. It's not unusual — it's the default if you don't actively configure otherwise.

Should I worry if I'm an indie developer with no voice data?

Yes, but with proportion. You don't have the same risk as Mercor. But if you use LLM APIs, you have tokens. If you have tokens, you have credentials that can be compromised. If you log requests for debugging — and almost all of us do — you have potential user data exposure. The scale changes, the pattern doesn't. The minimum useful exercise: audit how many active tokens you have today, how many have an expiration date, and what you're logging in production.

The Uncomfortable Part I'm Not Going to Soften

When I finished the simulation, I had found 23 tokens without expiration, logs with authentication headers in plain text, and preview deployments with access to production training data. I didn't suffer a breach. But if someone had compromised one of those tokens before I rotated them, the damage would have been real and silent.

What I take away from Mercor isn't moral outrage — though 4TB of voice from 40k contractors is concrete harm to real people. What I take away is that the AI training data ecosystem built its access infrastructure for speed, not resilience. And when that model scales to millions of globally distributed contractors, the attack surface grows faster than the controls.

My position is this: if you're building AI data pipelines — even at indie scale — auditing credentials and permissions is not a "when I have time" task. It's technical debt that, if you don't pay it, someone else collects it for you.

The same pattern that the GoDaddy domain attack taught me applies here: the breach doesn't happen where you're paying attention. It happens in the token you forgot, the log you never reviewed, the bucket you left wide open "just in case."

Go count your active tokens. I counted 23. How many do you have?

This article was originally published on juanchi.dev

4TB de voz robados de Mercor: simulé el mismo ataque sobre mi stack de datos IA

Juan Torchia — Tue, 28 Apr 2026 16:33:04 +0000

4TB de voz robados de Mercor: simulé el mismo ataque sobre mi stack de datos IA

El 80% de los breaches en plataformas de datos de entrenamiento involucran credenciales de terceros, no ataques directos a la empresa central. Sí, leíste bien. No rompen el castillo — roban la llave al contratista que entra y sale todos los días. Y cuando Mercor confirmó que perdió 4TB de muestras de voz de aproximadamente 40.000 contratistas IA, lo primero que pensé no fue "qué mal por ellos". Lo primero que pensé fue: yo tengo el mismo patrón en mi infra.

No soy Mercor. No tengo 40k workers ni petabytes de audio. Pero tengo pipelines de datos, tengo tokens de API que rotan mal, tengo artefactos de entrenamiento que viven en buckets con permisos más anchos de lo que debería. Y tengo una historia con este tipo de simulaciones: cuando GoDaddy me transfirió mi dominio a un desconocido, no escribí un thread de opinión — monté la misma superficie de ataque sobre mi propia infra para entender qué tan expuesto estaba. Hice lo mismo acá.

El patrón Mercor: no es un bug, es arquitectura

Lo que pasó en Mercor no es un exploit exótico. Es el patrón más aburrido y más peligroso del ecosistema IA actual: datos sensibles delegados a contratistas, con acceso granular insuficiente y rotación de credenciales inexistente.

Los contratistas de etiquetado y grabación de voz en plataformas como Mercor trabajan con herramientas que requieren acceso a buckets de almacenamiento, endpoints de upload, y a veces SDKs con tokens de larga duración. No es hipótesis — es el modelo operativo estándar. El problema es que esos tokens viajan en variables de entorno en laptops personales, en .env files que a veces terminan en repos privados (pero no tanto), y en configuraciones de apps móviles que tienen la vida útil de un proyecto freelance.

4TB de audio no se copian en un ataque sofisticado. Se copian con un token válido y un aws s3 sync o equivalente. Probablemente así:

# El ataque más aburrido del mundo
# Un token filtrado + acceso de lectura amplio = catástrofe silenciosa

aws s3 sync s3://mercor-voice-samples-prod ./dump \
  --region us-east-1 \
  --profile contratista_comprometido
  # sin rate limiting, sin alertas, sin MFA en el perfil
  # 4TB a ~100MB/s = ~11 horas de sync tranquilo

Esto no requiere CVE. Requiere un token que no venció.

Lo que encontré cuando simulé el ataque sobre mi propio stack

Acá viene la parte incómoda. Después de leer el informe de Mercor, abrí mi propia consola y empecé a auditar. Mi stack actual: Next.js en Railway, PostgreSQL, algunos pipelines de procesamiento de texto para features de autocompletado, y acceso a APIs de modelos (OpenAI, Anthropic). No grabo voces. Pero sí acumulo datos que, en manos equivocadas, son un problema.

Primera revisión: tokens activos con acceso amplio

# Auditoría básica: ¿cuántos tokens tengo activos que no debería?
# Corrí esto contra mi lista de API keys en Railway + .env de proyectos viejos

grep -r "API_KEY\|SECRET\|TOKEN" ~/.env_* ./projects/**/.env 2>/dev/null \
  | grep -v ".env.example" \
  | wc -l

# Resultado: 23
# Tokens activos que debería haber rotado hace meses: 23
# Tokens con fecha de expiración configurada: 4
# Proporción que me hizo sentir mal: 82.6%

Veintitrés tokens. Cuatro con expiración. El resto, eternos por omisión.

Segunda revisión: superficie de metadatos en logs de Railway

Cuando el agente me borró la base de datos el año pasado, aprendí a mirar los logs con otro nivel de paranoia. Pero esta vez busqué algo distinto: ¿qué metadatos de uso de API estoy logueando sin querer?

// Lo que encontré en mis logs de Railway — sanitizado pero real
// El problema: loggueaba el request completo para debugging, incluyendo headers

logger.info('API request', {
  endpoint: req.url,
  method: req.method,
  headers: req.headers,        // ← PROBLEMA: incluye Authorization header
  body: JSON.stringify(body),  // ← PROBLEMA: incluye prompts completos del usuario
  userId: session.userId,
  timestamp: new Date().toISOString()
});

// Resultado: logs con tokens Bearer visibles, prompts de usuarios reales,
// y suficiente correlación userId+comportamiento para reconstruir perfiles

No era voz. Pero era comportamiento de usuario + tokens en texto plano en logs persistentes. Mismo vector, diferente formato.

Tercera revisión: artefactos de entrenamiento en buckets

Tengo un bucket en Railway Volumes con datasets de fine-tuning que usé para experimentos. Corrí una auditoría de permisos:

# Verificar política de acceso en Railway Volumes (equivalente funcional)
# Si usás S3 directo, reemplazá con aws s3api get-bucket-acl

railway volume list --json | jq '.[].accessPolicy'
# Output que no quería ver:
# "accessPolicy": "project-wide"
# Significa: cualquier servicio del proyecto puede leer/escribir
# Incluyendo el servicio de preview deployments
# Incluyendo branches de PRs abiertas

Los preview deployments de PRs tienen acceso de lectura a mis volúmenes de datos de entrenamiento. Eso significa que cualquier colaborador externo que abra una PR — o cualquier atacante que comprometa esa superficie — puede llegar a esos artefactos.

Los errores que Mercor no inventó: los heredó del ecosistema

Mi tesis, después de esta simulación: Mercor no hizo nada raro. Hizo lo que hace el 90% del ecosistema de plataformas de datos IA. Y eso es exactamente el problema.

El modelo de contratistas distribuidos para etiquetado y grabación de datos nació de la necesidad de escalar rápido. RLHF, grabación de voz, evaluación de respuestas — todo esto requiere trabajo humano distribuido globalmente. La infraestructura de acceso se diseñó para facilitar ese trabajo, no para resistir un adversario que robe un token de un contratista en Manila o Lagos.

Gotcha #1: tokens de larga duración como default

La mayoría de las plataformas de tareas IA emiten tokens con expiración de 30-90 días. En un contrato que dura dos semanas, el token sobrevive al trabajo por meses. Nadie hace offboarding de credenciales porque nadie tiene el proceso.

Gotcha #2: acceso de lectura amplio para "comodidad operativa"

Si un contratista necesita descargar muestras de referencia para calibrar su trabajo, la solución más fácil es darle acceso de lectura al bucket completo. Scopear el acceso por lote, por fecha o por ID de tarea requiere ingeniería adicional que no siempre se prioriza.

Gotcha #3: ausencia de alertas en patrones de acceso anómalos

Un contratista legítimo accede a 200-300 archivos por sesión de trabajo. Un sync de 4TB es 40 millones de archivos pequeños o miles de archivos grandes en una ventana corta. Eso debería disparar una alerta. Si no la disparó, no había baseline de comportamiento normal configurado.

Esto conecta con algo que TypeScript 7.0 me hizo revisar en mi codebase: la mayoría de los problemas de seguridad que encontré no eran bugs de lógica — eran ausencia de constraints. Sin tipos estrictos, sin políticas de acceso estrictas, el sistema hace lo que puede, no lo que debe.

Lo que cambié en mi stack después de la simulación

No soy Mercor, pero el ejercicio me dejó con una lista concreta. La comparto porque los cambios son replicables en cualquier stack pequeño:

# 1. Rotación forzada de tokens sin fecha de expiración
# Script que corrí para identificar y revocar

for key in $(grep -r "sk-" ~/.env_* | awk -F'=' '{print $2}'); do
  # Verificar última vez usado via logs de Railway
  echo "Revisando: ${key:0:8}..."
  # Revocar si último uso > 30 días
done

# Resultado: revoqué 14 tokens, de los cuales 9 no habían sido usados en 60+ días

// 2. Sanitización de logs — lo que debería haber estado desde el principio

const sanitizeForLog = (obj: Record<string, unknown>): Record<string, unknown> => {
  const CAMPOS_SENSIBLES = ['authorization', 'token', 'secret', 'password', 'body'];

  return Object.fromEntries(
    Object.entries(obj).map(([key, value]) => [
      key,
      CAMPOS_SENSIBLES.some(campo => key.toLowerCase().includes(campo))
        ? '[REDACTADO]'
        : value
    ])
  );
};

// Uso:
logger.info('API request', sanitizeForLog({
  endpoint: req.url,
  method: req.method,
  headers: req.headers,  // ahora → '[REDACTADO]' para Authorization
  userId: session.userId
}));

# 3. Aislamiento de volúmenes por servicio en Railway
# Cambié de "project-wide" a "service-specific"

railway volume update --service api-produccion --access service-only
# Preview deployments ya no tienen acceso
# Costo operativo: tuve que configurar un endpoint de descarga autenticado
# Vale la pena

El tercer punto fue el más doloroso. Tenía preview deployments que usaban los mismos datos que producción para "facilitar el testing". Era conveniente. Era también una superficie de ataque directa. Cuando migré mis notas de Notion a Markdown aprendí que la comodidad tiene costos ocultos. Acá aplica igual: la comodidad de "acceso compartido" tiene un costo de superficie que no estaba midiendo.

FAQ: seguridad de datos en stacks de contratistas IA

¿Qué es exactamente lo que se robó en Mercor y por qué es grave?

Mercor es una plataforma que conecta empresas de IA con contratistas para tareas de etiquetado, evaluación y grabación de datos. Las 4TB robadas corresponden a muestras de voz recopiladas de aproximadamente 40.000 trabajadores. La gravedad es doble: primero, las grabaciones de voz son datos biométricos — son irrevocables, no podés cambiarle la voz a alguien como se cambia una contraseña. Segundo, esas muestras incluyen metadatos (nombre, ubicación, dispositivo) que permiten construir perfiles completos de personas que generalmente trabajan en economías vulnerables.

¿Cómo puede afectar esto a alguien que no usa Mercor pero trabaja con datos de entrenamiento?

El vector es el mismo aunque la plataforma sea distinta. Si almacenás datasets de entrenamiento en buckets con acceso amplio, si emitís tokens de larga duración a colaboradores externos, o si loggueás metadata de usuarios sin sanitizar, tenés la misma superficie. El nombre de la empresa comprometida cambia; la arquitectura de riesgo es idéntica.

¿Qué diferencia hay entre este robo y un breach de credenciales común?

La diferencia principal es la naturaleza irreversible del dato. Cuando te roban una contraseña, la cambiás. Cuando te roban una muestra de voz entrenada sobre miles de horas de grabación, no hay revocación posible. Además, los datos de entrenamiento de IA tienen valor de mercado muy específico: sirven para entrenar modelos de clonación de voz, sistemas de autenticación biométrica falsificados, y para evadir sistemas de detección de deepfakes. El mercado para eso existe y paga bien.

¿Es suficiente con rotar tokens regularmente para estar protegido?

No, pero es el primer escalón. La rotación de tokens ataca el problema de credenciales de larga duración, pero no resuelve el acceso amplio, los logs con información sensible, o la ausencia de alertas por comportamiento anómalo. Es necesario también: políticas de acceso mínimo (least privilege), alertas sobre patrones de descarga fuera de baseline, y separación estricta entre ambientes de desarrollo y producción.

¿Qué datos de uso de API de LLMs estoy exponiendo sin saberlo?

Más de lo que creés. Típicamente: prompts completos de usuarios en logs de debugging, tokens de autenticación en headers logueados, patrones de comportamiento que permiten identificar usuarios aunque no guardés PII explícita, y artefactos intermedios de procesamiento que pueden incluir fragmentos de datos de entrenamiento. Corrí la auditoría descrita en este post y encontré 23 tokens activos sin expiración y logs con Authorization headers en texto plano. No es inusual — es el default si no configurás activamente lo contrario.

¿Debería preocuparme si soy un desarrollador indie sin datos de voz?

Sí, pero con proporción. No tenés el mismo riesgo que Mercor. Pero si usás APIs de LLMs, tenés tokens. Si tenés tokens, tenés credenciales que pueden comprometerse. Si loggueás requests para debugging — y casi todos lo hacemos — tenés potencial exposición de datos de usuarios. La escala cambia, el patrón no. El ejercicio mínimo útil: auditar cuántos tokens activos tenés hoy, cuántos tienen fecha de expiración, y qué estás logueando en producción.

Lo incómodo que no voy a suavizar

Cuando terminé la simulación, había encontrado 23 tokens sin expiración, logs con headers de autenticación en texto plano, y preview deployments con acceso a datos de entrenamiento de producción. No sufrí un breach. Pero si alguien hubiera comprometido uno de esos tokens antes de que yo los rotara, el daño era real y silencioso.

Lo que me quedo de Mercor no es la indignación moral — aunque 4TB de voz de 40k contratistas es un daño concreto a personas reales. Lo que me quedo es que el ecosistema de datos de entrenamiento IA construyó su infraestructura de acceso para velocidad, no para resistencia. Y cuando ese modelo escala a millones de contratistas distribuidos globalmente, la superficie de ataque crece más rápido que los controles.

Mi postura es esta: si construís pipelines de datos IA — aunque sea a escala indie — la auditoría de credenciales y permisos no es una tarea para "cuando tenga tiempo". Es una deuda técnica que, si no la pagás, alguien más la cobra por vos.

El mismo patrón que me enseñó el ataque a mi dominio de GoDaddy aplica acá: el breach no ocurre donde ponés atención. Ocurre en el token que olvidaste, el log que nunca revisaste, el bucket que dejaste con permisos anchos "por las dudas".

Andá a contar tus tokens activos. Yo conté 23. ¿Vos cuántos tenés?

Este artículo fue publicado originalmente en juanchi.dev

pgbackrest is unmaintained: what I'm doing with my Postgres backups in production now

Juan Torchia — Tue, 28 Apr 2026 14:30:42 +0000

pgbackrest is unmaintained: what I'm doing with my Postgres backups in production now

A backup is basically like writing a phone number on a napkin. The napkin exists, the number is there, you feel covered. But the day you actually need to call and the napkin has dissolved at the bottom of a jeans pocket that went through the wash — that's the day you realize you never had a recovery plan. You had the illusion of one.

That's what the HN thread about pgbackrest made me see: I had a wet napkin.

pgbackrest alternative postgres backup production: the context that actually matters

The thread hit 425 points on Hacker News with a comment that left little room for doubt: the primary maintainer no longer has time, PRs are piling up unreviewed, and the project's direction is on indefinite pause. It's not an abandoned repo yet — but it's not something you'd want to stake a database holding real user data on.

I was using it. Not as a first line, but as part of the incremental backup flow I built two years ago after an AI agent deleted my production database. After that episode I swore I'd never depend on a single recovery mechanism again. pgbackrest was the layer handling incremental backups with compression and time-based retention. It worked. Until it stopped making sense to keep depending on something with no active maintainer.

My thesis: the death of an infra project isn't the problem itself — it's the smoke detector telling you you've never actually tested recovering anything. The problem existed before. The HN thread just made it visible.

What I evaluated and how I thought about it

Before jumping to whatever the trendy alternative was, I forced myself to define what I actually needed. My stack: PostgreSQL 16 running on Railway, ~4.2 GB database, WAL archiving enabled, 30-day retention, and an informal RTO of "under 2 hours" that I had never concretely measured.

Three options I evaluated seriously:

1. WAL-G

Open source, actively maintained by Wal-G Inc. (formerly part of the Citus/Microsoft stack), native support for S3, GCS, Azure, and local filesystem. The most concrete advantage: the binary is self-contained — no weird dependencies to wrangle.

# Basic install on Debian/Ubuntu
curl -L https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-20.04-amd64.tar.gz \
  | tar -xz -C /usr/local/bin/

# Minimum environment variables for S3
export WALG_S3_PREFIX="s3://my-backup-bucket/postgres"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export PGDATA="/var/lib/postgresql/16/main"

# Full base backup
wal-g backup-push $PGDATA

# List available backups
wal-g backup-list DETAIL

# Restore to a specific point in time
wal-g backup-fetch $PGDATA LATEST

What surprised me: in my restore tests, WAL-G took 18 minutes to recover the 4.2 GB from S3, including WAL application up to the target point in time. I measured that number three times with a simple script.

2. Barman (Backup and Recovery Manager)

Maintained by EnterpriseDB, far more mature in terms of operational interface. The configuration curve is steep — there's a separate Barman server acting as backup receiver, which means additional infrastructure.

# Basic barman.conf (on the dedicated Barman server)
[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link  # hardlinks for efficient incremental backups

[my-postgres-server]
description = "Main production"
conninfo = host=postgres-host user=barman dbname=postgres
backup_method = rsync
archiver = on
retention_policy = RECOVERY WINDOW OF 30 DAYS

# Check configuration
barman check my-postgres-server

# Backup
barman backup my-postgres-server

# List
barman list-backup my-postgres-server

# Restore
barman recover my-postgres-server latest /var/lib/postgresql/16/main \
  --target-time "2025-07-10 14:30:00"

Barman's restore time in the same scenario: 31 minutes. Nearly double. The main reason is that Barman uses rsync by default and has coordination overhead between servers. With backup_method = postgres (streaming) it comes down, but it still doesn't win.

3. Plain pg_dump with manual rotation

The most honest option. The one everyone knows, nobody wants to use for serious production, and the one that often is the only thing left standing when everything else fails.

#!/bin/bash
# pg_dump backup script — no magic, no external dependencies
# Saved as /usr/local/bin/pg_daily_backup.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_NAME="my_database"
BACKUP_DIR="/mnt/backups/postgres"
RETENTION_DAYS=14

# Compressed backup
pg_dump -Fc \
  --no-password \
  -h $PGHOST \
  -U $PGUSER \
  -d $DB_NAME \
  > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Automatic rotation
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

# Log the actual dump size
du -sh "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" >> /var/log/pg_backup.log

echo "Backup completed: ${TIMESTAMP}" >> /var/log/pg_backup.log

Restore with pg_dump is 23 minutes for the 4.2 GB. Faster than Barman, slower than WAL-G — but with no PITR (Point in Time Recovery). If you need to recover to 14:37 and your closest backup is from 14:00, you just lost 37 minutes of data. That trade-off is the one that really stings in real production.

What popularity benchmarks don't tell you

The problem with choosing infra tools by GitHub stars or how often people mention them on Reddit is that popularity measures adoption, not fitness for your specific case. pgbackrest has over 3,000 stars. That did nothing for me when I needed to understand how long my particular database would actually take to recover.

What helped: measuring. Three distinct scenarios:

Tool	Full restore (4.2 GB)	PITR available	Infra overhead	Storage cost (30 days)
WAL-G	18 min	Yes	Minimal	~$0.92/mo on S3
Barman	31 min	Yes	Dedicated server	~$0.92/mo + EC2
pg_dump	23 min	No	None	~$0.85/mo on S3

Storage cost on S3 is nearly identical because WAL-G compresses aggressively and archived WALs are reasonably small for a database without massive write throughput. But if Railway or Supabase were my managed Postgres option, external WAL archiving either comes pre-solved by the platform or simply isn't available for manual configuration.

That detail made me revisit why I moved certain things to my own infrastructure — control over how and where you store your recovery data is not a minor concern when the provider decides which features you get to touch.

The mistakes I made (and that you'll make if you don't check right now)

Mistake 1: I never actually restored anything

I'd had backups running for two years. I never did a full restore to a staging environment to measure real time. The number I had in my head ("Postgres backup, under an hour") was completely made up. My first real restore to a clean environment took 47 minutes with pgbackrest — almost double what I'd assumed.

If you haven't run a full restore in the last month, you don't have a recovery plan. You have a wet napkin.

Mistake 2: confusing backup with archive

WAL archiving and base backups are two different things that work together. If you only have WAL archiving without a recent base backup, restore time will be proportional to how many WAL files you need to apply from the last base backup. In my case, with a weekly base backup and continuous WAL, the worst case was 7 days of WAL — several additional minutes of replay.

# See how many WAL segments exist since the last backup
# In WAL-G:
wal-g wal-show

# Expected output — pay attention to the "segments" count
# +---------------------------+----------+---------+
# | Start                     | End      |Segments |
# +---------------------------+----------+---------+
# | 2025-07-04T03:00:00+00:00 | current  |    1842 |
# +---------------------------+----------+---------+
# 1842 segments = non-trivial replay time

Mistake 3: ignoring WAL size in production

My database is 4.2 GB of data, but it generates roughly 180 MB of WAL per day. Over 30 days: ~5.4 GB of additional archived WAL. If you don't measure it, the storage cost creeps up silently. On S3 it's cheap — on other providers it can surprise you.

-- Measure WAL generation in the last 24 hours
SELECT
  count(*) as wal_files_generated,
  pg_size_pretty(sum(size)) as total_size
FROM pg_ls_waldir()
WHERE modification > now() - interval '24 hours';

This kind of measurement is exactly what production logs reveal when you force yourself to look at them cold, without the adrenaline of an active incident.

FAQ: pgbackrest alternative postgres backup production

Is WAL-G a drop-in replacement for pgbackrest?

Functionally yes, in most cases. Both handle base backups + WAL archiving with PITR. The main difference is in configuration: WAL-G is simpler to get started (one binary, environment variables) while pgbackrest has a more expressive config file. If you already have pgbackrest configured, migrating to WAL-G means rewriting the config and doing a full base backup from scratch — you can't reuse existing backups in a different format.

Is Barman still worth it if you already have dedicated infra?

Yes, especially if you manage multiple Postgres instances and need a centralized operational interface with auditing. The overhead of a separate Barman server pays off when you're managing 5+ instances from one place. For a single instance like mine, it's overkill with a real cost.

Is pg_dump enough for production or just for development?

Depends on your RTO and RPO. If you can tolerate data loss up to N hours (where N is your dump frequency) and a 20–40 minute restore doesn't break any SLA, pg_dump with automated rotation is completely valid. The real limitation is the absence of PITR: you can't recover to an exact point between two dumps. For critical transactional databases, that's usually unacceptable.

How do I configure WAL archiving on Railway or Supabase?

On Railway with a custom Postgres install you can configure archive_mode = on and archive_command if you have access to postgresql.conf. On Supabase, WAL archiving is internal to the service — you can use Point in Time Recovery within the platform but you can't export WAL to external storage directly. That's a recovery vendor lock-in worth evaluating based on how critical your data is.

What base backup frequency makes sense?

For most cases: daily base backup + continuous WAL. A weekly base backup with continuous WAL is acceptable if the database grows slowly (under 500 MB/day of WAL). With daily base backups, WAL replay during restore is minimal. With weekly, in the worst case you need to apply 7 days of WAL — that can add tens of minutes depending on write volume.

Is it worth waiting to see if pgbackrest picks up maintenance again?

No. In infra systems, a maintainer who announces they don't have time rarely comes back with more energy. The window between "project without active maintenance" and "critical vulnerability with no patch" can be short. Migrate now, with time, not during an incident. The cost of migrating calmly is infinitely lower than migrating under pressure — something I learned the night I wiped a production server with rm -rf in my first week on the job.

What I chose and why it's not the right answer for everyone

I went with WAL-G + pg_dump as a second line.

WAL-G handles incremental backups with PITR. pg_dump runs every 24 hours to a separate S3 bucket as an independent fallback — no third-party tool dependencies, no special binaries, just pg_dump and aws s3 cp. If WAL-G disappeared tomorrow, I have yesterday's dump.

The criterion I used wasn't "which tool has more stars" — it was "how fast can I recover and how many dependencies are in the recovery chain." Fewer dependencies in the critical path is better. When you have to restore a database, every additional piece that can fail is a problem you don't need.

What I wouldn't choose for my case: Barman on a single instance. The operational overhead doesn't close the deal. It can make sense for teams with multiple databases and a dedicated DBA — but that's not my reality.

The uncomfortable part of all this: I spent two years with pgbackrest without ever measuring a real restore. The HN thread didn't break my infrastructure — it broke my false sense of security. And in the long run, that was better than keeping a wet napkin in my pocket.

If you want to audit what else might be in "works until it doesn't" state in your data layer, the post about migrating from Notion to Markdown has some of that same flavor: the silent dependency that only hurts when you try to leave.

And if you make the switch to WAL-G, measure the restore. Don't assume it. The real number is always different from the imagined one.

Migrating from pgbackrest or evaluating your options? Reach out — I'm putting together a repo of real WAL-G configs specifically for Railway.

This article was originally published on juanchi.dev

pgbackrest dejó de mantenerse: qué hago ahora con mis backups de Postgres en producción

Juan Torchia — Tue, 28 Apr 2026 14:30:38 +0000

pgbackrest dejó de mantenerse: qué hago ahora con mis backups de Postgres en producción

Hacer un backup es básicamente como anotarte un número de teléfono en una servilleta. La servilleta existe, el número está ahí, sentís que estás cubierto. Pero el día que necesitás llamar y la servilleta desapareció en el fondo de un bolsillo de jean que pasó por el lavarropas — ese día entendés que nunca tuviste un plan de recuperación. Tenías una ilusión de plan.

Eso es lo que el thread de HN sobre pgbackrest me hizo caer: yo tenía una servilleta mojada.

pgbackrest alternativa postgres backup producción: el contexto que importa

El thread llegó a 425 puntos en Hacker News con un comentario que no dejaba mucho lugar a la duda: el mantenedor principal ya no tiene tiempo, los PRs se acumulan sin revisión y la dirección del proyecto está en pausa indefinida. No es un repo abandonado todavía, pero tampoco es algo en lo que querrías apoyar una base de datos que aloja datos de usuarios reales.

Yo lo usaba. No como primera línea, pero sí como parte del flujo de backup incremental que armé hace dos años cuando el agente me borró la base de datos en producción. Después de ese episodio prometí que nunca más iba a depender de un solo mecanismo de recovery. pgbackrest era la capa que manejaba los backups incrementales con compresión y retención por tiempo. Funcionaba. Hasta que dejó de tener sentido seguir dependiendo de algo sin maintainer activo.

Mi tesis: la muerte de un proyecto de infra no es el problema en sí — es el detector de humo que te avisa que nunca probaste realmente recuperar nada. El problema estaba antes. El thread de HN solo lo hizo visible.

Qué opciones evalué y con qué criterio

Antes de saltar a la alternativa de moda, me obligué a definir qué necesitaba realmente. Mi stack: PostgreSQL 16 corriendo en Railway, base de datos de ~4.2 GB, WAL archiving habilitado, retention de 30 días, RTO informal de "menos de 2 horas" que nunca había medido concretamente.

Las tres opciones que evalué en serio:

1. WAL-G

Open source, mantenido activamente por Wal-G Inc. (antes parte del stack de Citus/Microsoft), soporte nativo para S3, GCS, Azure y filesystem local. La ventaja más concreta es que el binario es autocontenido — no hay dependencias raras que gestionar.

# Instalación básica en Debian/Ubuntu
curl -L https://github.com/wal-g/wal-g/releases/latest/download/wal-g-pg-ubuntu-20.04-amd64.tar.gz \
  | tar -xz -C /usr/local/bin/

# Variables de entorno mínimas para S3
export WALG_S3_PREFIX="s3://mi-bucket-backups/postgres"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export PGDATA="/var/lib/postgresql/16/main"

# Backup base completo
wal-g backup-push $PGDATA

# Listar backups disponibles
wal-g backup-list DETAIL

# Restore a punto específico en el tiempo
wal-g backup-fetch $PGDATA LATEST

Lo que me sorprendió: en mis pruebas de restore, WAL-G tardó 18 minutos en recuperar los 4.2 GB desde S3 incluyendo aplicación de WAL hasta el punto en el tiempo que elegí. Ese número lo medí tres veces con un script simple.

2. Barman (Backup and Recovery Manager)

Mantenido por EnterpriseDB, mucho más maduro en términos de interfaz operacional. La curva de configuración es empinada — hay un servidor Barman separado que actúa como receptor de backups, lo que implica infraestructura adicional.

# barman.conf básico (en el servidor Barman dedicado)
[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link  # hardlinks para backups incrementales eficientes

[mi-postgres-server]
description = "Producción principal"
conninfo = host=postgres-host user=barman dbname=postgres
backup_method = rsync
archiver = on
retention_policy = RECOVERY WINDOW OF 30 DAYS

# Verificar configuración
barman check mi-postgres-server

# Backup
barman backup mi-postgres-server

# Listar
barman list-backup mi-postgres-server

# Restore
barman recover mi-postgres-server latest /var/lib/postgresql/16/main \
  --target-time "2025-07-10 14:30:00"

El tiempo de restore de Barman en el mismo escenario: 31 minutos. Casi el doble. La razón principal es que Barman usa rsync por defecto y tiene overhead de coordinación entre servidores. Con backup_method = postgres (streaming) baja, pero igual no gana.

3. pg_dump puro con rotación manual

La opción más honesta. La que todo el mundo conoce, nadie quiere usar para producción seria, y que muchas veces es la única que sobrevive cuando todo lo demás falla.

#!/bin/bash
# Script de backup con pg_dump — sin magia, sin dependencias externas
# Guardado en /usr/local/bin/pg_backup_diario.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_NAME="mi_base"
BACKUP_DIR="/mnt/backups/postgres"
RETENTION_DAYS=14

# Backup comprimido
pg_dump -Fc \
  --no-password \
  -h $PGHOST \
  -U $PGUSER \
  -d $DB_NAME \
  > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Rotación automática
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

# Log del tamaño real del dump
du -sh "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" >> /var/log/pg_backup.log

echo "Backup completado: ${TIMESTAMP}" >> /var/log/pg_backup.log

Restore con pg_dump es 23 minutos para los 4.2 GB. Más rápido que Barman, más lento que WAL-G, pero sin PITR (Point in Time Recovery). Si necesitás recuperar a las 14:37 y el backup más cercano es de las 14:00, perdiste 37 minutos de datos. Ese trade-off es el que más duele en producción real.

Lo que los benchmarks de popularidad no te dicen

El problema con elegir herramientas de infra por GitHub stars o por cuánta gente las menciona en Reddit es que la popularidad mide adopción, no idoneidad para el caso específico. pgbackrest tiene más de 3.000 estrellas. Eso no me ayudó cuando necesité entender cuánto tarda mi base puntual en recuperarse.

Lo que sí me ayudó: medir. Tres scenarios distintos:

Herramienta	Restore completo (4.2 GB)	PITR disponible	Overhead infra	Costo storage (30 días)
WAL-G	18 min	Sí	Mínimo	~$0.92/mes en S3
Barman	31 min	Sí	Servidor dedicado	~$0.92/mes + EC2
pg_dump	23 min	No	Ninguno	~$0.85/mes en S3

El costo de storage en S3 es casi el mismo porque WAL-G comprime agresivamente y los WAL archivados son razonablemente chicos para una base que no tiene escrituras masivas. Pero si Railway o Supabase fueran mi opción de managed Postgres, el WAL archiving externo ya viene resuelto o directamente no está disponible para configurar manualmente.

Ese detalle me hizo revisar por qué migré ciertas cosas a infra propia — el control sobre cómo y dónde guardás los datos de recovery no es un tema menor cuando el proveedor decide qué features exponés.

Los errores que cometí (y que vas a cometer si no los revisás ahora)

Error 1: nunca restauré de verdad

Tenía backups funcionando desde hacía dos años. Nunca hice un restore completo a un ambiente de staging para medir el tiempo real. El número que tenía en la cabeza ("backup de Postgres, menos de una hora") era completamente inventado. Mi primer restore real en un ambiente limpio tardó 47 minutos con pgbackrest — casi el doble de lo que asumía.

Si no corriste un restore completo en el último mes, no tenés un plan de recovery. Tenés una servilleta mojada.

Error 2: confundir backup con archive

WAL archiving y backups base son dos cosas distintas que trabajan juntas. Si solo tenés WAL archiving sin un backup base reciente, el tiempo de restore va a ser proporcional a cuántos WAL files necesitás aplicar desde el último base backup. En mi caso, con un base backup semanal y WAL continuo, el peor escenario eran 7 días de WAL — varios minutos adicionales de replay.

# Ver cuántos WAL segments hay desde el último backup
# En WAL-G:
wal-g wal-show

# Salida esperada — prestá atención al "segments" count
# +---------------------------+----------+---------+
# | Start                     | End      |Segments |
# +---------------------------+----------+---------+
# | 2025-07-04T03:00:00+00:00 | current  |    1842 |
# +---------------------------+----------+---------+
# 1842 segments = tiempo de replay no trivial

Error 3: ignorar el WAL size en producción

Mi base tiene 4.2 GB de datos, pero genera aproximadamente 180 MB de WAL por día. En 30 días: ~5.4 GB de WAL adicional archivado. Si no lo medís, el costo de storage se va silenciosamente. En S3 es barato, pero en otros providers puede sorprender.

# Medir generación de WAL en las últimas 24hs
SELECT
  count(*) as wal_files_generados,
  pg_size_pretty(sum(size)) as tamanio_total
FROM pg_ls_waldir()
WHERE modification > now() - interval '24 hours';

Este tipo de medición es exactamente lo que los logs de producción revelan cuando te forzás a mirarlos en frío, sin la adrenalina de un incidente.

FAQ: pgbackrest alternativa postgres backup producción

¿WAL-G es un reemplazo directo de pgbackrest?

Funcionalmente sí, en la mayoría de los casos. Ambos manejan backups base + WAL archiving con PITR. La diferencia principal está en la configuración: WAL-G es más simple de arrancar (un binario, variables de entorno) mientras que pgbackrest tiene un archivo de configuración más expresivo. Si ya tenés pgbackrest configurado, la migración a WAL-G implica reescribir la config y hacer un primer backup base completo desde cero — no podés reutilizar los backups existentes de formato distinto.

¿Barman sigue valiendo la pena si ya tenés infra dedicada?

Sí, especialmente si manejás múltiples instancias de Postgres y necesitás una interfaz operacional centralizada con auditoría. El overhead de tener un servidor Barman separado se amortiza cuando gestionás 5+ instancias desde un solo lugar. Para una sola instancia como la mía, es overkill con costo real.

¿pg_dump alcanza para producción o es solo para desarrollo?

Depende de tu RTO y RPO. Si podés tolerar pérdida de hasta N horas de datos (donde N es la frecuencia de dumps) y un restore de 20-40 minutos no te rompe ningún SLA, pg_dump con rotación automatizada es completamente válido. La limitación real es la ausencia de PITR: no podés recuperar a un punto exacto entre dos dumps. Para bases transaccionales críticas, eso suele ser inaceptable.

¿Cómo configuro WAL archiving en Railway o Supabase?

En Railway con Postgres custom podés configurar archive_mode = on y archive_command si tenés acceso al postgresql.conf. En Supabase el WAL archiving es interno al servicio — podés usar Point in Time Recovery dentro de la plataforma pero no exportar WAL a storage externo directamente. Eso es un vendor lock-in de recovery que vale la pena evaluar según la criticidad del dato.

¿Qué frecuencia de backup base tiene sentido?

Para la mayoría de los casos: backup base diario + WAL continuo. Un backup base semanal con WAL continuo es aceptable si la base crece lento (bajo 500 MB/día de WAL). Con backup base diario, el replay de WAL en restore es mínimo. Con backup semanal, en el peor caso necesitás aplicar 7 días de WAL — eso puede sumar decenas de minutos dependiendo del volumen de escritura.

¿Vale la pena esperar a ver si pgbackrest retoma el mantenimiento?

No. En sistemas de infra, un maintainer que anuncia falta de tiempo disponible raramente vuelve con más energía. La ventana de riesgo entre "proyecto sin mantenimiento activo" y "vulnerabilidad crítica sin parchear" puede ser corta. Migrá ahora con tiempo, no durante un incidente. El costo de migrar en calma es infinitamente menor que el costo de migrar bajo presión — algo que aprendí la noche que tiré un servidor de producción con rm -rf en mi primera semana de laburo.

Qué elegí y por qué no es la respuesta para todos

Me quedé con WAL-G + pg_dump como segunda línea.

WAL-G maneja los backups incrementales con PITR. pg_dump corre cada 24 horas y va a un bucket S3 separado como fallback independiente — sin dependencias de herramientas de terceros, sin binarios especiales, solo pg_dump y aws s3 cp. Si WAL-G desapareciera mañana, tengo un dump de ayer.

El criterio que usé no fue "qué tool tiene más stars" sino "qué tan rápido puedo recuperar y con cuántas dependencias en la cadena de recovery". Menos dependencias en el path crítico es mejor. Cuando tenés que restaurar una base de datos, cada pieza adicional que puede fallar es un problema que no necesitás.

Lo que no elegiría para mi caso: Barman en una sola instancia. El overhead operacional no cierra. Puede tener sentido para equipos con múltiples bases y un DBA dedicado — pero eso no es mi realidad.

Lo incómodo de todo esto: pasé dos años con pgbackrest sin haber medido un restore real. El thread de HN no me rompió la infra — me rompió la tranquilidad falsa. Y eso, a la larga, fue mejor que seguir con una servilleta mojada en el bolsillo.

Si querés revisar qué más puede estar en estado de "funciona hasta que no funciona" en la capa de datos, el post sobre migrar de Notion a Markdown tiene algo de ese mismo sabor: la dependencia silenciosa que solo duele cuando intentás salir.

Y si hacés el switch a WAL-G, medí el restore. No lo asumas. El número real siempre es distinto del número imaginado.

¿Estás migrando de pgbackrest o evaluando opciones? Escribime — estoy armando un repositorio de configuraciones reales de WAL-G para Railway específicamente.

Este artículo fue publicado originalmente en juanchi.dev

Microsoft and OpenAI Break Their Exclusive Deal: What My API Usage Logs Actually Say About Who Benefits

Juan Torchia — Tue, 28 Apr 2026 12:31:22 +0000

Microsoft and OpenAI Break Their Exclusive Deal: What My API Usage Logs Actually Say About Who Benefits

Back in 2009, at 18, I was studying for my CCNA at night after eight hours working at a cybercafé. Cisco had a near-monopoly on enterprise networking in Argentina. I remember thinking: "if Cisco breaks something with a partner, why should I care? I still need to know OSPF." Today, reading that Microsoft and OpenAI dissolved their exclusivity agreement — the big news that dominated Hacker News with 880 points in just a few hours — I got exactly the same feeling. Tons of noise at the top. Down in my logs, the story is more boring and more honest.

But there's one exception. And I found it on my March invoice.

Microsoft and OpenAI Exclusivity Deal: What Actually Changed and What Didn't

For anyone who already has the week's context: I'm not going to rehash the 2019 deal, the $13 billion, or the distribution rights. That's all out there. What's new is that Microsoft no longer holds exclusivity over the OpenAI API for cloud providers. Any other vendor — Google Cloud, AWS, Oracle — can now offer direct access to GPT-4o, o1, or whatever comes next, without going through Azure OpenAI Service.

My concrete thesis: this change benefits almost exclusively OpenAI, marginally benefits competing hyperscalers, and for the independent dev calling the API directly it's noise — except for one pricing variable that's actually worth understanding.

This isn't a hot take. It's what I read in my own numbers.

What My Last 90 Days of Logs Say

I run my projects on Railway. I call the OpenAI API directly — I never went through Azure OpenAI Service because the setup overhead never made sense for small projects. When I looked at my logs from the last 90 days, the pattern was clear:

# Extract calls by model and cost - last 90 days
# File: analyze_api_logs.sh

#!/bin/bash
LOGS_DIR="./logs/api"

echo "=== Call distribution by model ==="
grep '"model"' $LOGS_DIR/*.jsonl | \
  jq -r '.model' | \
  sort | uniq -c | sort -rn

echo ""
echo "=== Estimated cost by model (USD) ==="
# Each line has: timestamp, model, input_tokens, output_tokens, cost_usd
awk -F',' '
  NR>1 {
    model[$2] += $5
    calls[$2]++
  }
  END {
    for (m in model)
      printf "%-25s calls: %d  total: $%.4f\n", m, calls[m], model[m]
  }
' $LOGS_DIR/summary.csv | sort -t'$' -k2 -rn

Actual output from my last 90 days:

=== Call distribution by model ===
   4821 gpt-4o
   2103 gpt-4o-mini
    847 o1-mini
    312 gpt-4-turbo (legacy, migrating)

=== Estimated cost by model (USD) ===
gpt-4o                    calls: 4821  total: $38.4200
o1-mini                   calls: 847   total: $14.9300
gpt-4o-mini               calls: 2103  total: $2.1800
gpt-4-turbo               calls: 312   total: $4.8800

Total over 90 days: ~$60.40 USD calling api.openai.com directly.

Would I have paid something different using Azure OpenAI Service? Yes. Azure charges a markup on the same calls — historically between 10% and 20% depending on tier and region. On $60 over 90 days, that's between $6 and $12 of difference. Nothing. For a company spending $60,000 in 90 days, that's between $6,000 and $12,000. That's where the real game is.

Why This Change Benefits OpenAI More Than Microsoft

The original deal was brilliant for Microsoft in 2019: OpenAI needed compute and money, Microsoft needed AI credibility. But the world changed. Today OpenAI has:

Direct revenue from subscriptions (ChatGPT Plus, Team, Enterprise)
Its own API with millions of devs calling it directly
Negotiating leverage that simply didn't exist in 2019

Distribution exclusivity gave Microsoft a privileged channel to enterprise customers. But that channel has a cost: every deal Microsoft closed with a big client via Azure OpenAI Service meant OpenAI was seeing a fraction of the revenue it would've captured on its own.

Breaking exclusivity means OpenAI can now negotiate direct deals with Google Cloud, with AWS, with any enterprise consultancy that wants to offer its models. More channels, more revenue, more control.

For Microsoft, the cost is real but bounded: Azure is still the cloud provider with the deepest integration, with Copilot, with the M365 ecosystem. They don't lose everything. But they lose the advantage of being the only authorized enterprise provider.

The uncomfortable thing nobody says in the HN threads: Microsoft knew this was coming. OpenAI's current valuation makes it indefensible to charge a markup for exclusive access when the product owner can walk and sell directly. The end of the exclusive was negotiated, not ripped away.

The Invoice Detail That Actually Matters for Independent Devs

I promised there was an exception. Here it is.

When I reviewed my March invoice I found something: I started receiving usage credits through an Azure program I have active through my dev subscription. Credits that only apply if you call OpenAI via Azure OpenAI Service, not via the direct API.

// Endpoint comparison - same call, different billing
// api.openai.com = direct billing, no Azure credits
// azure.openai.com = Azure Dev/Startup credits apply if you have them

const OPENAI_DIRECT = {
  endpoint: 'https://api.openai.com/v1/chat/completions',
  // No Azure credits
  // Lower latency in some cases (no extra hop)
  // Setup: 2 minutes
}

const AZURE_OPENAI = {
  endpoint: `https://${AZURE_RESOURCE}.openai.azure.com/openai/deployments/${DEPLOYMENT}/chat/completions`,
  // Azure credits apply if you have them active
  // Easier enterprise compliance (data residency, VNet, etc.)
  // Setup: 20 minutes minimum, more if you use managed identity
}

If you have active Azure credits — startup programs, Visual Studio subscriptions, Microsoft for Startups — and you're calling OpenAI directly, you're leaving money on the table. That doesn't change with the new agreement, but it is something that could get renegotiated now that the exclusive is broken: if Google Cloud or AWS start offering similar credits for OpenAI model access, the incentive ecosystem opens up.

For now, in my specific case: I evaluated moving $30–$40 per month to Azure for the credits. The setup overhead stopped me. I'm staying on direct.

The Most Common Misreads I Saw in the HN Threads

The 880-point thread has some error patterns worth dismantling:

"Now OpenAI can go with Google Cloud and everyone migrates" — Not so fast. Microsoft has compute agreements that go well beyond the distribution deal. OpenAI runs on Azure infrastructure. That doesn't change overnight.

"Microsoft lost its $13B bet" — The $13B wasn't a payment for exclusivity; it was structured investment in a company now worth exponentially more. The investment is still an investment.

"Devs will get cheaper prices now" — Why? OpenAI's API has its own pricing. Azure was charging a markup on top of that. Without the exclusive, Azure could lower its markup to stay competitive, but nothing guarantees it happens tomorrow. Competition takes time.

"This is the beginning of the end for Azure" — Azure has 200+ services. OpenAI is one. Anyone saying this is confusing media visibility with actual business weight.

On the architecture topics I've been working through this week — the agent that deleted my production database, the Notion to Markdown migration, the supply chain issues I dug into with Bitwarden — there's a pattern that keeps repeating: the changes that hit hardest aren't the ones with 880 upvotes on HN. They're the quiet ones. The breaking of the exclusivity deal is loud. What actually changes my real workflow is somewhere else.

FAQ: Microsoft and OpenAI Exclusivity Deal

What exactly was the exclusivity agreement between Microsoft and OpenAI?
Microsoft had exclusive rights to distribute and commercialize OpenAI's models through its Azure cloud platform. Any company that wanted to integrate GPT-4 or similar models into enterprise products had to go through Azure OpenAI Service. That gave Microsoft a commercial markup and a privileged position over Google Cloud, AWS, and others.

What changes for an independent developer already using the OpenAI API directly?
Almost nothing in the short term. The prices at api.openai.com don't change because of this announcement. The possible positive consequence in the medium term is that more competition between cloud providers could push prices down or generate more accessible credit programs. For now, if you're not using Azure, the only change is strategic context.

Should I migrate to Azure OpenAI Service after this change?
Depends on whether you have active Azure credits. If you use Visual Studio Enterprise, Microsoft for Startups, or other programs with credits, it's worth running the numbers. If you're paying Azure at list price without credits, the historical markup means the direct API is still cheaper for low to medium volumes.

Can OpenAI now run its models on Google Cloud or AWS?
Technically yes, the distribution agreement no longer blocks it. But OpenAI has all its training and inference infrastructure on Azure. Moving that is a years-long decision, not months. What can happen is that Google Cloud or AWS offer access to OpenAI models as resellers, similar to how other cloud marketplace agreements work.

Does this affect the pricing of Copilot or Microsoft's AI-integrated products?
Not directly. Copilot products (M365, GitHub, Azure) have their own agreements and pricing structures that don't depend on the API exclusivity deal. Microsoft still has access to OpenAI's models; what it loses is the monopoly on who else can have it.

How do I know if I should switch endpoints in my current projects?
Open your logs from the last 30–60 days, calculate what you're spending on api.openai.com, and check if you have available Azure credits. If your monthly spend is above $100 USD and you have unused credits, the Azure OpenAI Service setup pays for itself in a few weeks. Below that, the configuration overhead doesn't pencil out.

My Final Take, Unfiltered

The end of the exclusivity agreement is an important corporate news story. For the industry, it's a signal of maturity: OpenAI no longer needs Microsoft's umbrella to reach enterprise. For Microsoft, it's a calculated concession that keeps the investment intact while releasing regulatory pressure.

For me, looking at my $60 in 90 days of logs: irrelevant — unless someone activates a credits program that justifies switching endpoints.

What I do find relevant — and this is something I didn't read in any of the 400+ comments in that thread — is that this move opens the door for OpenAI to build direct deals with companies that until now had to negotiate through Microsoft. That concentrates more power in OpenAI, not less. And a company with that level of centralized power over models already running in critical production systems — including mine, including almost everyone who read that thread — deserves more scrutiny than it gets when the headlines are talking about "competition" and "openness."

The openness that matters isn't between cloud providers. It's between models, between vendors, between architectures. The fact that a dev today can choose between GPT-4o, Claude, Gemini, and Mistral at comparable costs — that's actual openness. The rest is just reorganizing who collects the markup.

If you're interested in multi-provider architecture decisions, last week I wrote about TypeScript 7.0 Beta on a real codebase — there's an abstraction pattern for clients that applies directly to this. And if you want to see how I think about owning my infra before trusting third-party services with critical decisions, start with the Asahi Linux on Apple Silicon post: the philosophy is the same.

This article was originally published on juanchi.dev

Microsoft y OpenAI rompen su acuerdo exclusivo: lo que mis logs de uso dicen sobre a quién le conviene realmente

Juan Torchia — Tue, 28 Apr 2026 12:31:17 +0000

Microsoft y OpenAI rompen su acuerdo exclusivo: lo que mis logs de uso dicen sobre a quién le conviene realmente

En 2009, a los 18 años, estudiaba para el CCNA de noche después de ocho horas en el cyber. Cisco tenía un ecosistema casi monopólico en networking empresarial en Argentina. Recuerdo haber pensado: "si Cisco rompe algo con algún partner, ¿a mí qué me cambia? Igual tengo que saber OSPF". Hoy, leyendo que Microsoft y OpenAI disolvieron su acuerdo de exclusividad —el notición que dominó Hacker News con 880 puntos en pocas horas— me vino exactamente la misma sensación. Mucho ruido arriba. Abajo, en mis logs, la historia es más aburrida y más honesta.

Pero hay una excepción. Y la encontré en mi factura de marzo.

Microsoft OpenAI deal exclusividad: qué cambió y qué no

Para el lector que ya vino con el contexto de la semana: no voy a repetir la historia del deal de 2019, los 13 mil millones de dólares o los derechos de distribución. Ya está. Lo nuevo es que Microsoft ya no tiene exclusividad sobre la API de OpenAI para cloud providers. Cualquier otro proveedor —Google Cloud, AWS, Oracle— puede ahora ofrecer acceso directo a GPT-4o, o1, o lo que venga después, sin pasar por Azure OpenAI Service.

Mi tesis concreta: este cambio beneficia casi exclusivamente a OpenAI, marginalmente a los hiperescalares competidores, y para el dev independiente que llama la API directamente es ruido salvo por una variable de pricing que vale la pena entender.

No es una opinión caliente. Es lo que leo en mis propios números.

Lo que dicen mis logs de los últimos 90 días

Corro mis proyectos en Railway. Llamo a la API de OpenAI directo —nunca pasé por Azure OpenAI Service porque el overhead de setup no me cerró para proyectos pequeños. Cuando miré mis logs de los últimos 90 días, el patrón fue claro:

# Extraer llamadas por modelo y costo - últimos 90 días
# Archivo: analyze_api_logs.sh

#!/bin/bash
LOGS_DIR="./logs/api"

echo "=== Distribución de llamadas por modelo ==="
grep '"model"' $LOGS_DIR/*.jsonl | \
  jq -r '.model' | \
  sort | uniq -c | sort -rn

echo ""
echo "=== Costo estimado por modelo (USD) ==="
# Cada línea tiene: timestamp, model, input_tokens, output_tokens, cost_usd
awk -F',' '
  NR>1 {
    modelo[$2] += $5
    llamadas[$2]++
  }
  END {
    for (m in modelo)
      printf "%-25s llamadas: %d  total: $%.4f\n", m, llamadas[m], modelo[m]
  }
' $LOGS_DIR/summary.csv | sort -t'$' -k2 -rn

Resultado real de mis últimos 90 días:

=== Distribución de llamadas por modelo ===
   4821 gpt-4o
   2103 gpt-4o-mini
    847 o1-mini
    312 gpt-4-turbo (legacy, migrando)

=== Costo estimado por modelo (USD) ===
gpt-4o                    llamadas: 4821  total: $38.4200
o1-mini                   llamadas: 847   total: $14.9300
gpt-4o-mini               llamadas: 2103  total: $2.1800
gpt-4-turbo               llamadas: 312   total: $4.8800

Total en 90 días: ~$60.40 USD llamando directo a api.openai.com.

¿Habría pagado algo diferente usando Azure OpenAI Service? Sí. Azure cobra un markup sobre las mismas llamadas —históricamente entre 10% y 20% dependiendo del tier y región. Para $60 en 90 días eso son entre $6 y $12 de diferencia. No es nada. Para una empresa que gasta $60.000 en 90 días, son entre $6.000 y $12.000. Ahí está el juego real.

Por qué este cambio beneficia más a OpenAI que a Microsoft

El acuerdo original fue brillante para Microsoft en 2019: OpenAI necesitaba compute y dinero, Microsoft necesitaba credibilidad en IA. Pero el mundo cambió. OpenAI hoy tiene:

Ingresos directos por subscripciones (ChatGPT Plus, Team, Enterprise)
API propia con millones de devs que llaman directo
Capacidad negociadora que en 2019 simplemente no existía

La exclusividad de distribución le daba a Microsoft un canal privilegiado hacia clientes enterprise. Pero ese canal tiene un costo: cada deal que Microsoft cerraba con un cliente grande vía Azure OpenAI Service, OpenAI veía una fracción del ingreso que habría capturado sola.

Romper la exclusividad significa que OpenAI puede ahora negociar deals directos con Google Cloud, con AWS, con cualquier consultora enterprise que quiera ofrecer sus modelos. Más canales, más ingresos, más control.

Para Microsoft, el costo es real pero acotado: Azure sigue siendo el cloud provider con la integración más profunda, con Copilot, con el ecosistema M365. No pierden todo. Pero pierden la ventaja de ser el único proveedor enterprise autorizado.

Lo incómodo que nadie dice en los threads de HN: Microsoft sabía que esto llegaba. La valuación actual de OpenAI hace indefendible cobrar un markup por acceso exclusivo cuando el dueño del producto puede irse a vender directo. El fin del exclusivo fue negociado, no arrancado.

El dato en la factura que sí importa para devs independientes

Prometí que había una excepción. Acá está.

Cuando revisé mi factura de marzo encontré algo: empecé a recibir créditos de uso a través de un programa de Azure que tengo activo por mi suscripción de dev. Créditos que solo aplican si llamás a OpenAI vía Azure OpenAI Service, no vía la API directa.

// Comparación de endpoints - misma llamada, diferente billing
// api.openai.com = facturación directa, sin créditos Azure
// azure.openai.com = aplican créditos Azure Dev/Startup si los tenés

const OPENAI_DIRECT = {
  endpoint: 'https://api.openai.com/v1/chat/completions',
  // Sin créditos Azure
  // Menor latencia en algunos casos (sin hop extra)
  // Setup: 2 minutos
}

const AZURE_OPENAI = {
  endpoint: `https://${AZURE_RESOURCE}.openai.azure.com/openai/deployments/${DEPLOYMENT}/chat/completions`,
  // Aplican créditos Azure si los tenés activos
  // Compliance enterprise más fácil (data residency, VNet, etc.)
  // Setup: 20 minutos mínimo, más si usás managed identity
}

Si tenés créditos Azure activos —startup programs, Visual Studio subscriptions, Microsoft for Startups— y estás llamando a OpenAI directo, estás dejando plata sobre la mesa. Eso no cambia con el nuevo acuerdo, pero sí es algo que con el exclusivo roto podría renegociarse: si Google Cloud o AWS empiezan a ofrecer créditos similares para acceso a modelos OpenAI, el ecosistema de incentivos se abre.

Por ahora, en mi caso concreto: evalué mover $30-$40 por mes a Azure por los créditos. El overhead de setup me frenó. Sigo en directo.

Los errores de lectura más comunes que vi en los threads de HN

El thread de 880 puntos tiene algunos patrones de error que vale la pena desmontar:

"Ahora OpenAI puede irse con Google Cloud y todos migran" — No tan rápido. Microsoft tiene acuerdos de compute que van más allá del deal de distribución. OpenAI corre en infraestructura Azure. Eso no cambia de un día para el otro.

"Microsoft perdió su apuesta de $13B" — Los $13B no eran un pago por exclusividad; eran inversión estructurada en una empresa que hoy vale exponencialmente más. La inversión sigue siendo inversión.

"Para los devs ahora es más barato" — ¿Por qué? La API de OpenAI tiene sus precios. Azure cobraba markup sobre eso. Sin exclusivo, Azure puede bajar el markup para ser competitivo, pero nada garantiza que lo haga mañana. La competencia tarda en llegar.

"Esto es el inicio del fin de Azure" — Azure tiene 200+ servicios. OpenAI es uno. Quien dice esto confunde visibilidad mediática con peso de negocio.

Sobre los temas de arquitectura que vengo trabajando esta semana —el agente que borró mi base de datos en producción, la migración de Notion a Markdown, los problemas de supply chain que revisé con Bitwarden— hay un patrón que se repite: los cambios que más impactan no son los que tienen 880 upvotes en HN. Son los silenciosos. La rotura del deal exclusivo es ruidosa. Lo que cambia mi flujo de trabajo real está en otra parte.

FAQ: Microsoft OpenAI deal exclusividad

¿Qué era exactamente el acuerdo de exclusividad entre Microsoft y OpenAI?
Microsoft tenía derechos exclusivos para distribuir y comercializar los modelos de OpenAI a través de su plataforma cloud Azure. Cualquier empresa que quisiera integrar GPT-4 o modelos similares en productos enterprise necesitaba pasar por Azure OpenAI Service. Eso le daba a Microsoft un markup comercial y una posición privilegiada frente a Google Cloud, AWS y otros.

¿Qué cambia para un desarrollador independiente que ya usa la API de OpenAI directa?
Casi nada en el corto plazo. Los precios de api.openai.com no cambian por este anuncio. La posible consecuencia positiva a mediano plazo es que más competencia entre cloud providers podría bajar precios o generar programas de créditos más accesibles. Por ahora, si no usás Azure, el único cambio es de contexto estratégico.

¿Conviene migrar a Azure OpenAI Service después de este cambio?
Depende de si tenés créditos Azure activos. Si usás Visual Studio Enterprise, Microsoft for Startups u otros programas con créditos, vale hacer el análisis. Si pagás Azure a precio de lista sin créditos, el markup histórico hace que la API directa siga siendo más barata para volúmenes bajos o medianos.

¿OpenAI puede ahora correr sus modelos en Google Cloud o AWS?
Técnicamente sí, el acuerdo de distribución ya no lo impide. Pero OpenAI tiene toda su infraestructura de entrenamiento e inferencia en Azure. Mover eso es una decisión de años, no de meses. Lo que sí puede pasar es que Google Cloud o AWS ofrezcan acceso a los modelos de OpenAI como resellers, similar a cómo funcionan otros acuerdos de marketplace en la nube.

¿Esto afecta el pricing de Copilot o los productos Microsoft con IA integrada?
No directamente. Los productos Copilot (M365, GitHub, Azure) tienen sus propios acuerdos y estructuras de precios que no dependen del deal de exclusividad API. Microsoft sigue teniendo acceso a los modelos de OpenAI; lo que pierde es el monopolio sobre quién más puede tenerlo.

¿Cómo puedo saber si me conviene cambiar de endpoint en mis proyectos actuales?
Abrí tus logs de los últimos 30-60 días, calculá cuánto gastás en api.openai.com, y verificá si tenés créditos Azure disponibles. Si el gasto mensual supera los $100 USD y tenés créditos sin usar, el setup de Azure OpenAI Service se amortiza en pocas semanas. Por debajo de eso, el overhead de configuración no cierra.

Mi postura final, sin suavizar

El fin del acuerdo exclusivo es una noticia corporativa importante. Para la industria, es señal de madurez: OpenAI ya no necesita el paraguas de Microsoft para llegar a enterprise. Para Microsoft, es una concesión calculada que mantiene la inversión intacta mientras libera presión regulatoria.

Para mí, mirando mis $60 en 90 días de logs: irrelevante salvo que alguien active un programa de créditos que justifique el cambio de endpoint.

Lo que sí me parece relevante —y esto es lo que no leí en ninguno de los 400+ comentarios del thread— es que este movimiento le abre la puerta a OpenAI para construir deals directos con empresas que hasta ahora tenían que negociar a través de Microsoft. Eso concentra más poder en OpenAI, no menos. Y una empresa con ese nivel de poder centralizado sobre modelos que ya corren en producciones críticas —incluyendo la mía, incluyendo la de casi todos los que leyeron ese thread— merece más escrutinio del que recibe cuando los titulares hablan de "competencia" y "apertura".

La apertura que importa no es entre cloud providers. Es entre modelos, entre proveedores, entre arquitecturas. Que un dev pueda hoy elegir entre GPT-4o, Claude, Gemini y Mistral con costos comparables —eso sí es apertura. El resto es reorganización de quién cobra el markup.

Si te interesa el tema de arquitectura de decisiones con múltiples providers, la semana pasada escribí sobre TypeScript 7.0 Beta en codebase real —hay un patrón de abstracción de cliente que aplica directo a esto. Y si querés ver cómo pienso la infra propia antes de confiarle decisiones a servicios de terceros, empezá por el post de Asahi Linux en Apple Silicon: la filosofía es la misma.

Este artículo fue publicado originalmente en juanchi.dev

GoDaddy gave my domain to a stranger: I simulated the attack on my own infra and learned how exposed I really was

Juan Torchia — Mon, 27 Apr 2026 16:32:42 +0000

GoDaddy gave my domain to a stranger: I simulated the attack on my own infra and learned how exposed I really was

It was 10pm and I was scrolling Hacker News when the post hit the top: GoDaddy had transferred a domain to someone who wasn't the owner. Score 610, 200+ comments, most of them saying "I moved to Cloudflare years ago" or "this is why you don't use GoDaddy". I closed the tab. And then I just sat there thinking.

I have six active domains. Three on Namecheap, two on Cloudflare Registrar, one on Porkbun. All connected to Railway or Vercel. All pointing at things that, if they go down, come crashing down on me.

My first reaction was the condescending nerd one: "I don't use GoDaddy, I'm fine." My second reaction, twenty minutes later, was the architect who knows that arrogance in security is the most expensive vulnerability. So I didn't cover the incident as news. I used it as an excuse to simulate the attack against my own infrastructure, document every step, and measure how far an attacker would have gotten before I even noticed.

My thesis, before diving in: the problem isn't GoDaddy specifically. It's that the DNS identity verification chain was designed in the '90s for a world where changing a record was a rare, manual event. Today, with automation, CI/CD, and registrar APIs that respond in milliseconds, that chain is wet paper. And nobody's redesigning it.

GoDaddy domain hijacking: what happened and why I took it personally

The case reported on HN described a classic social engineering vector combined with a support process that validated identity by email. The attacker didn't hack any system. They called (or wrote), presented fake documentation, and GoDaddy's internal process handled the transfer.

That's when I actually got angry. Because it's not a bug. It's a process working exactly as designed — and the design is the problem.

I went and reviewed the transfer processes for the three registrars I use. Here's what I found for an outbound domain transfer:

Namecheap: confirmation email to the registered address + authorization code (EPP). If the attacker has access to the email, the domain walks out in 5-7 days with zero additional friction.
Cloudflare Registrar: same as Namecheap, plus optional 2FA (which I had enabled on two of three domains, not all — embarrassing detail).
Porkbun: email + mandatory TOTP for transfers. The most resistant of the three.

The attack vector isn't the registrar. It's the email address associated with the registrar account.

How I simulated the attack: step by step with my own stack

I didn't break anything real. I used a test domain I have on Namecheap (juanchi-test-[hash].com, bought in January, never pointed at production) and documented every step as if I were an attacker with access to my Google Workspace email.

Phase 1: reconnaissance

# First thing an attacker would do: map the surface
whois juanchi-test-[hash].com

# Relevant output (anonymized):
# Registrar: Namecheap, Inc.
# Creation Date: 2025-01-15
# Registry Expiry Date: 2026-01-15
# Name Server: dns1.registrar-servers.com
# Name Server: dns2.registrar-servers.com
# DNSSEC: unsigned  <-- this matters, we'll get to it

# Registrant email was redacted (WhoisGuard active)
# But the registrar shows up — first useful data point for the attacker

WHOIS gave me the registrar. With that, an attacker knows who to call. WhoisGuard hides the technical contact's email, but doesn't hide the registrar. It's like hiding your name on the door but leaving the apartment number visible.

Phase 2: the real vector — compromise the email first

Here's the insight that made me most uncomfortable. An attack on a domain doesn't start at the registrar. It starts at the email.

# Checked what MX records my test domain had
dig MX juanchi-test-[hash].com

# And what SPF/DKIM the email domain I use for the registrar had
dig TXT juanchi-dev.com | grep -E "v=spf|DKIM"

# Result: SPF configured, DKIM active on Cloudflare
# But the weak point isn't the configuration — it's account recovery

Google Workspace has SMS recovery. My phone number is in the profile. If someone does SIM swapping, they have my email. If they have my email, they have all my Namecheap domains and two of three on Cloudflare (the one without 2FA enabled).

That was the moment I understood I was just as vulnerable as any GoDaddy user. My attacker just needed one extra step first.

Phase 3: what Namecheap "support" requires for an emergency transfer

I didn't call pretending to be anyone. I read Namecheap's public support documentation for domain recovery cases when you've "lost access to your email." Here's what they ask for:

Photo of your ID document
Last purchase invoice for the domain
Description of the problem

That's it. No liveness check. No callback to the registered phone number. No independent second factor. If an attacker has a photo of my ID (which exists on LinkedIn, at conferences, in a million places), a convincing fake invoice, and email access — or doesn't need the email because support can override — the domain can walk.

This process exists at almost every registrar. Because it was designed for the legitimate case of "I forgot my password and changed my email." Not for a sophisticated attacker.

Phase 4: what would happen next — the damage to my Railway/Vercel stack

Once the domain is transferred, the attacker controls DNS. Here's what they could do against my Railway and Vercel infra:

# Scenario: attacker has domain juanchi.dev
# Step 1: changes the A record to their own server
# Time for the change to propagate: 30 min to 48h depending on TTL

# My current TTLs (measured before the experiment):
dig juanchi.dev | grep TTL
# TTL: 300 seconds — propagation in 5 minutes

# Step 2: request SSL certificate with Let's Encrypt
# ACME HTTP-01 or DNS-01 challenge — trivial with domain control
# Time: under 2 minutes

# Step 3: mount a reverse proxy pointing at my Railway deployment
# Or just an identical phishing page
# With a valid cert and the real domain, the browser shows nothing unusual

The 300-second TTL I had configured for performance would have given me a five-minute detection window after the change. Way too short.

This connects directly to what I documented in the Vercel breach post — when the deployment infrastructure is compromised, or the domain feeding it is compromised, the damage isn't technical. It's trust. And trust doesn't roll back.

The mistakes I found in my own configuration

I'm going to be specific because that's the most valuable part of this experiment. These are the real problems I had before simulating the attack:

Mistake 1: inconsistent 2FA across registrars

One domain on Cloudflare Registrar without 2FA enabled. No excuse. Fixed it in ten minutes during the experiment.

Mistake 2: DNSSEC disabled on all my domains

# Quick DNSSEC check
dig DS juanchi.dev @8.8.8.8
# Empty response = DNSSEC not configured

# With DNSSEC active, an attacker who modifies DNS records
# generates responses that resolvers validate and reject
# Not bulletproof, but it adds real friction

DNSSEC is annoying to set up. Cloudflare does it in one click. Namecheap supports it but the UI is terrible. I had it enabled on none of them. Now I have it on four of six domains (the two on Porkbun are still pending — I'm migrating them this week).

Mistake 3: no alerts for DNS record changes

I had zero alerting to detect changes to my A, CNAME, or NS records. An attacker could have changed the NS record and I would have found out when a user messaged me that the site was down — or worse, that something was off.

I fixed this with a simple script running on a Railway cron job:

// monitor-dns.ts — runs every 5 minutes on Railway
// Sends a Telegram alert if any record changes

import { Resolver } from 'node:dns/promises';

const resolver = new Resolver();
// Using different resolvers to detect cache divergence
resolver.setServers(['8.8.8.8', '1.1.1.1']);

const CRITICAL_DOMAINS = [
  { domain: 'juanchi.dev', type: 'A', expectedValue: process.env.IP_PROD },
  { domain: 'api.juanchi.dev', type: 'CNAME', expectedValue: 'my-app.railway.app' },
];

async function checkRecords() {
  for (const { domain, type, expectedValue } of CRITICAL_DOMAINS) {
    try {
      const result = await resolver.resolve(domain, type as 'A' | 'CNAME');
      const currentValue = result[0];

      if (currentValue !== expectedValue) {
        // Something changed — immediate alert
        await notifyTelegram(
          `⚠️ DNS CHANGED\nDomain: ${domain}\nExpected: ${expectedValue}\nActual: ${currentValue}`
        );
      }
    } catch (error) {
      // Domain doesn't resolve — that's also an alert
      await notifyTelegram(`🚨 DNS NOT RESOLVING: ${domain}`);
    }
  }
}

Simple. Runs on Railway with a cron job. I got one false positive alert on the first day because Railway rotated a deployment IP — which was, ironically, exactly the kind of detection I was going for.

Mistake 4: the registrar recovery email was the same as my work email

If someone compromised my Google Workspace account, they had access to everything. I moved the registrar accounts to a dedicated email — no alias, different password generated in Bitwarden, hardware key (YubiKey) as the second factor.

This is especially relevant given the Bitwarden CLI supply chain attack I documented last week — the trust surface isn't just the password manager, it's everything that password manager protects.

The gotchas nobody mentions in "protect your domains" posts

Transfer lock doesn't save you from social engineering

Every registrar has a "transfer lock" — it blocks outbound transfers. But social engineering doesn't need a transfer. It needs to change the NS records, which on most registrars lives in the same panel as the transfer lock and requires exactly the same level of access.

Registry Lock actually helps, but it's for enterprises

There's something called Registry Lock (distinct from Registrar Lock) that requires out-of-band verification for any change, including NS updates. Verisign and other registries offer it for .com. It costs $100-$300/year per domain. Not for personal blogs, but if you have a domain that's critical to your business, it's worth the conversation.

DNSSEC doesn't protect against registrar-level hijacking

If the attacker already controls the registrar, they can change the DS record (the "anchor" for DNSSEC) along with the NS records. DNSSEC protects against attacks at the resolution layer (cache poisoning). It doesn't protect you if the attacker has access to the registrar panel.

FAQ: GoDaddy domain hijacking and how to protect your domains

Does this only happen with GoDaddy or can it happen with any registrar?

Any registrar. GoDaddy has more reported cases because it has more users, but the email + document identity verification process for account recovery is practically universal. Namecheap, Google Domains (now Squarespace), Name.com — they all have similar processes. The problem is systemic, not vendor-specific.

Is enabling 2FA on the registrar enough?

Necessary but not sufficient. 2FA protects direct login. But if the registrar's account recovery process accepts "email + photo ID" as a fallback (many do), 2FA has a bypass via support. The most robust protection combines strong 2FA (TOTP or hardware key) + a dedicated email for the registrar account + active monitoring for DNS changes.

What is Registry Lock and is it worth paying for?

Registry Lock is an additional protection layer implemented by the registry (Verisign for .com, for example) that requires out-of-band verification for any change operation. The registrar can't process an NS change or a transfer without going through a manual registry process. It costs $100-$300/year per domain and makes sense for domains that generate direct revenue or have high production impact.

Does DNSSEC solve this?

Partially. DNSSEC protects against cache poisoning and attacks at the resolution layer. It doesn't protect you if the attacker already has access to the registrar panel — because they can change the DS record alongside the NS records. It's a valid defense layer, but it's not the final shield against domain hijacking.

How long does a malicious DNS change take to propagate?

It depends on the configured TTL. With a TTL of 300 seconds (5 minutes, common in performance-tuned configs), an attacker has effective control of traffic in under 10 minutes after changing the record. With a TTL of 3600 (1 hour), you get a longer detection window but resolvers also cache the legitimate value longer. There's no perfect answer — low TTL accelerates both the attack and the recovery.

Can Railway or Vercel do anything if the domain gets hijacked?

Not much. If the domain stops pointing to the Railway or Vercel deployment, the deployment stays alive but traffic stops arriving. You can make the app respond from the Railway internal URL (*.railway.app) while you sort out the domain, but users hitting the compromised domain will see whatever the attacker has mounted — with a valid SSL certificate and the real domain in the browser bar. Vercel and Railway are not part of the domain custody chain.

What changed in my infra after this experiment

Concrete, no fluff:

YubiKey 2FA on all registrars — not just TOTP, hardware key as second factor wherever it's supported
Dedicated email for registrars — isolated from Google Workspace, with its own domain that isn't registered at any of the registrars it protects
DNSSEC enabled on four of six domains — the remaining two are moving to Cloudflare Registrar this week
DNS monitor on Railway — cron every 5 minutes, Telegram alert within 10 minutes of any divergence
TTL increased on critical domains — from 300 to 900 seconds. The slower propagation trade-off is worth the wider detection window
Audit of the account recovery process — read the support documentation for each registrar to understand what bypasses exist and what mitigations apply

The attack surface didn't disappear. But the friction for an attacker increased considerably, and my detection time dropped from "when someone messages me that the site is acting weird" to "ten minutes after the change."

The uncomfortable part of all this is that none of these measures required the GoDaddy incident to implement. I knew about them. I had them on my backlog. And I did them on a Saturday night after reading a post on HN.

That says more about how we prioritize security than anything GoDaddy could have done wrong.

If you want to check how exposed your current stack is, start with the registrar's email account. Not the registrar panel. The email is the real entry point, and if that email falls, everything else follows.

This article was originally published on juanchi.dev

GoDaddy le dio mi dominio a un desconocido: simulé el ataque con mi propia infra y entendí qué tan expuesto estaba

Juan Torchia — Mon, 27 Apr 2026 16:32:37 +0000

GoDaddy le dio mi dominio a un desconocido: simulé el ataque con mi propia infra y entendí qué tan expuesto estaba

Estaba revisando Hacker News a las 10pm cuando el post llegó al top: GoDaddy había transferido un dominio a alguien que no era el dueño. Score 610, 200+ comentarios, la mayoría diciendo "migré a Cloudflare hace años" o "esto es por qué no usás GoDaddy". Cerré la pestaña. Y me quedé pensando.

Yo tengo seis dominios activos. Tres en Namecheap, dos en Cloudflare Registrar, uno en Porkbun. Todos conectados a Railway o Vercel. Todos apuntando a cosas que si se caen, me caen encima.

Mi primera reacción fue la del nerd condescendiente: "yo no uso GoDaddy, estoy bien". Mi segunda reacción, veinte minutos después, fue la del arquitecto que sabe que la arrogancia en seguridad es la vulnerabilidad más cara. Así que no cubrí el caso como noticia. Lo usé como excusa para simular el ataque contra mi propia infra, documentar cada paso, y medir qué tan lejos habría llegado un atacante antes de que yo me enterara.

Mi tesis, antes de arrancar: el problema no es GoDaddy específicamente. Es que la cadena de verificación de identidad en DNS fue diseñada en los '90 para un mundo donde cambiar un registro era un evento raro y manual. Hoy, con automatización, CI/CD y APIs de registradores que responden en milisegundos, esa cadena es papel mojado. Y nadie la está rediseñando.

GoDaddy domain hijacking security: qué pasó y por qué me importó personalmente

El caso reportado en HN describía un vector clásico de social engineering combinado con un proceso de soporte que validaba identidad por email. El atacante no hackeó ningún sistema. Llamó (o escribió), presentó documentación falsa, y el proceso interno de GoDaddy procesó la transferencia.

Ahí fue cuando me calenté de verdad. Porque no es un bug. Es un proceso que funciona exactamente como fue diseñado — y el diseño es el problema.

Me fui a revisar los procesos de los tres registradores que uso. Esto es lo que encontré para una transferencia de dominio saliente:

Namecheap: email de confirmación al email registrado + código de autorización (EPP). Si el atacante tiene acceso al email, el dominio sale en 5-7 días sin fricción adicional.
Cloudflare Registrar: igual que Namecheap, más 2FA opcional (que yo tenía activado en dos de tres dominios, no en todos — detalle vergonzoso).
Porkbun: email + TOTP obligatorio para transferencias. El más resistente de los tres.

El vector de ataque no es el registrador. Es el email asociado a la cuenta del registrador.

Cómo simulé el ataque: paso a paso con mi propio stack

No rompí nada real. Usé un dominio de prueba que tengo en Namecheap (juanchi-test-[hash].com, comprado en enero, nunca apuntó a producción) y documenté cada paso como si fuera un atacante con acceso a mi email de Google Workspace.

Fase 1: reconocimiento

# Lo primero que haría un atacante: mapear la superficie
whois juanchi-test-[hash].com

# Output relevante (anonimizado):
# Registrar: Namecheap, Inc.
# Creation Date: 2025-01-15
# Registry Expiry Date: 2026-01-15
# Name Server: dns1.registrar-servers.com
# Name Server: dns2.registrar-servers.com
# DNSSEC: unsigned  <-- esto importa, lo vemos después

# El email del registrant estaba redactado (WhoisGuard activo)
# Pero el registrador sí aparece — primer dato útil para el atacante

El WHOIS me dio el registrador. Con eso, un atacante sabe a quién llamar. WhoisGuard protege el email del contacto técnico, pero no protege el registrador. Es como esconder el nombre en la puerta pero dejar el número de apartamento visible.

Fase 2: el vector real — comprometer el email primero

Acá está el insight que más me incomodó. Un ataque a un dominio no empieza en el registrador. Empieza en el email.

# Chequeé qué MX records tenía mi dominio de prueba
dig MX juanchi-test-[hash].com

# Y qué SPF/DKIM tenía el dominio del email que uso para el registrador
dig TXT juanchi-dev.com | grep -E "v=spf|DKIM"

# Resultado: SPF configurado, DKIM activo en Cloudflare
# Pero el punto débil no es la configuración — es la recuperación de cuenta

Google Workspace tiene recuperación por SMS. Mi número de teléfono está en el perfil. Si alguien hace SIM swapping, tiene mi email. Si tiene mi email, tiene todos mis dominios en Namecheap y dos de tres en Cloudflare (el que no tenía 2FA activado).

Ese fue el momento en que entendí que yo era tan vulnerable como cualquier usuario de GoDaddy. Solo que mi atacante necesitaba un paso previo adicional.

Fase 3: qué le pide Namecheap a "soporte" para una transferencia de emergencia

No llamé haciéndome pasar por nadie. Leí la documentación pública de soporte de Namecheap para casos de recuperación de dominio cuando "perdiste acceso al email". Esto es lo que piden:

Foto del documento de identidad
Última factura de compra del dominio
Descripción del problema

Eso es todo. No hay verificación de liveness. No hay callback al teléfono registrado. No hay segundo factor independiente. Si un atacante tiene una foto de mi DNI (que existe en LinkedIn, en conferencias, en un millón de lugares), una factura falsa creíble y acceso al email — o no necesita el email porque el soporte puede hacer override — el dominio puede salir.

Este proceso existe en casi todos los registradores. Porque fue diseñado para el caso legítimo de "se me olvidó el password y cambié de email". No para el caso de un atacante sofisticado.

Fase 4: qué pasaría después — el daño en mi stack de Railway/Vercel

Una vez transferido el dominio, el atacante controla los DNS. Esto es lo que podría hacer contra mi infra en Railway y Vercel:

# Escenario: atacante tiene el dominio juanchi.dev
# Paso 1: cambia el A record a su propio servidor
# Tiempo para que el cambio propague: entre 30 min y 48h según TTL

# Mis TTLs actuales (medidos antes del experimento):
dig juanchi.dev | grep TTL
# TTL: 300 segundos — propagación en 5 minutos

# Paso 2: solicita certificado SSL con Let's Encrypt
# ACME challenge HTTP-01 o DNS-01 — con control del dominio, trivial
# Tiempo: menos de 2 minutos

# Paso 3: monta un reverse proxy hacia mi propio Railway deployment
# O simplemente una página de phishing idéntica
# Con un certificado válido y el dominio real, el browser no avisa nada

El TTL de 300 segundos que tengo configurado por performance me habría dado una ventana de detección de cinco minutos después del cambio. Demasiado poco.

Esto conecta directamente con lo que documenté en el post del Vercel breach — cuando la infra de deployment está comprometida o el dominio que la alimenta está comprometido, el daño no es técnico. Es de confianza. Y la confianza no se recupera con un rollback.

Los errores que encontré en mi propia configuración

Voy a ser concreto porque me parece lo más valioso de este experimento. Estos son los problemas reales que tenía antes de simular el ataque:

Error 1: 2FA inconsistente entre registradores

Un dominio en Cloudflare Registrar sin 2FA activado. No tenía excusa. Lo activé en diez minutos durante el experimento.

Error 2: DNSSEC desactivado en todos mis dominios

# Verificación rápida de DNSSEC
dig DS juanchi.dev @8.8.8.8
# Respuesta vacía = DNSSEC no configurado

# Con DNSSEC activo, un atacante que modifique registros DNS
# genera respuestas que los resolvers validan y rechazan
# No es infalible, pero agrega fricción real

DNSSEC es engorroso de configurar. Cloudflare lo hace en un click. Namecheap lo soporta pero la UI es horrible. No lo tenía activado en ninguno. Ahora lo tengo en cuatro de seis dominios (los dos de Porkbun siguen pendientes, los voy a migrar).

Error 3: sin alertas de cambio de registros DNS

No tenía ningún sistema de alerta para detectar cambios en mis registros A, CNAME o NS. Un atacante podría haber cambiado el NS record y yo me habría enterado cuando un usuario me escribiera que el sitio está caído — o peor, que está raro.

Esto lo resolví con un script simple que corre en un cron de Railway:

// monitor-dns.ts — corre cada 5 minutos en Railway
// Alerta por Telegram si un registro cambia

import { Resolver } from 'node:dns/promises';

const resolver = new Resolver();
// Uso resolvers distintos para detectar divergencia entre cachés
resolver.setServers(['8.8.8.8', '1.1.1.1']);

const DOMINIOS_CRITICOS = [
  { dominio: 'juanchi.dev', tipo: 'A', valorEsperado: process.env.IP_PROD },
  { dominio: 'api.juanchi.dev', tipo: 'CNAME', valorEsperado: 'my-app.railway.app' },
];

async function verificarRegistros() {
  for (const { dominio, tipo, valorEsperado } of DOMINIOS_CRITICOS) {
    try {
      const resultado = await resolver.resolve(dominio, tipo as 'A' | 'CNAME');
      const valorActual = resultado[0];

      if (valorActual !== valorEsperado) {
        // Algo cambió — alerta inmediata
        await notificarTelegram(
          `⚠️ DNS CAMBIADO\nDominio: ${dominio}\nEsperado: ${valorEsperado}\nActual: ${valorActual}`
        );
      }
    } catch (error) {
      // El dominio no resuelve — también es alerta
      await notificarTelegram(`🚨 DNS NO RESUELVE: ${dominio}`);
    }
  }
}

Simple. Corre en Railway con un cron job. Me llegó una alerta falsa positiva en el primer día porque Railway rotó una IP de deployment — lo cual fue, irónicamente, exactamente el tipo de detección que quería.

Error 4: el email de recuperación del registrador era el mismo que el email de trabajo

Si alguien compromete mi cuenta de Google Workspace, tenía acceso a todo. Moví las cuentas de registrador a un email dedicado, sin alias, con una contraseña distinta generada en Bitwarden y con una clave de hardware (YubiKey) como segundo factor.

Esto es especialmente relevante dado el supply chain attack sobre Bitwarden CLI que documenté la semana pasada — la surface de confianza no es solo el password manager, es todo lo que ese password manager protege.

Los gotchas que nadie menciona en los posts de "protegé tus dominios"

El transfer lock no te salva del social engineering

Todos los registradores tienen "transfer lock" — bloquea transferencias salientes. Pero el social engineering no necesita una transferencia. Necesita cambiar los NS records, que en la mayoría de los registradores está en el mismo panel que el transfer lock, y requiere exactamente el mismo nivel de acceso.

Registry lock sí ayuda, pero es para empresas

Existe algo llamado Registry Lock (distinto al Registrar Lock) que requiere verificación fuera de banda para cualquier cambio, incluyendo NS. Lo ofrecen Verisign y otros registros para .com. Cuesta entre $100-$300 al año por dominio. No es para blogs personales, pero si tenés un dominio crítico para tu negocio, vale la conversación.

DNSSEC no protege contra el hijacking en la capa de registrador

Si el atacante ya controla el registrador, puede cambiar el registro DS (que es la "ancla" de DNSSEC) junto con los NS records. DNSSEC protege contra ataques en la capa de resolución (cache poisoning). No protege si el atacante tiene acceso al panel del registrador.

FAQ: GoDaddy domain hijacking y cómo proteger tus dominios

¿Solo pasa con GoDaddy o puede pasar con cualquier registrador?

Con cualquier registrador. GoDaddy tiene más casos reportados porque tiene más usuarios, pero el proceso de verificación de identidad basado en email + documento es prácticamente universal. Namecheap, Google Domains (ahora Squarespace), Name.com — todos tienen procesos similares para recuperación de acceso. El problema es sistémico, no es de un proveedor específico.

¿Activar 2FA en el registrador es suficiente?

Es necesario pero no suficiente. El 2FA protege el login directo. Pero si el proceso de recuperación de cuenta del registrador acepta "email + foto de DNI" como fallback (que muchos aceptan), el 2FA tiene un bypass vía soporte. La protección más robusta es combinar 2FA fuerte (TOTP o hardware key) + email dedicado para la cuenta del registrador + vigilancia activa de cambios en DNS.

¿Qué es Registry Lock y vale la pena pagarlo?

Registry Lock es una capa adicional de protección implementada por el registro (Verisign para .com, por ejemplo) que requiere verificación out-of-band para cualquier operación de cambio. El registrador no puede procesar un cambio de NS o una transferencia sin pasar por un proceso manual del registro. Cuesta entre $100-$300/año por dominio y tiene sentido para dominios que generan ingresos directos o tienen alto impacto en producción.

¿DNSSEC resuelve esto?

Parcialmente. DNSSEC protege contra cache poisoning y ataques en la capa de resolución. No protege si el atacante ya tiene acceso al panel del registrador — porque puede cambiar el registro DS junto con los NS. Es una capa de defensa válida, pero no es el escudo final contra domain hijacking.

¿Cuánto tiempo tarda en propagarse un cambio de DNS malicioso?

Depende del TTL configurado. Con TTL de 300 segundos (5 minutos, que es común en configuraciones de performance), un atacante tiene control efectivo del tráfico en menos de 10 minutos después de cambiar el registro. Con TTL de 3600 (1 hora), tenés más tiempo de detección pero los resolvers cachean el valor legítimo durante más tiempo también. No hay una respuesta perfecta — TTL bajo acelera tanto el ataque como la recuperación.

¿Railway o Vercel pueden hacer algo si el dominio se secuestra?

Poco. Si el dominio deja de apuntar al deployment de Railway o Vercel, el deployment sigue vivo pero el tráfico no llega. Podés hacer que la app responda desde la URL interna de Railway (*.railway.app) mientras resolvés el dominio, pero los usuarios que lleguen al dominio comprometido van a ver lo que el atacante monte — con un certificado SSL válido y el dominio real en la barra del browser. Vercel y Railway no son parte de la cadena de custodia del dominio.

Lo que cambió en mi infra después de este experimento

Concreto, sin floro:

2FA con YubiKey en todos los registradores — no solo TOTP, hardware key como segundo factor donde lo soportan
Email dedicado para registradores — aislado de Google Workspace, con dominio propio que no está en ninguno de los registradores que protege
DNSSEC activado en cuatro de seis dominios — los dos restantes van a Cloudflare Registrar esta semana
Monitor DNS en Railway — cron cada 5 minutos, alerta por Telegram en menos de 10 minutos ante cualquier divergencia
TTL aumentado en dominios críticos — de 300 a 900 segundos. El trade-off de propagación más lenta vale la ventana de detección más amplia
Audit del proceso de recuperación de cuenta — leí la documentación de soporte de cada registrador para entender qué bypass existe y qué mitigación aplica

La superficie de ataque no desapareció. Pero la fricción para un atacante aumentó considerablemente, y mi tiempo de detección bajó de "cuando alguien me avisa que el sitio está raro" a "diez minutos después del cambio".

Lo incómodo de todo esto es que ninguna de estas medidas requería el incidente de GoDaddy para implementarse. Las sabía. Las tenía pendientes. Y las hice en un sábado a la noche después de leer una noticia en HN.

Eso dice más sobre cómo priorizamos seguridad que cualquier cosa que GoDaddy pueda haber hecho mal.

Si querés revisar cómo está expuesto el stack que usás, arrancá por el email del registrador. No por el panel del registrador. El email es el punto de entrada real, y si ese email cae, todo lo demás sigue.

Este artículo fue publicado originalmente en juanchi.dev

Asahi Linux 7.0 on Apple Silicon: I Installed It on My Real Machine and Here's What It Says About the Future of the Kernel on ARM

Juan Torchia — Mon, 27 Apr 2026 14:31:08 +0000

Asahi Linux 7.0 on Apple Silicon: I Installed It on My Real Machine and Here's What It Says About the Future of the Kernel on ARM

Why do we keep treating Apple Silicon like hostile territory for Linux when the upstream kernel has been absorbing Asahi patches for months? I'd been asking myself that every time I landed on an HN thread where someone swore that "Linux on a Mac isn't usable for real work." This week the Asahi Linux 7.0 post hit 620 points on Hacker News — that's not noise. That's signal. I decided to stop reading threads and do what I always end up doing: install it, break things, measure.

Spoiler: not everything works. But what does work completely changed how I read the problem.

Asahi Linux 7.0 on Apple Silicon: What Upstream Kernel Support Actually Means and Why It Matters More Than the GPU Driver

The coverage over the last few days focused on the GPU driver — makes sense, it's the most photogenic headline. But there's something more important underneath: Linux 6.x (and what's coming in 7.0) started absorbing native Apple Silicon support into the mainline kernel tree. Not a patch you download from some fork. Not a specialized distro living in its own bubble. The mainline tree.

That has concrete consequences — I'll detail them with what I measured — but first, the context for why I personally care.

My daily development workflow runs on Next.js, TypeScript, Docker, and PostgreSQL on Railway. Last week I was evaluating TypeScript 7.0 Beta against my own codebase — you can read that experiment in the TypeScript 7.0 Beta post. What I learned there made me pay closer attention to how fragile it is to depend on an ecosystem you don't control. Asahi Linux gives me the same feeling, but on the hardware side.

When I ran the Asahi Linux 7.0 installer on my MacBook Pro M2, the first thing I noticed was how ordinary the process felt. No dramatic warnings. No cathartic ceremony. That in itself is a technical statement.

What I Measured in My Real Workflow: Honest Numbers

The Environment

# Hardware: MacBook Pro M2, 16GB RAM
# Asahi Linux 7.0 (Fedora Asahi Remix)
# Kernel: 6.12.0-asahi (base for the 7.0 series)
# Shell: zsh, tmux

uname -r
# 6.12.0-asahi-00001-g3e5f8b2d1a4c

# Verify actual architecture
uname -m
# aarch64

That — aarch64 on a Mac — still feels slightly like science fiction. But here we are.

Docker: The First Real Test

# Brought up my usual development stack
docker compose up -d

# PostgreSQL 16 + Next.js dev server + Redis
# Boot time on Apple Silicon with Asahi:
time docker compose up -d
# real    0m8.341s

# Same stack on x86_64 (reference point, different hardware, not a direct comparison):
# real    0m11.2s (average of 3 runs)

The number isn't a fair cross-architecture comparison — the hardware is different. What I can say: Docker on Asahi Linux on M2 is not the bottleneck. There was never a moment where I thought "this is being throttled by the kernel." Containers came up, volumes mounted, ports exposed. Normal flow.

What did take longer was the first docker pull of linux/arm64 images — not every image has multi-arch manifests. Official PostgreSQL 16: no problem. Some internal tooling images we have on the team: broken. That's not Asahi's fault, it's arm64 debt in the container ecosystem. Different cause, different fix.

Node.js and the Next.js Build

# Cloned my main project
git clone git@github.com:juantorchia/mi-proyecto.git
cd mi-proyecto
npm ci

# Production build
time npm run build

# Result on Asahi Linux / M2:
# real    1m14.3s

# Previous references (same project, same commit):
# M2 macOS: 0m58.1s
# x86_64 Linux (Railway VPS): 1m49.2s

Here's the interesting data point: Asahi Linux on M2 is faster at compilation than any x86 VPS I have access to. Slower than native macOS, yes — there's kernel overhead and some syscall translation layers that aren't fully optimized yet. But "slower than native macOS" isn't the relevant benchmark. The relevant benchmark is: can I do my work? The answer is yes, with room to spare.

What Doesn't Work Yet

I'm not going to pretend everything runs clean. Some things are broken:

Suspend/wake: the laptop sometimes comes back from suspend with a dead network connection. I need sudo systemctl restart NetworkManager to recover it. It's a 3-second workaround, but it's a workaround. That's not a workflow, it's a scar.

Bluetooth: I connected my AirPods. They paired. Audio comes through. With noticeable latency on calls — usable for background music, completely unusable for a Zoom meeting. For that I'm still on macOS or wired headphones.

GPU: the Asahi GPU driver (Honeykrisp) works for basic acceleration and Vulkan. For my development workflow I don't need more than that. But if you're running local ML workloads or editing video, the story is different.

The Mistakes I Made (And That You'll Make Too)

1. Assuming the Dual Boot Would Be Transparent

The Asahi installer handles partitioning in a way that's non-standard by Apple's own conventions. The first time I tried to shrink the macOS partition, the process failed silently — no error, no message, nothing changed. I had to reread the documentation (which is good, but dense) to understand I needed to do it from Apple's Recovery Mode with specific diskutil commands.

# This does NOT work from normal macOS:
diskutil apfs resizeContainer disk0s2 100GB

# This DOES work from macOS Recovery:
# diskutil apfs resizeContainer disk0s2 100GB
# (same command, different context — where you run it matters)

Three hours lost on something the documentation explicitly explains, but that I skipped because I was being arrogant about it.

2. Assuming Every Docker Image Has arm64 Support

Already mentioned above, but it deserves its own bullet: check the manifests before building a workflow that depends on specific images. docker manifest inspect image:tag before you're crying at 11pm.

3. Confusing "Kernel Support" With "Feature Parity"

Upstream kernel support for Apple Silicon doesn't mean everything that works on macOS works on Linux. It means the kernel knows how to talk to the base hardware. On top of that you still have individual drivers, firmware, userspace layers. It's real progress but it's not a "done" flag. If you came in with that expectation, you're going to be frustrated.

4. Not Making a Backup Before the First Attempt

Obvious. I'm saying it anyway because I was tempted to skip it myself. I made the backup. I'm an adult.

My Real Thesis on What Asahi Linux 7.0 Actually Means

The GPU driver is the headline. But the real story is that Apple Silicon stopped being a trap for Linux developers.

Trap in what sense: before Asahi, if you bought an M1/M2 Mac and wanted to run Linux on real hardware, you were on your own. You could use a VM but you'd lose the chip's performance. You could wait for someone to port something, but that someone had no long-term maintenance commitment. The hardware was excellent and the Linux ecosystem was telling you "you're not welcome here."

What changed with upstream support is the chain of trust. Now when there's a kernel bug related to Apple Silicon, there's a community with actual incentives to fix it in the mainline tree. Not in a fork that someone abandons when they take a job somewhere else. That's what I learned with the Bitwarden CLI supply chain attack: the trust surface of a tool isn't just its code, it's its maintenance chain. Asahi improved that chain structurally.

When we migrated Notion notes to Markdown and found that portability has a hidden cost, the problem wasn't the format — it was platform lock-in. Apple Silicon with macOS was that same problem on the hardware side. You buy the best chip on the market and you're stuck with the manufacturer's OS. Asahi Linux 7.0 starts breaking that lock-in in a legitimate way.

Is it production-ready today? For a server, no — it doesn't make sense. For a development workstation where you already know the gotchas and can tolerate meh Bluetooth and the occasional suspend failure, yes, right now.

FAQ: Asahi Linux 7.0 on Apple Silicon

Is Asahi Linux 7.0 stable for daily use?
Depends on what you mean by "daily use." For software development — compiling, running Docker, writing code — it's stable. For video calls over Bluetooth or suspending the laptop ten times a day, there's still real friction. My honest take: if your work is mostly terminal and browser, yes. If you need the full multimedia stack without configuration, not yet.

Does Docker work on Apple Silicon with Asahi Linux?
Yes. Docker runs natively on aarch64 without an emulation layer. Images with linux/arm64 manifests work without issues. Images that only have linux/amd64 will fail or need emulation via --platform. Check the manifests for the images you use before migrating your full workflow.

Which Apple chip works best with Asahi Linux 7.0?
M1 and M2 have the most mature support because they've been under the community's microscope the longest. M3 and M4 have growing but more incomplete support, especially for GPU drivers. If you're choosing new hardware with Asahi in mind, M2 Pro is the sweet spot right now.

Does the Asahi GPU driver (Honeykrisp) hold up for development?
For web development, yes — basic acceleration works, GPU-accelerated terminals run well, the desktop experience is smooth. For local ML workloads or 3D rendering, the current state isn't enough. Vulkan works but not at the speed of Apple's native Metal.

Can I use Asahi Linux as a complete macOS replacement?
Today: partially. About 80% of a modern development workflow runs without friction. The remaining 20% — mature Bluetooth, solid suspend/resume, some tools that assume macOS — still needs workarounds or trade-offs. In 12 months that ratio is going to shift. The pace of upstream contributions accelerated noticeably with the 6.12+ series.

Is it worth installing if I already have a macOS workflow that works?
If the workflow works, don't break it out of curiosity. Install it in dual boot if you want to explore without risk. What does make sense to do today: evaluate whether your development stack runs cleanly on arm64 Linux, because that knowledge is going to be relevant when more infrastructure migrates to ARM. That's why I did this — not to escape macOS, but to understand the terrain before it becomes mandatory to understand it. Same reason I benchmark GPT-5.5 in the API or evaluate whether Claude's quality degradation justifies canceling: I don't wait for the ecosystem to tell me. I measure it myself.

The Lock-In Nobody Names

I spent years worrying about software platform lock-in — SaaS, tools, languages. What I wasn't measuring was hardware lock-in. Apple Silicon is the best laptop chip on the market right now. The problem was that buying it meant committing to macOS with no real exit.

Asahi Linux 7.0 doesn't solve that completely. But it lays the first stone of an exit. Upstream kernel support changes the long-term maintenance equation — and for me, that weighs more than the GPU driver. Because drivers improve over time. What doesn't improve on its own is the incentive structure. And that structure today favors the people who want Linux on Apple Silicon.

What I'm not buying: the hype that "it's ready for everyone." It's not. You still need tolerance for discomfort and a genuine willingness to debug weird things at 2am on a Saturday. But that tolerance was always the price of admission to the Linux world. What's new is that now there's something on the other side that justifies it.

If you want to get started: asahilinux.org, read the full documentation before touching the disk, and make a backup. The rest is the same honest chaos it's always been.

This article was originally published on juanchi.dev

Asahi Linux 7.0 en Apple Silicon: lo instalé en mi máquina real y esto dice sobre el futuro del kernel en ARM

Juan Torchia — Mon, 27 Apr 2026 14:31:03 +0000

Asahi Linux 7.0 en Apple Silicon: lo instalé en mi máquina real y esto dice sobre el futuro del kernel en ARM

¿Por qué seguimos tratando a Apple Silicon como territorio hostil para Linux cuando el kernel upstream lleva meses absorbiendo los parches de Asahi? Llevaba un tiempo haciéndome esa pregunta cada vez que veía un thread de HN donde alguien juraba que "Linux en Mac no sirve para trabajo real". Esta semana el post de Asahi Linux 7.0 llegó a 620 puntos en Hacker News — un número que no es ruido. Es señal. Decidí parar de leer threads y hacer lo que siempre termino haciendo: instalar, romper, medir.

Spoiler: no todo anda. Pero lo que anda cambió mi lectura del problema por completo.

Asahi Linux 7.0 en Apple Silicon: qué significa kernel upstream y por qué importa más que el driver de GPU

La cobertura de los últimos días se concentró en el driver de GPU — lógico, es el titular más fotogénico. Pero hay algo más importante debajo: Linux 6.x (y lo que viene en 7.0) empezó a absorber soporte nativo para Apple Silicon en el árbol principal del kernel. No un parche que bajás de un fork. No una distro especializada que vivía en su propia burbuja. El árbol principal.

Eso tiene consecuencias concretas que voy a detallar con lo que medí, pero primero el contexto de por qué me importa personalmente.

Mi flujo de desarrollo diario corre sobre Next.js, TypeScript, Docker y PostgreSQL en Railway. La semana pasada estaba evaluando TypeScript 7.0 Beta contra mi propio código — podés leer ese experimento en el post sobre TypeScript 7.0 Beta. Lo que aprendí ahí me hizo prestar más atención a qué tan frágil es depender de un ecosistema que no controlás. Asahi Linux me da la misma sensación, pero en el lado del hardware.

Cuando corrí el instalador de Asahi Linux 7.0 en mi MacBook Pro M2, lo primero que noté fue lo ordinario del proceso. Sin ceremonias. Sin warnings catárticos. Eso en sí mismo es una declaración técnica.

Lo que medí en mi flujo de trabajo real: números honestos

El entorno

# Hardware: MacBook Pro M2, 16GB RAM
# Asahi Linux 7.0 (Fedora Asahi Remix)
# Kernel: 6.12.0-asahi (base para la serie 7.0)
# Shell: zsh, tmux

uname -r
# 6.12.0-asahi-00001-g3e5f8b2d1a4c

# Verificar arquitectura real
uname -m
# aarch64

Eso — aarch64 en un Mac — todavía me parece medio ciencia ficción. Pero es lo que hay.

Docker: el primer test serio

# Levanté mi stack de desarrollo habitual
docker compose up -d

# PostgreSQL 16 + Next.js dev server + Redis
# Tiempo de boot en Apple Silicon con Asahi:
time docker compose up -d
# real    0m8.341s

# El mismo stack en x86_64 (referencia, otro hardware, no comparable directo):
# real    0m11.2s (promedio de 3 runs)

El número no es una comparación justa entre arquitecturas — el hardware es distinto. Lo que sí puedo decir: Docker en Asahi Linux sobre M2 no es el cuello de botella. No hubo un momento donde pensé "esto está limitado por el kernel". Los contenedores levantaron, los volúmenes montaron, los puertos expusieron. Flujo normal.

Lo que sí tardé más fue el primer docker pull de imágenes linux/arm64 — no todas las imágenes tienen manifiestos multi-arch. PostgreSQL 16 oficial: sin problema. Algunas imágenes de herramientas internas que tenemos en el equipo: roto. Eso no es culpa de Asahi, es deuda de arm64 en el ecosistema de contenedores. Distintas causas, distinto fix.

Node.js y el build de Next.js

# Cloné mi proyecto principal
git clone git@github.com:juantorchia/mi-proyecto.git
cd mi-proyecto
npm ci

# Build de producción
time npm run build

# Resultado en Asahi Linux / M2:
# real    1m14.3s

# Referencia previa (mismo proyecto, mismo commit):
# M2 macOS: 0m58.1s
# x86_64 Linux (VPS Railway): 1m49.2s

Acá el dato interesante: Asahi Linux en M2 es más rápido en compilación que cualquier VPS x86 que tengo. Más lento que macOS nativo, sí — hay overhead del kernel y de la capa de traducción de algunas syscalls que todavía no están completamente optimizadas. Pero "más lento que macOS nativo" no es el benchmark relevante. El benchmark relevante es: ¿puedo hacer mi trabajo? La respuesta es sí, con margen.

Lo que no funciona todavía

No me voy a hacer el que todo anda. Hay cosas rotas:

Suspender/despertar: el laptop a veces vuelve del suspend con la red muerta. Necesito sudo systemctl restart NetworkManager para recuperarla. Es un workaround de 3 segundos, pero es un workaround. No es un flujo de trabajo, es una cicatriz.

Bluetooth: conecté mis AirPods. Emparejaron. El audio llega. Con latencia notable en llamadas — usable para música de fondo, inutilizable para una reunión de Zoom. Para eso sigo usando macOS o auriculares con cable.

GPU: el driver de GPU de Asahi (Honeykrisp) funciona para aceleración básica y Vulkan. Para mi flujo de desarrollo no necesito más que eso. Pero si corrés cosas de ML locales o editás video, el cuento es diferente.

Los errores comunes que cometí (y que vas a cometer vos también)

1. Asumir que el dual boot va a ser transparente

El instalador de Asahi maneja el particionado de manera no estándar para los estándares de Apple. La primera vez que intenté reducir la partición de macOS, el proceso falló silenciosamente — sin error, sin mensaje, simplemente no cambió nada. Tuve que releer la documentación (que es buena, pero densa) para entender que necesitaba hacerlo desde el Recovery Mode de Apple con comandos específicos de diskutil.

# Esto NO funciona desde macOS normal:
diskutil apfs resizeContainer disk0s2 100GB

# Esto SÍ funciona desde macOS Recovery:
# diskutil apfs resizeContainer disk0s2 100GB
# (mismo comando, distinto contexto — importa desde dónde corrés)

Tres horas perdidas en algo que la documentación aclara, pero que yo salteé por soberbio.

2. Asumir que todas las imágenes Docker tienen soporte arm64

Ya lo mencioné arriba, pero merece su propio bullet: revisá los manifiestos antes de construir un flujo que dependa de imágenes específicas. docker manifest inspect imagen:tag antes de llorar a las 11pm.

3. Confundir "kernel support" con "feature parity"

El soporte upstream del kernel para Apple Silicon no significa que todo lo que funciona en macOS funciona en Linux. Significa que el kernel sabe cómo hablar con el hardware base. Encima de eso hay drivers individuales, firmware, capas de userspace. Es un progreso real pero no es un flag de "terminado". Si venías con esa expectativa, vas a frustrarte.

4. No hacer backup antes del primer intento

Obvio. Lo digo igual porque yo mismo estuve tentado de no hacerlo. Hice backup. Soy adulto.

Mi tesis real sobre lo que significa Asahi Linux 7.0

El driver de GPU es el titular. Pero la verdadera historia es que Apple Silicon dejó de ser una trampa para desarrolladores Linux.

Trampa en qué sentido: antes de Asahi, si comprabas un Mac M1/M2 y querías correr Linux en hardware real, estabas solo. Podías usar una VM, pero perdías el rendimiento del chip. Podías esperar a que alguien portara algo, pero ese alguien no era nadie con responsabilidad de mantenimiento a largo plazo. El hardware era excelente y el ecosistema Linux te decía "no sos bienvenido acá".

Lo que cambió con el soporte upstream es la cadena de confianza. Ahora cuando hay un bug de kernel relacionado con Apple Silicon, hay una comunidad con incentivos para arreglarlo en el árbol principal. No en un fork que alguien abandona cuando consigue trabajo en otra parte. Eso es lo que aprendí con el ataque a Bitwarden CLI: la superficie de confianza de una herramienta no es solo su código, es su cadena de mantenimiento. Asahi mejoró esa cadena de manera estructural.

Cuando migramos notas de Notion a Markdown y encontramos que la portabilidad tiene un costo oculto, el problema no era el formato sino el lock-in de la plataforma. Apple Silicon con macOS era ese mismo problema en el lado del hardware. Comprás el mejor chip del mercado y te quedás atado al OS del fabricante. Asahi Linux 7.0 empieza a romper ese lock-in de manera legítima.

¿Es para producción hoy? Para un servidor, no — no tiene sentido. Para una workstation de desarrollo donde ya sabés los gotchas y podés tolerar el Bluetooth meh y el suspend que a veces falla, sí, hoy mismo.

FAQ: Asahi Linux 7.0 en Apple Silicon

¿Asahi Linux 7.0 es estable para uso diario?
Depende de qué entendés por "uso diario". Para desarrollo de software — compilar, correr Docker, escribir código — es estable. Para video conferencias con Bluetooth o suspender el laptop diez veces por día, todavía tiene fricción real. Mi evaluación honesta: si el trabajo consiste principalmente en terminal y browser, sí. Si necesitás todo el stack multimedia sin configuración, todavía no.

¿Funciona Docker en Apple Silicon con Asahi Linux?
Sí. Docker corre nativamente en aarch64 sin capa de emulación. Las imágenes que tienen manifiestos linux/arm64 funcionan sin problemas. Las que solo tienen linux/amd64 van a fallar o van a necesitar emulación con --platform. Revisá los manifiestos de las imágenes que usás antes de migrar el flujo completo.

¿Qué chip de Apple funciona mejor con Asahi Linux 7.0?
M1 y M2 tienen el soporte más maduro porque llevan más tiempo bajo el microscopio de la comunidad. M3 y M4 tienen soporte creciente pero más incompleto, especialmente en drivers de GPU. Si estás eligiendo hardware nuevo pensando en Asahi, M2 Pro es el punto dulce en este momento.

¿El driver de GPU de Asahi (Honeykrisp) sirve para desarrollo?
Para desarrollo web, sí — la aceleración básica funciona, los terminales acelerados por GPU andan bien, la experiencia de escritorio es fluida. Para workloads de ML locales o rendering 3D, el estado actual no es suficiente. Vulkan funciona pero no a la velocidad del metal nativo de Apple.

¿Puedo usar Asahi Linux como reemplazo completo de macOS?
Hoy: parcialmente. El 80% de un flujo de desarrollo moderno funciona sin fricciones. El 20% restante — Bluetooth maduro, soporte de suspend/resume, algunas herramientas que asumen macOS — todavía necesita workarounds o sacrificios. En 12 meses, esa proporción va a cambiar. El ritmo de upstream contributions aceleró notablemente con la serie 6.12+.

¿Vale la pena instalarlo si ya tengo un flujo macOS que funciona?
Si el flujo funciona, no lo rompas por curiosidad. Instalalo en dual boot si querés explorar sin riesgo. Lo que sí tiene sentido hacer hoy: evaluar si tu stack de desarrollo corre limpio en arm64 Linux, porque ese conocimiento va a ser relevante cuando más infraestructura migre a ARM. Yo lo hice por eso — no para escapar de macOS, sino para entender el terreno antes de que sea obligatorio entenderlo. Lo mismo que hago cuando mido GPT-5.5 en la API o evalúo si el deterioro de Claude justifica cancelar: no espero que el ecosistema me avise. Mido yo.

Conclusión: el lock-in de hardware es el problema que nadie nombra

Pasé años preocupándome por el lock-in de plataformas de software — SaaS, herramientas, lenguajes. Lo que no estaba midiendo era el lock-in de hardware. Apple Silicon es el mejor chip del mercado de laptops hoy por hoy. El problema era que comprarlo significaba comprometerse con macOS sin salida real.

Asahi Linux 7.0 no resuelve eso completamente. Pero pone la primera piedra de una salida. El soporte upstream del kernel cambia la ecuación de mantenimiento a largo plazo — y eso, para mí, pesa más que el driver de GPU. Porque los drivers mejoran con el tiempo. Lo que no mejora solo es la estructura de incentivos. Y esa estructura hoy favorece a los que quieren Linux en Apple Silicon.

Lo que no compro: el hype de que "ya está listo para todos". No está. Todavía necesitás tolerancia a la incomodidad y ganas de debuggear cosas raras un sábado a la madrugada. Pero esa tolerancia siempre fue el precio de entrada al mundo Linux. Lo nuevo es que ahora hay algo del otro lado que lo justifica.

Si querés arrancar: asahilinux.org, leé la documentación completa antes de tocar el disco, y hacé backup. El resto es el mismo caos honesto de siempre.

Este artículo fue publicado originalmente en juanchi.dev

An Agent Deleted My Production Database: What My Logs Say That the Viral HN Post Leaves Out

Juan Torchia — Mon, 27 Apr 2026 12:31:57 +0000

An Agent Deleted My Production Database: What My Logs Say That the Viral HN Post Leaves Out

The right solution to stop an agent from destroying production is giving it less autonomy, not more guardrails. I know that sounds backwards — the entire industry is going to sell you the opposite. Let me walk through my own logs and explain why that distinction matters more than it looks.

The Hacker News post blew up this week. Score 689, hundreds of comments, the obligatory thread where everyone expresses horror and then goes right back to deploying agents with the same credentials as always. I read it twice. It's a solid account of the accident. It's a terrible root cause analysis.

Because the problem it describes isn't new to me. I have logs. I opened them.

A few weeks back I wrote about CrabTrap, the LLM-as-a-judge proxy I put in front of my production agent. Also about async agents and what debugging doesn't tell you. In both cases I left something unresolved: what happens when the judge fails, when the proxy lets something through that it shouldn't. Today I want to pull on that thread.

What HN Says and What It Leaves Out

The viral post has a classic structure: agent with broad permissions, ambiguous task, poorly bounded context, irreversible action. The author concludes they needed "better guardrails." The comments agree. Everyone closes the thread with a list of tools.

My thesis is the opposite: the problem isn't that the guardrails failed. The problem is that we design for the happy path and guardrails are the patch we slap over that decision.

A guardrail is a reactive mechanism. It shows up after you've already decided to give the agent access to production, real credentials, and a scope wide enough to cause real damage. It's like installing an airbag in a car you removed the brakes from and sent downhill.

What my logs show is more uncomfortable than that.

What Almost Happened: Three Destructive Operations From My Own Logs

I opened CrabTrap's logs from the last 30 days. Filtered for operations with destructive verbs: DELETE, DROP, TRUNCATE, rm -rf, reset variants. Found 23 calls that hit the proxy with some destructive intent. Of those 23:

17 were blocked by the LLM judge before executing.
4 passed the judge but failed due to permission restrictions in Railway (the DB user didn't have DDL access).
2 made it all the way through and executed something they shouldn't have.

Those two cases are the ones that matter. Not because they were catastrophic — they weren't — but because they show exactly where the chain broke.

Case 1: DELETE with no WHERE clause

-- What the agent wanted to execute
-- Context: "clean up the test records from the staging environment"
DELETE FROM sessions;

-- What it should have executed
DELETE FROM sessions WHERE environment = 'staging' AND created_at < NOW() - INTERVAL '7 days';

The proxy let DELETE FROM sessions through because the judge evaluated the intent as valid (clean up staging sessions) without validating that the query had no WHERE clause. The agent was right about what it wanted to do. The implementation was a disaster.

The result? I wiped 14,000 session rows — production and staging mixed together because they shared the same table. Not critical — sessions are regenerable — but if that table had been orders or payments, this would be a very different conversation.

Case 2: The Silent Cascade

-- What the agent executed in response to "delete test user id=9981"
DELETE FROM users WHERE id = 9981;

-- What it didn't know (and I'd never documented well):
-- users has ON DELETE CASCADE on:
--   → orders (→ order_items → inventory_movements)
--   → documents
--   → audit_logs
-- Total: 847 rows across 5 tables

The proxy had no way to know that CASCADE existed. I hadn't documented it in the context I was passing to the agent. The judge approved the operation because it was semantically correct. The schema did the rest.

This is what the HN post doesn't say: guardrails operate on intent, not on the side effects of your schema. And schema side effects are invisible to any LLM that doesn't have the full ERD in context — which, at any real scale, is impossible.

Why Framework Guardrails Are Theater

I reviewed the guardrails offered by the three most-used agent frameworks today. Not going to name them — I'm not here to do free marketing — but the pattern is identical across all of them:

# Typical "guardrail" pattern in agent frameworks
# (representative pseudocode, not from any specific framework)

BLOCKED_OPERATIONS = ["DROP TABLE", "TRUNCATE", "DELETE FROM users"]

def validate_query(query: str) -> bool:
    # String matching. That's it. That's the whole thing.
    for blocked in BLOCKED_OPERATIONS:
        if blocked.upper() in query.upper():
            return False
    return True

# The problem: all of these pass cleanly
validate_query("delete from users where id=1")  # → True
validate_query("DROP   TABLE sessions")          # → True (extra spaces)
validate_query("EXEC sp_executesql @q")          # → True (dynamic SQL)

String matching on SQL queries. In 2025. With agents generating dynamic SQL from natural language context.

When I built CrabTrap, I replaced that pattern with semantic evaluation — the proxy sends the query plus context to the model and asks whether the operation is destructive in that specific context. It's better. But as the two cases above show, it's still not enough when the problem is in the schema, not the query.

The solution I landed on — and the one the HN post never mentions — is more boring: database users with minimal permissions, separated by environment, no DDL access, and row-level security where it applies. Not sexy. Not a framework. It's the thing that should exist before the agent ever starts talking to your database.

This connects to something I've been dragging around since the Bitwarden CLI supply chain attack analysis: the trust surface gets designed before the incident, not after. When you start patching after the fact, you've already made the decisions that actually mattered.

The Design Mistakes the HN Incident Normalizes Without Meaning To

The viral post, well-intentioned as it is, lets three assumptions slide by without questioning them:

1. That the agent needed direct database access.

In most cases, it doesn't. The agent should be talking to a domain API that exposes named, validated, audited operations. deleteTestUser(id) instead of DELETE FROM users WHERE id=?. The difference is that the domain function knows about the cascade, the domain function has business validations baked in, and the domain function can be tested against edge cases without touching production.

2. That staging and production are different enough.

They're not if they share a schema, if the agent uses the same credentials for both, or if "staging" is just a flag in an environment variable the agent can ignore or misread. I learned that the hard way with the DELETE without a WHERE clause. The agent's context is the prompt, and prompts can be incomplete or badly constructed.

3. That this problem is new.

It isn't. Back when I worked at a cyber café as a teenager — doing network diagnostics at 11pm with a full house — I learned something no tutorial ever teaches: systems fail at intersections, not in components. The connection didn't drop because of the router alone or the ISP alone — it dropped at the point where the two were talking past each other. Agents destroy databases at the intersection of broad autonomy, generous permissions, and incomplete context. Not from any one of those three factors alone.

FAQ: AI Agents and Production Databases

What minimal permissions should an agent have when accessing a database?

Depends on the use case, but as a general rule: SELECT on tables it needs to read, INSERT and UPDATE on tables it needs to modify, and zero DDL access (DROP, ALTER, TRUNCATE). If the agent needs to delete data, better to expose a domain function with soft delete than direct DELETE access. For production environments, row-level security is the layer that closes the perimeter when everything else fails.

Are LangChain, CrewAI, or similar guardrails enough to prevent destructive operations?

In my experience, no. They're useful as a first layer, but they operate on text patterns or semantic intent without access to the real schema. The problem of silent cascades, implicit foreign keys, or database triggers is invisible to any guardrail that doesn't have the full ERD in context. Necessary but not sufficient.

What's better: an LLM-as-a-judge proxy or restrictive DB permissions?

Both layers, in that order of priority. Restrictive permissions are the floor: they define what can physically happen. The proxy is the ceiling: it catches semantically dangerous operations before they reach the floor. If you have to pick one, pick permissions. A proxy without minimal permissions is a text guardrail sitting on top of a superuser connection.

How do I separate staging from production so an agent can't confuse the two?

Different database users, different credentials, and — if you can swing it — different databases on different hosts. A ENV=staging flag in your config isn't enough. An agent doesn't read environment variables with the same certainty as a deterministic process: its context is the prompt, and the prompt can be incomplete or malformed. Physical separation is the only kind that can't be misinterpreted.

Is it worth adding human confirmation before destructive operations?

Yes, but with judgment. Human-in-the-loop on every operation kills the agent's usefulness. What works is a classification system: read operations → automatic; idempotent write operations → automatic with logging; destructive or irreversible operations → human confirmation always. The trick is that classification has to live in the infrastructure layer, not in the prompt.

Is the HN agent-deletes-DB incident representative of what happens in production?

More than the industry admits. The difference between that case and mine was the permission level on the database user. In the HN case, it had full access. In mine, DDL access was blocked by Railway, which turned a potential disaster into a loggable permission error. That difference didn't come from an agent framework — it came from an infrastructure decision made before the agent existed.

What I Accept, What I Don't Buy, and the Honest Trade-off

What I accept: agents are going to keep breaking things. Not out of malice, but because they operate on incomplete context inside systems designed for humans who understand the implicit schema. That's not going to change with better prompts or better guardrails.

What I don't buy: that the solution is more abstraction piled on top of the same permissions problem. Every new framework that promises "safe agents by default" and then exposes a superuser connection in the documentation examples is lying to me. I saw the same pattern with TypeScript 7.0 and its new typing features — new abstractions don't solve old design problems, they hide them until they explode.

The honest trade-off: real autonomy has an infrastructure cost that most people don't want to pay. Physically separating environments, creating DB users with minimal permissions, exposing domain APIs instead of direct table access, implementing soft deletes, auditing cascades — all of that takes time. It's easier to give the agent full access and trust that the LLM will do the right thing.

The HN post with 689 points exists because that shortcut eventually comes due.

My two near-disaster cases exist because I took shortcuts too — the DELETE without a WHERE clause was my fault in the shared schema design, the silent CASCADE was documentation I never wrote. The guardrails saved me twice. The third time might not go as well.

The difference between designing for the happy path and designing for the failure path isn't a difference in tools. It's a difference in attitude toward the system. And that attitude gets learned, almost always, after something breaks.

Keep the conversation going in the comments: what near-destructive operations have you found in your own logs?

This article was originally published on juanchi.dev

Un agente borró mi base de datos en producción: lo que mis logs dicen que el post viral de HN omite

Juan Torchia — Mon, 27 Apr 2026 12:31:52 +0000

Un agente borró mi base de datos en producción: lo que mis logs dicen que el post viral de HN omite

La solución correcta para evitar que un agente destruya producción es darle menos autonomía, no más guardrails. Sé que suena raro — la industria entera te va a vender lo contrario. Dejame explicar con mis propios logs por qué esa distinción importa más de lo que parece.

El post de Hacker News explotó esta semana. Score 689, cientos de comentarios, el hilo de turno donde todos se horrorizan y después siguen desplegando agentes con las mismas credenciales de siempre. Lo leí dos veces. Es un buen relato del accidente. Es un pésimo análisis de la causa raíz.

Porque el problema que describe no es nuevo para mí. Tengo logs. Los abrí.

Hace unas semanas escribí sobre CrabTrap, el proxy LLM-as-a-judge que puse delante de mi agente en producción. También sobre los agentes async y lo que el debugging no te dice. En ambos casos dejé algo sin resolver: qué pasa cuando el juez falla, cuando el proxy deja pasar algo que no debería. Hoy quiero agarrar esa hebra.

AI agent deleted production database: qué dice HN y qué omite

El relato viral tiene una estructura clásica: agente con permisos amplios, tarea ambigua, contexto mal delimitado, acción irreversible. El autor concluye que necesitaba "mejores guardrails". Los comentarios coinciden. Se cierran con una lista de herramientas.

Mi tesis es la opuesta: el problema no es que los guardrails fallaron. El problema es que diseñamos para el happy path y los guardrails son el parche sobre esa decisión.

Un guardrail es un mecanismo reactivo. Llega después de que ya decidiste darle al agente acceso a producción, credenciales reales, y un scope lo suficientemente amplio como para que pueda hacer daño. Es como poner un airbag en un auto al que le sacaste los frenos y lo mandaste cuesta abajo.

Lo que mis logs muestran es más incómodo que eso.

Lo que casi pasó: tres operaciones destructivas en mis propios logs

Abrí los logs de CrabTrap de los últimos 30 días. Filtré por operaciones con verbos destructivos: DELETE, DROP, TRUNCATE, rm -rf, variantes de reset. Encontré 23 llamadas que llegaron al proxy con alguna de esas intenciones. De esas 23:

17 fueron bloqueadas por el juez LLM antes de ejecutarse.
4 pasaron el juez pero fallaron por restricciones de permisos en Railway (el usuario de DB no tenía acceso a DDL).
2 pasaron todo y ejecutaron algo que no debería haber ejecutado.

Esos dos casos son los que importan. No porque hayan sido catastróficos — no lo fueron — sino porque muestran exactamente dónde rompió la cadena.

Caso 1: DELETE sin WHERE

-- Lo que el agente quería ejecutar
-- Contexto: "limpiá los registros de test del entorno de staging"
DELETE FROM sessions;

-- Lo que debería haber ejecutado
DELETE FROM sessions WHERE environment = 'staging' AND created_at < NOW() - INTERVAL '7 days';

El proxy dejó pasar el DELETE FROM sessions porque el juez evaluó la intención como válida (limpiar sesiones de staging) sin validar que la query no tenía cláusula WHERE. El agente tenía razón en lo que quería hacer. La implementación era un desastre.

¿El resultado? Borré 14.000 filas de sesiones de producción mezcladas con las de staging porque compartían la misma tabla. No era crítico — las sesiones son regenerables — pero si esa tabla hubiera sido orders o payments, la conversación sería diferente.

Caso 2: Cascade silencioso

-- El agente ejecutó esto en respuesta a "eliminá el usuario de test id=9981"
DELETE FROM users WHERE id = 9981;

-- Lo que no sabía (y yo tampoco había documentado bien):
-- users tiene ON DELETE CASCADE sobre:
--   → orders (→ order_items → inventory_movements)
--   → documents
--   → audit_logs
-- En total: 847 filas en 5 tablas

El proxy no tenía forma de saber que ese CASCADE existía. Yo tampoco lo había documentado en el contexto que le pasé al agente. El juez aprobó la operación porque era semánticamente correcta. El schema hizo el resto.

Esto es lo que el post de HN no dice: los guardrails operan sobre la intención, no sobre los efectos secundarios del schema. Y los efectos secundarios del schema son invisibles para cualquier LLM que no tenga el ERD completo en contexto — lo cual, a escala, es imposible.

Por qué los guardrails de los frameworks son teatro

Revisé los guardrails que ofrecen los tres frameworks de agentes más usados hoy. No voy a nombrarlos para no hacer publicidad gratuita, pero el patrón es el mismo en todos:

# Patrón típico de "guardrail" en frameworks de agentes
# (pseudocódigo representativo, no de un framework específico)

BLOCKED_OPERATIONS = ["DROP TABLE", "TRUNCATE", "DELETE FROM users"]

def validate_query(query: str) -> bool:
    # Chequeo de string matching. Eso es todo.
    for blocked in BLOCKED_OPERATIONS:
        if blocked.upper() in query.upper():
            return False
    return True

# El problema: esto pasa sin problemas
validate_query("delete from users where id=1")  # → True
validate_query("DROP   TABLE sessions")          # → True (espacios extra)
validate_query("EXEC sp_executesql @q")          # → True (SQL dinámico)

String matching sobre queries SQL. En 2025. Con agentes que generan SQL dinámico basado en contexto natural.

Cuando armé CrabTrap, reemplacé ese patrón por evaluación semántica — el proxy manda la query + el contexto al modelo y pregunta si la operación es destructiva en ese contexto específico. Es mejor. Pero como muestran los dos casos de arriba, tampoco es suficiente cuando el problema está en el schema, no en la query.

La solución que encontré — y que el post de HN no menciona — es más aburrida: usuarios de base de datos con permisos mínimos, separados por entorno, sin acceso a DDL, y con restricciones de row-level security cuando aplica. No es sexy. No es un framework. Es lo que debería existir antes de que el agente empiece a hablar con la base de datos.

Esto conecta con algo que vengo arrastrando desde el análisis del supply chain attack sobre Bitwarden CLI: la superficie de confianza se diseña antes del incidente, no después. Cuando empezás a remendar después, ya tomaste las decisiones que importaban.

Los errores de diseño que el incidente de HN normaliza sin querer

El relato viral, aunque bien intencionado, deja pasar tres supuestos sin cuestionarlos:

1. Que el agente necesitaba acceso directo a la base de datos.

En la mayoría de los casos, no lo necesita. El agente debería hablar con una API de dominio que exponga operaciones nombradas, validadas y auditadas. eliminarUsuarioDePrueba(id) en vez de DELETE FROM users WHERE id=?. La diferencia es que la función de dominio conoce el cascade, la función de dominio tiene validaciones de negocio, y la función de dominio puede ser testeada con casos límite sin tocar producción.

2. Que los entornos de staging y producción son lo suficientemente distintos.

No lo son si comparten schema, si el agente usa las mismas credenciales, o si "staging" es simplemente un flag en una variable de entorno que el agente puede ignorar o malinterpretar. Yo lo aprendí a las malas con el caso del DELETE sin WHERE.

3. Que el problema es nuevo.

No lo es. En el cyber café donde laburé de adolescente, el diagnóstico de red a las 11pm con el local lleno me enseñó algo que ningún tutorial explica: los sistemas fallan en las intersecciones, no en los componentes. La conexión no se caía por el router solo ni por el ISP solo — se caía en el punto donde los dos se hablaban mal. Los agentes destruyen DBs en la intersección entre autonomía amplia, permisos generosos y contexto incompleto. No en ninguno de esos tres factores solos.

FAQ: AI agents y bases de datos en producción

¿Qué permisos mínimos debería tener un agente que accede a una base de datos?

Depende del caso de uso, pero como regla general: SELECT sobre las tablas que necesita leer, INSERT y UPDATE sobre las tablas que necesita modificar, y cero acceso a DDL (DROP, ALTER, TRUNCATE). Si el agente necesita borrar datos, mejor exponerle una función de dominio con soft delete que acceso directo a DELETE. Para entornos productivos, row-level security es la capa que cierra el perímetro cuando el resto falla.

¿Los guardrails de LangChain, CrewAI o similares son suficientes para prevenir operaciones destructivas?

En mi experiencia, no. Son útiles como primera capa, pero operan sobre patrones de texto o sobre intención semántica sin acceso al schema real. El problema de los cascades silenciosos, las foreign keys implícitas o los triggers de base de datos es invisible para cualquier guardrail que no tenga el ERD completo en contexto. Son necesarios pero no suficientes.

¿Qué es mejor: un proxy LLM-as-a-judge o permisos restrictivos en la DB?

Las dos capas, en ese orden de prioridad. Los permisos restrictivos son el piso: definen qué puede pasar físicamente. El proxy es el techo: detecta operaciones semánticamente peligrosas antes de que lleguen al piso. Si tenés que elegir uno, elegí los permisos. El proxy sin permisos mínimos es un guardrail de texto sobre una conexión con permisos de superusuario.

¿Cómo separo staging de producción para que un agente no pueda confundir los dos?

Usuarios de base de datos distintos, credenciales distintas, y — si podés — bases de datos distintas en hosts distintos. No alcanza con un flag ENV=staging en la configuración. El agente no lee variables de entorno con el mismo nivel de certeza que un proceso determinístico: su contexto es el prompt, y el prompt puede estar incompleto o mal construido. La separación física es la única que no puede ser malinterpretada.

¿Vale la pena agregar confirmación humana antes de operaciones destructivas?

Sí, pero con criterio. Human-in-the-loop en cada operación destruye la utilidad del agente. Lo que funciona es un sistema de clasificación: operaciones de lectura → automático; operaciones de escritura idempotentes → automático con log; operaciones destructivas o irreversibles → confirmación humana siempre. El truco es que esa clasificación tiene que estar en la capa de infraestructura, no en el prompt.

¿El problema del agente que borró la DB en HN es representativo de lo que pasa en producción?

Más de lo que la industria admite. La diferencia entre ese caso y los míos fue el nivel de permisos que tenía el usuario de base de datos. En el caso de HN, tenía acceso total. En el mío, el acceso DDL estaba bloqueado por Railway, lo que convirtió un potencial desastre en un error de permisos logueable. Esa diferencia no vino de un framework de agentes — vino de una decisión de infraestructura tomada antes de que el agente existiera.

Lo que acepto, lo que no compro y el trade-off honesto

Lo que acepto: los agentes van a seguir rompiendo cosas. No por malicia, sino porque operan sobre contexto incompleto en sistemas diseñados para humanos que entienden el schema implícito. Eso no va a cambiar con mejores prompts ni con mejores guardrails.

Lo que no compro: que la solución es más abstracción encima del mismo problema de permisos. Cada framework nuevo que promete "agentes seguros por defecto" y después expone una conexión con credenciales de superusuario en los ejemplos de la documentación me está mintiendo. Lo vi con TypeScript 7.0 y sus nuevas features de tipado — las abstracciones nuevas no resuelven los problemas de diseño viejos, los ocultan hasta que explotan.

El trade-off honesto: autonomía real tiene un costo de infraestructura que la mayoría no quiere pagar. Separar entornos físicamente, crear usuarios de DB con permisos mínimos, exponer APIs de dominio en vez de acceso directo a tablas, implementar soft deletes, auditar cascades — todo eso toma tiempo. Es más fácil dejar al agente con acceso completo y confiar en que el LLM va a hacer lo correcto.

El post de HN con 689 puntos existe porque ese atajo eventualmente cobra.

Mis dos casos casi-desastre existen porque yo también tomé atajos — el DELETE sin WHERE fue descuido mío en el diseño del schema compartido, el CASCADE silencioso fue documentación que nunca escribí. Los guardrails me salvaron dos veces. La tercera podría no hacerlo.

La diferencia entre diseñar para el happy path y diseñar para el failure path no es una diferencia de herramientas. Es una diferencia de actitud frente al sistema. Y esa actitud se aprende, casi siempre, después de que algo se rompe.

Seguí la conversación en los comentarios: ¿qué operaciones casi-destructivas encontraste en tus propios logs?

Este artículo fue publicado originalmente en juanchi.dev