The PaaSTA Contract

The PaaSTA Contract is similar to the 12 Factor App documented for Heroku. It specifies what kinds of apps are suitable for PaaSTA and what that app must do to run properly

Basic requirements


PaaSTA assumes that the source for a service is stored in a single Git repository, which can produce a single Docker image. The image MUST run that service, though the same image MAY support multiple use cases (worker daemon, web task, etc).


The Docker image MUST contain all the code necessary to run the service.


PaaSTA services SHOULD be stateless. Services MAY do filesystem IO, but all disks are ephemeral with Docker (with the possible exception of RW bind-mounts, which are discouraged).


Services should log to external log processors, at Yelp this is Scribe.


PaaSTA reserves the right to cause a bounce on your service at any time. Please make sure your service can handle this. See the docs on bouncing for bounce settings that can help make bounces less impactful to your service.

HTTP/TCP services

  • MUST be discoverable by SmartStack
  • MUST bind to port 8888 if using the 'bridge' networking mode or ONLY to the ports $MARATHON_PORT if using the 'host' networking mode

Long-running tasks (services that don’t listen on a port, or “batch daemons”)


  • Not have a SmartStack configuration file (smartstack.yaml)…

  • If they have a SmartStack configuration file (e.g. because a single service codebase provides both an HTTP service and a long-running task) the instance configuration for the long-running task MUST NOT define a proxy_port:

    # marathon.yaml
      instances: 3
      instances: 1
    # smartstack.yaml
      proxy_port: 12345
    # (no worker definition in smartstack.yaml!)
  • MAY set healthcheck_mode to cmd and specify a healthcheck_cmd in marathon-<cluster>.yaml to give Mesos better insight into the health of a task:

    # marathon.yaml
      healthcheck_mode = "cmd"
      healthcheck_cmd = "/"

Deployment Workflow