Workers

A worker is a long-running process that does work in the background: consuming a queue, running a websocket server, handling email delivery, polling an external API, or anything else that shouldn't be triggered by an incoming HTTP request. From the platform's perspective, workers share almost everything with web services (build pipeline, env vars, logs, metrics, deploys) except the public URL and the request-concurrency autoscaler.

Creating a worker

From your project dashboard, click New service, then Worker. Pick a repo, a branch, and a start command, then deploy. Workers don't need a PORT value or a public hostname: Appentic just runs your start command and keeps the process alive. If it crashes, Appentic restarts it and records the crash in the logs tab.

Differences from web services

Four things are different compared to a web service:

• No HTTP routing. Workers don't get a public URL, and the PORT environment variable is not injected.
• No request-based health check. Appentic monitors the process itself: if it exits, that's a crash, and the worker is restarted.
• No request-concurrency autoscaling. You pick how many instances to run. Appentic keeps that many alive.
• Same everything else. Logs, metrics, environment variables, deploys, rollbacks, and the interactive shell all work the same way as they do for web services.

Because the non-HTTP bits are identical, you can promote code between a worker and a web service (or split a monolith into both) without changing how you build, deploy, or debug it.

Good fits for workers

Workers earn their keep whenever you have work that needs to happen but shouldn't block an HTTP response:

• Queue consumers (BullMQ, Celery, Sidekiq, SQS clients) that pick jobs off a queue and process them.
• Long-lived websocket servers that hold open connections for realtime features.
• Event-driven integrations that listen to webhooks on a persistent channel.
• Pollers that hit an external API on a loop (email providers, CRMs, payment processors).

If the work is scheduled on a timer rather than triggered by an event, use a cron job instead. Cron jobs scale to zero between runs, which is cheaper than running a worker 24/7.

Related

• Cron jobs for scheduled one-shot tasks.
• Key-value store as a message bus or queue backing.