Developer Center


Add https components to a service to deploy websites and apis.

HTTPS components

Https components let you deploy code to an https endpoint that is either public or internal.

Public https components are used to deploy APIs and websites to the public, while Internal https components are used to deplyo APIs and websites that are accessible to other services and users inside your network.

If you are deploying a static site, we recommend using a static component.

We are adding support for build packs soon.

Minimum config

A minimum https-public config looks like:

  - type: https-public
    instances: 1 - 5
    cmd: /app/scripts/cmd

A minimal https-internal config looks like:

You can run pt schema validate at any time to validate a service config.


  • type: component type (required)
  • instances: number of container instances (required)
  • cmd: command to run inside the container to start the https service (required)


  • mem

  • cpu

  • hooks

  • dockerfile

  • port

  • route

  • health: endpoint to check health of the container (default: /)

  • ready: endpoint to query when a container is ready to serve traffic (default: /)

Ready checks are useful for services that need to do setup time when they startup.

Provisioned resources

Each https component in a service provisions:

  • loadbalancer - a cloud provided load balancer
  • kubernetes deployment
  • kubernetes pod autoscaler
  • kubernetes service
  • dns entry for route

A public https component provisions the following additional resources:

  • kubernetes ingress
  • cloud managed SSL certificate
  • global public ip address
  • cloud cdn + waf (coming soon)

More architecture / cloud resource documentation is coming soon.