Si tienes un Worker en un VPS consultando una cola continuamente, quizá te hayas preguntado por qué sigues administrando un servidor entero. Al fin y al cabo, los trabajos vienen de una cola externa y sus resultados acaban en una base de datos. Los nuevos Daemons de Vercel prometen ejecutar un contenedor de forma persistente con un número fijo de instancias.

Pero eso no convierte a Daemons en un sustituto directo de un VPS. Tras revisar el anuncio de Vercel, los límites oficiales y la gestión de instancias, la distinción es clara: un consumidor que extrae trabajos, guarda su estado fuera del contenedor y tolera los reintentos es candidato. Un proceso que requiere puertos entrantes, archivos locales persistentes o un entorno completo de CI no se puede trasladar sin más.

El 15 de octubre de 2026, Vercel anunció Python para backends en GA, Container Functions y Daemons Public Beta. El análisis de la plataforma se basa en su documentación y JSON Schema; por separado, ejecuté un experimento local con Node.js y señales reales `SIGTERM` para mostrar qué sucede cuando un trabajo se confirma antes o después de producir sus efectos. No es una prueba de un Daemon ejecutándose en Vercel.

Responder peticiones HTTP no equivale a consumir una cola

Para una API HTTP hecha con FastAPI, Flask o Django, Python Functions (GA) usa el modelo de ejecución por petición. Si necesitas una imagen OCI propia o bibliotecas del sistema, Container Functions (Beta) puede servir un endpoint HTTP y escalar con las solicitudes. Daemons, en cambio, mantiene una cantidad fija de procesos de larga duración que extraen trabajos de colas o bases de datos. Según la documentación oficial, actualmente no admite conexiones HTTP/TCP entrantes.

Trabajo existenteModelo candidatoPregunta antes de migrar
API pública FastAPI / FlaskPython Functions (GA)Duración de petición, dependencias, conexiones
Servicio OCI que recibe HTTPContainer Functions (Beta)Escalado por solicitudes y precio de Functions
Consumidor de cola con base de datos externaDaemons (Public Beta)Instancias fijas, estado externo, reintentos e idempotencia
Servicio que depende de archivos o caché locales persistentesVPS u otro host con volumen persistenteDaemons no tiene almacenamiento local persistente
Servicio con puerto TCP de entradaVPS u hosting TCP compatibleDaemons no expone puertos entrantes

También sería precipitado migrar directamente un GitHub Self-hosted Runner. Aunque el Runner obtiene tareas por iniciativa propia, estas pueden requerir construir contenedores, un directorio de trabajo, caché y permisos sensibles de despliegue. Compartir el patrón pull no garantiza compatibilidad de sistema de archivos, aislamiento o privilegios. Hay que examinar cada workflow real.

Diez vCPU-hours al mes no equivalen a un Worker gratuito permanente

Los límites Beta asignan a Hobby 10 vCPU-hours por equipo y mes. Una instancia de 1 vCPU funcionando continuamente consume la cuota en unas diez horas. Una vez alcanzado el límite, los Daemons del equipo se detienen hasta el mes siguiente o hasta cambiar de plan.

La unidad representa número de vCPU asignadas × horas en funcionamiento, no el porcentaje efectivo de uso. Un Worker que pasa casi todo el tiempo esperando mensajes tampoco es un servicio gratuito 24/7. Tampoco se debe trasladar sin comprobarlo el concepto de facturación Active CPU de Container Functions a los Daemons.

En Pro, el límite concurrente por defecto es 16 vCPU y 32 GiB de RAM: no es una tarifa mensual en dólares. Para comparar costes con un VPS hacen falta los recursos reservados, la duración de ejecución, los costes de red y cola y el trabajo de mantenimiento.

La Beta tampoco incluye Preview Deployments, escalado automático ni disco local persistente; `vercel dev` no inicia directamente los Daemons. Estos arrancan con el despliegue de producción y durante el desarrollo local debes ejecutar el contenedor tú mismo. Si dependes de entornos Preview o cachés en disco, esa diferencia puede resultar más problemática que el código. Hay otras restricciones sobre directorios raíz anidados en los límites.

El problema tras SIGTERM: cuándo se confirma el trabajo

La guía de gestión indica que, al desplegar una versión nueva, pueden coincidir brevemente los Daemons antiguos y nuevos. El proceso anterior recibe `SIGTERM` y dispone por defecto de diez segundos para finalizar. El asunto importante es qué ocurre con el trabajo a medio hacer.

Supongamos que el Worker confirma un cambio en la base de datos y termina antes de enviar Ack a la cola. Si el mensaje vuelve a entregarse, podrías repetir el efecto. Invierte el orden —Ack primero, efecto después— y un cierre prematuro puede dejar un mensaje marcado como procesado aunque la operación nunca se realizara.

Para ilustrarlo ejecuté una pequeña cola sintética en Node.js v22.16.0 y Linux x64. Un archivo JSON guarda una tarea ficticia y sus efectos simulados; varios procesos hijos de Node ejecutan el trabajo y reciben realmente `SIGTERM` en tres escenarios de interrupción. No mide la fiabilidad ni la latencia de Vercel: contrasta el orden de los efectos y el Ack.

Escenario local sintéticoIntentosEfectos registradosAck final
Ejecutar efecto y luego confirmar11Sí
Interrupción tras el efecto y reintento con deduplicación por ID21Sí
Interrupción tras el efecto y reintento sin deduplicación22Sí
Confirmar antes de ejecutar y sufrir una interrupción10Sí

Los cuatro casos produjeron el resultado esperado. Los dos controles negativos enseñan el riesgo: sin deduplicación se repite el efecto, y confirmar demasiado pronto puede perder el trabajo.

La comprobación principal ocupa unas pocas líneas; `effects` son registros de nuestro modelo sintético:

function recordEffect(s, dedupe) {
  const existing = s.effects.some((effect) => effect.jobId === s.job.id);
  if (dedupe && existing) return 'effect_deduplicated';
  s.effects.push({ jobId: s.job.id, effect: 'synthetic-committed-action' });
  return 'effect_applied';
}

Con deduplicación por `jobId`, el segundo intento detecta un efecto existente y no lo añade de nuevo. Sin esa condición lo duplica. En el caso de Ack anticipado, el Worker recuperado encuentra `acked: true` y omite la tarea aunque el efecto todavía no exista.

Las colas reales añaden timeouts de visibilidad, transacciones y reglas de reentrega que este archivo JSON no reproduce. Antes de migrar hay que introducir claves de negocio únicas o escrituras idempotentes, y verificar los reintentos con la cola que se vaya a utilizar.

La configuración es corta; entender sus garantías no tanto

La referencia de configuración describe un Worker de una sola región como este. Dentro de `worker/` necesitarás además el Dockerfile y el consumidor real de la cola:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 1 },
      "resources": { "requests": { "memory": "2Gi" } }
    }
  }
}

`instances` fija la cantidad por región; `iad1` es el identificador de la región de Washington. No activa el escalado automático.

El JSON Schema del proyecto todavía acepta la propiedad antigua `replicas`, pero está marcada como deprecated. Si se especifican ambas, prevalece `instances`. La guía de gestión y la referencia de configuración actuales ya usan `instances`, que es la opción adecuada para proyectos nuevos.

El plazo de `SIGTERM` documentado es de diez segundos por defecto, y el Schema incluye `terminationGracePeriodSeconds`. Ampliar ese plazo no arregla la duplicación de efectos ni un orden incorrecto de confirmación. Primero hay que diseñar trabajos reintentables y seguros ante una interrupción; después comprobar la configuración en un despliegue real.

Para Workers ligeros que consumen una cola externa, guardan su estado fuera del contenedor y toleran un número fijo de instancias, probaría Daemons primero con tareas no críticas. Mantendría el VPS si necesito directorios persistentes, privilegios complejos para CI, puertos entrantes o un entorno Preview estable. Cambiar el alojamiento de un Runner tampoco elimina el riesgo de ejecutar código no fiable junto a secretos de despliegue.

Puedes ampliar ese contexto con la cadena de publicación ChatGPT Web + GitHub + Self-hosted Runner o la prueba de PanelAlpha Engine en un VPS.

Para repetir los cuatro escenarios locales, guarda el siguiente código como `queue-interruption-l1.mjs` y ejecútalo con Node.js 20 o posterior mediante `node queue-interruption-l1.mjs`. Imprimirá un JSON con los resultados.

Ver el código completo de la prueba sintética con Node.js
/**
 * First-party, offline, synthetic queue acknowledgement experiment.
 * Not a Vercel deployment, Vercel Daemon integration, or platform reliability test.
 * Dependencies: Node.js >= 20 standard library, no network, no cloud credentials.
 * Run: node queue-interruption-l1.mjs
 */
import assert from 'node:assert/strict';
import { fork } from 'node:child_process';
import { createHash } from 'node:crypto';
import { existsSync, mkdtempSync, readFileSync, rmSync, renameSync, writeFileSync } from 'node:fs';
import { tmpdir } from 'node:os';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const SCRIPT = fileURLToPath(import.meta.url);
const JOB = 'synthetic-job-001';
const sha256 = (bytes) => createHash('sha256').update(bytes).digest('hex');
const readState = (file) => JSON.parse(readFileSync(file, 'utf8'));
function writeState(file, state) {
  const temp = `${file}.next`;
  writeFileSync(temp, JSON.stringify(state) + '\n', { mode: 0o600 });
  renameSync(temp, file);
}
function newState(file) {
  writeState(file, { job: { id: JOB, acked: false }, effects: [], attempt: 0 });
}
function recordEffect(s, dedupe) {
  const existing = s.effects.some((effect) => effect.jobId === s.job.id);
  if (dedupe && existing) return 'effect_deduplicated';
  s.effects.push({ jobId: s.job.id, effect: 'synthetic-committed-action' });
  return 'effect_applied';
}

// The worker is our own short-lived child process, not a provider/runtime process.
function worker(mode, stateFile) {
  const state = readState(stateFile);
  if (state.job.acked) {
    process.send({ phase: 'already_acknowledged' }, () => process.exit(0));
    return;
  }
  state.attempt += 1;
  if (mode === 'ack-before-effect') {
    state.job.acked = true;
    writeState(stateFile, state);
    process.send({ phase: 'ack_committed_effect_missing' });
    process.on('message', () => {}); // Keep child alive until real SIGTERM.
    return;
  }
  if (mode === 'effect-before-ack') {
    recordEffect(state, false);
    writeState(stateFile, state);
    process.send({ phase: 'effect_committed_ack_missing' });
    process.on('message', () => {}); // Keep child alive until real SIGTERM.
    return;
  }
  if (mode === 'complete' || mode === 'complete-without-dedupe') {
    const action = recordEffect(state, mode === 'complete');
    state.job.acked = true;
    writeState(stateFile, state);
    process.send({ phase: action }, () => process.exit(0));
    return;
  }
  throw Error(`Unknown first-party worker mode: ${mode}`);
}

async function runChild(mode, stateFile, expectedPhase, interrupt) {
  return await new Promise((resolve, reject) => {
    const child = fork(SCRIPT, ['--worker', mode, stateFile], {
      env: { PATH: process.env.PATH ?? '', NODE_ENV: 'test' },
      stdio: ['ignore', 'ignore', 'pipe', 'ipc']
    });
    let seen = null;
    let settled = false;
    let stderr = '';
    child.stderr.setEncoding('utf8');
    child.stderr.on('data', (chunk) => { stderr = (stderr + chunk).slice(-1200); });
    const timer = setTimeout(() => {
      child.kill('SIGKILL');
      if (!settled) { settled = true; reject(Error(`Worker timeout: ${mode}`)); }
    }, 7000);
    child.on('error', (error) => {
      clearTimeout(timer);
      if (!settled) { settled = true; reject(error); }
    });
    child.on('message', (event) => {
      if (seen !== null) return;
      seen = event.phase;
      if (interrupt) child.kill('SIGTERM');
    });
    child.on('exit', (code, signal) => {
      clearTimeout(timer);
      if (settled) return;
      settled = true;
      if (seen !== expectedPhase || (interrupt ? signal !== 'SIGTERM' : code !== 0)) {
        reject(Error(`Worker mismatch mode=${mode} seen=${seen} code=${code} signal=${signal}; stderr=${stderr}`));
      } else {
        resolve({ phase: seen, exit_code: code, exit_signal: signal });
      }
    });
  });
}

async function experiment() {
  const started = new Date().toISOString();
  const dir = mkdtempSync(path.join(tmpdir(), 'offline-queue-l1-'));
  const cases = [];
  let cleanup = false;
  try {
    const stateFile = path.join(dir, 'state.json');
    newState(stateFile);
    const normal = await runChild('complete', stateFile, 'effect_applied', false);
    let s = readState(stateFile);
    assert.equal(s.effects.length, 1);
    assert.equal(s.job.acked, true);
    cases.push({ id: 'control_effect_then_ack', passed: true, effects: s.effects.length, acked: s.job.acked, attempts: s.attempt, worker: normal });

    newState(stateFile);
    const interruptedSafe = await runChild('effect-before-ack', stateFile, 'effect_committed_ack_missing', true);
    s = readState(stateFile);
    assert.equal(s.effects.length, 1);
    assert.equal(s.job.acked, false);
    const replaySafe = await runChild('complete', stateFile, 'effect_deduplicated', false);
    s = readState(stateFile);
    assert.equal(s.effects.length, 1);
    assert.equal(s.job.acked, true);
    assert.equal(s.attempt, 2);
    cases.push({ id: 'sigterm_replay_with_dedupe', passed: true, effects: s.effects.length, acked: s.job.acked, attempts: s.attempt, workers: [interruptedSafe, replaySafe] });

    newState(stateFile);
    const interruptedUnsafe = await runChild('effect-before-ack', stateFile, 'effect_committed_ack_missing', true);
    const replayUnsafe = await runChild('complete-without-dedupe', stateFile, 'effect_applied', false);
    s = readState(stateFile);
    assert.equal(s.effects.length, 2); // Deliberate negative control: duplicate side effect.
    assert.equal(s.job.acked, true);
    cases.push({ id: 'sigterm_replay_without_dedupe_negative_control', passed: true, effects: s.effects.length, acked: s.job.acked, attempts: s.attempt, observed_risk: 'duplicate_side_effect', workers: [interruptedUnsafe, replayUnsafe] });

    newState(stateFile);
    const earlyAck = await runChild('ack-before-effect', stateFile, 'ack_committed_effect_missing', true);
    const recovery = await runChild('complete', stateFile, 'already_acknowledged', false);
    s = readState(stateFile);
    assert.equal(s.effects.length, 0);
    assert.equal(s.job.acked, true);
    assert.equal(s.attempt, 1);
    cases.push({ id: 'ack_before_effect_negative_control', passed: true, effects: s.effects.length, acked: s.job.acked, attempts: s.attempt, observed_risk: 'lost_work', workers: [earlyAck, recovery] });
  } finally {
    rmSync(dir, { recursive: true, force: true });
    cleanup = !existsSync(dir);
  }
  assert.equal(cases.length, 4);
  assert.ok(cases.every((entry) => entry.passed));
  assert.equal(cleanup, true);
  const receipt = {
    schema_version: 1,
    type: 'FIRST_PARTY_OFFLINE_SYNTHETIC_QUEUE_EXPERIMENT',
    scope: 'LOCAL_NODE_CHILD_PROCESSES_ONLY_NOT_VERCEL',
    source_sha256: sha256(readFileSync(SCRIPT)),
    node: process.version,
    platform: process.platform,
    architecture: process.arch,
    started_at: started,
    ended_at: new Date().toISOString(),
    case_count: cases.length,
    passed: cases.length,
    failed: 0,
    clean_up_verified: cleanup,
    cases,
    limitations: [
      'No Vercel account, Daemon, Vercel Functions, managed queue, container or API was used.',
      'Synthetic queue state is an isolated JSON file and effects are fake records; no external side effects.',
      'Real local child processes received SIGTERM, but signal timing/rollout/delivery semantics of Vercel were not measured.',
      'No performance/cost/availability benchmark; 4 illustrative cases are not a statistical reliability study.'
    ]
  };
  console.log(JSON.stringify(receipt, null, 2));
}

if (process.argv[2] === '--worker') {
  worker(process.argv[3], process.argv[4]);
} else if (process.argv.length === 2) {
  experiment().catch((error) => {
    console.error(`SYNTHETIC_L1_FAIL: ${error.message}`);
    process.exitCode = 1;
  });
} else {
  throw Error('Usage: node queue-interruption-l1.mjs');
}