• Dark
  • PDF


  • Dark
  • PDF


A Service is a running deployment of Modules within a Package.
You must have a bot in order to deploy and run a service. For more information go to bots.
A Service entity specifies from which Module it should be deployed, what arguments should be passed to the Module's exported class' init method, and the infrastructural configuration for it, such as the number of replicas and the CPU/memory requirements per replica.

A replica is the number of machines that run at the same time.

Once the service is ready, one may execute any available function on any input.
Note that multiple services can be deployed from the same module.

The "init" Method

The "init" method is a unique method in the exported class that you can use if needed.
It is used for uploading heavy pre-processing or models on a service level, so you won't need to upload it on every execution.

This method is invoked immediately after loading the Module and is used for initializing the replica of the Service.
For example, for an image bounding box classifier, the "init" method will download the model and load it to its memory.
All subsequent invocations of a function in the Service will use the loaded model to calculate the bounding box for the image.
The schema for the inputs of the "init" method of the Module is defined in the "initInputs" field of the Module.
The actual value passed to the "init" method at loading time will be taken from the "initParams" field of the service.


The following statuses can be assigned to a service:
  • Active: an active service has running replicas or an autoscaler configured to create replicas automatically when executions are created for the service.
  • Inactive: when a service is paused, all replicas go down. Any trigger or UI slot set for the service will become inactive as well.
  • Initializing: initializing one or more of the service replicas. This status is usually displayed after activating a service, or when autoscaler is in action.
  • Error: when the service fails to deploy. The service replicas have active errors (can be fount under "Error info").


A deployed service gets a version that represents its state. Every time you update a service it will bump its version and its previous state will be saved in the service revision. Later on, you can re-deploy the service with an earlier revision. To view the service revisions run:

# List of history revisions of the service each time that the service has been updated with the service.update() command
# The revision of the currently used package codebase (the service can use the old package version)

Service JSON

  "name": "service-name",           # service name
  "packageName": "default_package", # package name
  "packageRevision": "latest",      # what package version to run?
  "runtime": {
    "gpu": false,                   # Does the service require a GPU?
    "replicas": 1,                  # How many replicas should the service create
    "concurrency": 6,               # How many executions can run simultaneously?
    "runnerImage": ""               # You can provide your own docker image for                                                                         the service to run on.
    "triggers": [],                 # List of triggers to trigger service
    "initParams": {},               # Does your init method expects input if it                                                                              does provide it here.
    "moduleName": "default_module"  # Which module to deploy?

Advanced Information on Services can be found in the Advanced Guides Section.

What's Next