Processes

Run web servers, background workers, and scheduled jobs from the same codebase and Docker image.

Process types

Type	Description
`web`	Receives HTTP traffic. Gets a public URL, TLS, and `PORT` injected. At least one web process is required for your app to be reachable.
`worker`	Long-running background process. No inbound traffic, no `PORT`. Use for queue consumers or any persistent background task.
`cron`	Runs on a schedule. Specify a cron expression. Suitable for cleanup jobs, email digests, periodic syncs.

All process types share the same Docker image, secrets, and database connections. You only maintain one Dockerfile.

Adding a process

MCP (Claude Code / Cursor)

configure_process(
  app_name: "my-api",
  process_name: "web",
  process_type: "web",
  command: "gunicorn app:app --bind 0.0.0.0:$PORT",
  health_check_path: "/health"
)

configure_process(
  app_name: "my-api",
  process_name: "worker",
  process_type: "worker",
  command: "python worker.py"
)

configure_process(
  app_name: "my-api",
  process_name: "digest",
  process_type: "cron",
  command: "python -m jobs.digest",
  cron_schedule: "0 9 * * *"
)

CLI

promptship process configure my-api web --type web --command "gunicorn app:app --bind 0.0.0.0:\$PORT"
promptship process configure my-api worker --type worker --command "python worker.py"
promptship process configure my-api digest --type cron --command "python -m jobs.digest" --schedule "0 9 * * *"

Web process

The web process receives all public HTTPS traffic. PromptShip provisions a platform subdomain (my-api-dev.apps.promptship.dev) and TLS automatically.

Your app must listen on $PORT and bind to 0.0.0.0, not localhost. See Env Vars for usage examples.

Use health_check_path to tell the platform which endpoint to probe before marking a deploy as succeeded. The endpoint must return HTTP 200.

Worker process

Workers are long-running processes that start alongside web processes but receive no inbound traffic. Use them for:

Queue consumers (Celery, RQ, BullMQ)
Background processing loops

Workers share all secrets and database connections with the web process. Each process runs its own command — no wrapper scripts needed:

configure_process(
  app_name: "my-api",
  process_name: "worker",
  process_type: "worker",
  command: "celery -A app worker --loglevel=info"
)

The PROCESS_TYPE and PROCESS_NAME env vars are injected into every process if you need runtime branching.

Cron process

Cron processes run on a schedule using standard cron syntax. The container starts, runs to completion, and exits.

# Every day at 9am UTC
0 9 * * *

# Every 15 minutes
*/15 * * * *

# Every Monday at midnight
0 0 * * 1

Cron jobs share the same secrets and database connections as other processes. Logs are available via get_logs / promptship logs after each run.

Removing a process

remove_process(app_name: "my-api", process_name: "digest")

promptship process remove my-api digest

Removing a process stops and deletes the running container. The next deploy will not restart it.