The Shipa Developer Hub

Welcome to the Shipa developer hub. You'll find comprehensive guides and documentation to help you start working with Shipa as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Changelog


Shipa provisioners are responsible for creating and scheduling units for applications and node-containers. Currently, Shipa supports its own internal provisioner and Kubernetes.

Provisioners are also responsible for knowing which nodes are available to create units, register new nodes, and remove old nodes.

Provisioners are associated with frameworks. Shipa uses frameworks to find out which provisioner is responsible for each application. A single Shipa installation can manage different frameworks with different provisioners at the same time.

Shipa Provisioner

Shipa's provisioner uses MongoDB to store metadata of existing nodes and containers on each node and track images as they are created on each node. To accomplish this, Shipa talks directly to the Docker API on each. The Docker API must be allowed to receive connections from the Shipa API using HTTP or HTTPS.

Shipa relies on the default BusyBody node-container to monitor containers on each node and report back which containers are unavailable or have had their address changed by Docker restarting them. The Shipa provisioner is then responsible for rescheduling those containers on new nodes.

There is no need to register a cluster to use the Shipa provisioner. With the Docker API running, add new nodes, and Shipa can use them.

When units are scheduled on nodes, those application containers receive high availability prioritization. Shipa creates each new container on the node with the fewest containers from the application. If there are multiple nodes with no containers from the application being scheduled, Shipa creates new containers on nodes with different metadata from those that already exist.

Kubernetes Provisioner

You can register a Kubernetes cluster in Shipa that points to the Kubernetes API server. The Shipa Kubernetes provisioner uses Kubernetes itself to manage its nodes and containers. Shipa doesn’t store anything in its internal storage related to nodes and containers that are part of a Kubernetes cluster.

Scheduling is controlled exclusively by Kubernetes for each application/process, and Shipa creates a Deployment controller. Changes to the application like adding and removing units are executed by updating the Deployment with rolling update configured using the Kubernetes API. Node containers are created using the DaemonSets.

A Service controller is created for every Deployment, allowing for direct communication between services without the need to go through a Shipa router.

You can scale your Kubernetes cluster in the background as usual, and Shipa will automatically identify the newly added or removed nodes

Kubernetes Compatibility

The following Kubernetes versions were tested with Shipa's 1.2 release:

  • Kubernetes 1.14.x to 1.19.x

Updated 2 months ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.