A Servable is an instantiation of a Prototype that when running results in a Kubernetes Pod and Service. The Service exposes the Pod within the Kubernetes Cluster itself. This enables Servables to run non-HTTP services and make those services accessible to other Servables, but does not enable access to them from outside of the cluster.


Servables can be one of the following types:

  • App

  • Dataset

  • Model

  • Report

  • Pipeline

  • Daemon

With the exception of Pipeline and Daemon, all of these types are equivalent. The reason for different types to exist is that while the implementation is the same, the semantic meaning is not, which matters when it comes to making access control decisions. It is often useful to be able to grant an App some Capabilities on Models, but not on Datasets. These pre-defined types are the only types available, but they should be general enough to model a variety of different domains and use cases.

Apps, Datasets, Models, and Reports are expected to have HTTP interfaces. Authenticated users with the Request Capability on the Servable will be allowed to make HTTP requests to the Servable.

Daemons do not expose HTTP interfaces by default, but are instead intended to provide non-interactive services to support other Servables. Pipelines also do not expose an HTTP interface, and are expected to complete a discrete task and then exit, whereas other Servables, including Daemons, are expected to run forever or until they are stopped. There is nothing enforcing this behavior at this time, but it is an expected convention.


Servables are exposed to DTaaS users through an HTTP Proxy that is able to authenticate them. Access to Servables is routed through different domain prefixes. For example, if DTaaS is deployed to, then by default a Servable is accessible on Servables that expose HTTP interfaces must do so on port 8080.

Servables are exposed via the same mechanism as a dtApp, with the authentication field being set to an internal ACL service that implements our Capability system. When a Servable is exposed in a node that is part of a dtDomain, then the domainSelector is set to the dtDomain that the node is a part of.


Servables are able to be exposed with or without authentication. Disabling authentication will allow any HTTP request through, even from unauthenticated sources. Enabling authentication will only allow requests from authenticated sources that have the Request Capability on the Servable.

Disabling authentication does not mean that there is no security around a Servable, only that the Servable is managing its own security semantics. For example, rather than relying on DTaaS Capabilities to determine access control, a Servable can perform its own Authentication the same way any other web application could.