The shipa.yaml is a special file located at the root of the application source code. The name of the file may be either shipa.yaml or shipa.yml.

The file is used to describe certain aspects of the application being deployed. The file describes information about deployment hooks and deployment time health checks.

Deployment Hooks

Shipa provides different deployment hooks options, such as restart:before, restart:after and build. Deployment hooks allow developers to run commands during different stages of the application deployment.

Below is an example of how to declare hooks in the shipa.yaml file:

      - python local_file
      - python clear_cache

Currently, Shipa supports the following hooks:

  • restart:before: executes commands before the unit is restarted. Commands listed in this hook run once per unit. For instance, if there is an application with two units and the shipa.yaml file listed above, the command python local_file would run two times, once per unit.
  • restart:after: works like before-each, but runs after restarting a unit.


Developers can declare a health check in the shipa.yaml file. Provide health check probes as defined at under healthcheck element as described below:

                - cat
                - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
                - cat
                - /tmp/lively
        initialDelaySeconds: 5
        periodSeconds: 5

Shipa reports deployment failure if health check fails. If doing canary deployment, next version doesn't get activated until health check passes.

Kubernetes Configuration

If the application is running on a Kubernetes-provisioned framework, Developers can set specific configurations for Kubernetes. These configurations are ignored if the application is running on a Shipa provisioner.

Developers can configure which ports are exposed to each process of the application. Here is a complete example:

       - name: web 
         protocol: TCP
         target_port: 5000
         port: 8080
       - name: socket-port
         protocol: TCP
         port: 4000
      ports: []

Each exposed port can be configured for each process using the port's key:

  • kubernetes:processes::ports:name: is a descriptive name for the port. This field is optional.
  • kubernetes:processes::ports:protocol: defines the port protocol. The accepted values are TCP (default) and UDP.
  • kubernetes:processes::ports:target_port: is the port that the process is listening on. If omitted, the port value is used.
  • kubernetes:processes::ports:port: is the port that will be exposed on a Kubernetes service. If omitted, the target_port value is used.

If both port and target_port are omitted in a port config, the deployment fails.

Developers can set a process to expose no ports with an empty field, like worker above.

The configuration for multiple ports still has a couple of limitations:

  • Healthcheck is set to use the first configured port in each process
  • Only the first port of the web process (or the only process, if there is only one) is exposed in the router - but Developers can access the other ports from other applications in the same cluster, using Kubernetes DNS records, like *appname-processname.namespace.svc.cluster.local


Shipa supports secret injection into the application using the HashiCorp Vault product.

Shipa.yaml has a security section where you can define Vault annotations for secret injection.

                {{- with secret "internal/data/database/config" -}}
                    postgresql://{{ }}:{{ }}@postgres:5432/wizard
                {{- end -}}

Annotate Kubernetes resources managed by Shipa

Provide annotations to be applied to shipa managed kubernetes resources of deployed application such as Ingress, Deployment etc.

    - kind: Ingress
      values: basic basic-auth 'Authentication Required - foo'
    - kind: Deployment
        key1: val1