> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Worker and background processes

> Run a project as a background process type (worker, queue, scheduler, reverb) instead of a public web service.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Deploy long-running background work — queue consumers, schedulers, socket servers — with the right health model and resources.

## Prerequisites

* A project that builds successfully
* A start command that runs your background process

## Workflow

<Steps>
  <Step>
    Choose the project’s process type in the import flow or project settings runtime fields.
  </Step>

  <Step>
    Set the start command to the process you want to run (for example, your queue worker command).
  </Step>

  <Step>
    Pick a resource preset appropriate for the workload (a dedicated worker preset is available).
  </Step>

  <Step>
    Deploy; the process runs headless and is monitored by process health rather than an HTTP probe.
  </Step>
</Steps>

## Process types

* web: a public HTTP service with ingress and HTTP health checks (the default).
* worker: a generic long-running background process.
* queue: a queue/job consumer.
* scheduler: a long-running scheduler process (distinct from one-off scheduled jobs).
* reverb: a websocket/realtime server process (Laravel Reverb-style).

## How background process types differ from web

* No public ingress is provisioned — background processes are not exposed on a domain or port.
* Health is determined by whether the process is running, not by an HTTP health check.
* They use a dedicated start command rather than a web server entrypoint.
* A worker resource preset (more memory/CPU) is available for heavier background work.

## Web plus background work

A project runs as a single process type. To run a public web service and a separate background worker for the same codebase, deploy them as separate projects (each with its own process type and start command) so each gets the correct health model, scaling, and resources.

## Expected result

<Check>
  A continuously running background process with no public port, kept alive and restarted like any other workload.
</Check>

## Common failures

<Warning>
  * Process exits immediately: the start command returned instead of staying resident — make sure it runs in the foreground.
  * No URL for a worker: that is expected — background process types do not get public ingress.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Scheduled jobs (cron)" href="/projects/scheduled-jobs">
    Run a command from your deployed image on a recurring standard-cron schedule, with run history and exit-code tracking.
  </Card>

  <Card title="Deploy from GitHub" href="/projects/deploy-from-github">
    Use the repository-backed project flow when you want StackShift to detect the app, build from source, and let you override runtime behavior before the first deploy.
  </Card>

  <Card title="Builds, deployments, and logs" href="/projects/builds-deployments-and-logs">
    Understand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.
  </Card>
</CardGroup>