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)

add_process(
  app_name: "my-api",
  process_name: "web",
  process_type: "web",
  health_check_path: "/health"
)

add_process(
  app_name: "my-api",
  process_name: "worker",
  process_type: "worker"
)

add_process(
  app_name: "my-api",
  process_name: "digest",
  process_type: "cron",
  cron_schedule: "0 9 * * *"
)

CLI

promptship process add my-api web --type web
promptship process add my-api worker --type worker
promptship process add my-api digest --type cron --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. In your Docker entrypoint, branch on an environment variable or command argument to run a different entry point:

# Dockerfile CMD runs web by default
CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:$PORT"]

# Override per process via a start command (coming soon)
# For now, use a wrapper script that checks an env var

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.