A queue consumer, a scraper working through a list, a Telegram bot polling for updates, none of that is a request/response API, and none of it fits neatly into a function with a fifteen-second lifetime. DenkOps runs the worker as one always-on slot: it starts, keeps its own memory and connections, and runs until the job is actually done.
Write progress, a dead-letter log or partial output to /persist so a restart resumes instead of starting over. Only the queue, database or storage bucket the worker actually needs has to be added to the egress allowlist.
Yes. A DenkOps slot has no execution timeout, a queue consumer, a scraping loop or a batch job keeps running as long as the process is alive, whether that's ten minutes or ten hours. It ends when the job finishes or you redeploy, not when a platform's clock runs out.
Serverless queue consumers are usually billed and time-boxed per invocation, which forces jobs to be split into short chunks with state handed off between them. A background worker on DenkOps is one continuously running process with its own memory and a durable disk at /persist, so it can hold a connection pool, an in-memory cache or partial progress for the whole run.
← API hosting · FastAPI scraper guide · Bun+Hono Telegram bot guide