¿Pueden Vercel Daemons sustituir un Worker en VPS? Límites, SIGTERM y configuración
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 existente | Modelo candidato | Pregunta antes de migrar |
|---|---|---|
| API pública FastAPI / Flask | Python Functions (GA) | Duración de petición, dependencias, conexiones |
| Servicio OCI que recibe HTTP | Container Functions (Beta) | Escalado por solicitudes y precio de Functions |
| Consumidor de cola con base de datos externa | Daemons (Public Beta) | Instancias fijas, estado externo, reintentos e idempotencia |
| Servicio que depende de archivos o caché locales persistentes | VPS u otro host con volumen persistente | Daemons no tiene almacenamiento local persistente |
| Servicio con puerto TCP de entrada | VPS u hosting TCP compatible | Daemons 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ético | Intentos | Efectos registrados | Ack final |
|---|---|---|---|
| Ejecutar efecto y luego confirmar | 1 | 1 | Sí |
| Interrupción tras el efecto y reintento con deduplicación por ID | 2 | 1 | Sí |
| Interrupción tras el efecto y reintento sin deduplicación | 2 | 2 | Sí |
| Confirmar antes de ejecutar y sufrir una interrupción | 1 | 0 | Sí |
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');
}