Developer Center


Add serverless components to a service to deploy serverless functions, websites and webhooks

Serverless components are currently only supported on GCP.

Serverless components

Serverless components let you deploy serverless functions that are accessible over a public or internal https endpoint.

Serverless components run on your own infrastructure and use Knative. You can build serverless functions using our 7 built in languages, or add a Dockerfile to use a custom language.

We do not currently support serverless worker functions

Built in runtimes

We support the following built in runtimes for function components.

  • python - python3 (supports a requirements.txt dependency file)
  • nodejs - latest stable version of node (supports a package.json dependency file)
  • ruby - latest stable version of ruby (supports a Gemfile dependency file)
  • golang - latest stable version of golang (supports a go.mod dependency file)
  • php - latest stable version of php (no support for dependencies yet).

If you would like to use a custom runtime, simply specify a Dockerfile


You can add a dependency file for the language of your choice into your service directory. When you run pt build, PowerTools will automatically install all dependencies for you.

Minimum config

A minimum function-public config looks like:

  - type: function-public
    runtime: golang

You can add a `runtime_version` field to use a specific version such as `1.17` of a runtime..

A minimal function-internal config looks like:

  - type: function-internal
    runtime: python3

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

You can deploy as many function components as you would like in a service.


  • type: component type (required)
  • runtime: runtime to use (required)
  • entry: runtime to use (required)
  • route


  • runtime_version - runtime version to use (other than defaulting to latest)

  • hooks

  • dockerfile

  • idle_timeout - default time a container can remain idle before being removed

  • max_tps_per_instance - maximum transactions/second a process will receive

  • max_instances - maximum processes that can be started

  • target_tps - number of transactions/second to target before autoscaling

  • min_instances - minimum number of processes to be run.

the max tps your service will receive is equal to (max_tps_per_instance * max_instances) if bothmax_tps_per_instance and max_instances are set to values greater than 0

set a high idle_timeout if you would like to keep containers around longer to avoid cold starts.

Provisioned resources

Each function component in a service provisions:

  • dns entry
  • ssl certificate
  • knative service
  • knative route
  • knative autoscaling config