Docker Apps

Docker images can be deployed to Helion Stackato like source code, directly from the Docker Hub or from specific Docker registry servers:

$ stackato push -n --docker-image

Helion Stackato fetches the named image (a Docker App) from the Docker Hub or specified registry server and deploys it.

Permission to Push Docker Apps

Because certain Docker images can potentially expose a root user and other escalated privileges, Helion Stackato administrators should generally restrict the ability to push Docker images to:

  • a trusted group of users in an organization with sudo permissions enabled
  • a trusted list of Docker images, namespaces, or registry servers
  • a trusted group deploying from a trusted list

Depending on which restrictions your Helion Stackato administrator has set, an error message describing the restriction may be displayed when you attempt to push an application as an unauthorized user:

Error staging: Need 'allow_sudo' quota to stage and run a Docker app (400)

An error may also be displayed when you attempt to push an unauthorized image:

Error staging: Docker image example/simple-server is not from an allowed registry (400)

To Add sudo Permissions for All Users of a Quota Plan

  1. In the Helion Stackato console, click Admin > Quota Plans.
  2. Click a quota plan and then click Edit Quota.
  3. Check the Allow Sudo checkbox and then click Update.
  4. For the setting to take effect, restart any apps running under the quota plan.

To Remove sudo Requirements for Docker App Deployment

  1. In the Helion Stackato console, click Settings > HPE Helion Stackato Settings.
  2. On the left panel, click Docker App Settings.
  3. Uncheck the Require sudo checkbox.

Pushing Docker Apps

You can specify official Docker Hub library images by name, with or without a tag. For example:

$ stackato push --docker-image tomee:8-jre-7.0.0-M1-webprofile

You can also specify images from a particular user or organization by namespace, for example:

$ stackato push --docker-image cloudfoundry/lattice-app

Images from a particular registry server require a fully-qualified URL (without the protocol portion):

$ stackato push --docker-image

For registries that requires authentication, use the <user>:<pass>@<host> format to specify credentials:

$ stackato push --docker-image

Administrators can save default credentials for specific servers in the Allowed Registries list. Stackato uses these credentials for a specific registry server, if it is present. However, any credentials specified in the command override the default credentials.


If the registry credentials contain the @ or : characters, ensure that that username and password strings are URL-encoded.

Docker Apps and Data Services

Docker apps can be bound to data services like staged apps. $VCAP_SERVICES, $STACKATO_SERVICES, and URL-based environment variables are injected into the container and can be read by the application. For instructions on creating data service instances and binding them to applications, see the Data Services documentation.

Docker apps do not have staging hooks:, so there is no opportunity to extract and reformat credentials into the format the Docker app expects. To circumvent this issue you can do one of the following:

  1. Refactor the Docker app to consume the default service variables.
  2. Bind the new service to a temporary app (for example, go-env or node-env) to find the service instance credentials, and then set the environment variables the Docker app expects using the web console, the --env option of the CLI client, or in the manifest.yml file.

Web Process and Exposed Ports

The $PORT environment variable exposed in staged apps is also available for Docker apps to use for web processes. For example, a Dockerfile may end with the following line:

ENTRYPOINT /usr/bin/python runserver$PORT

This parameter serves the web process on a port automatically allocated by Helion Stackato.

If the app's Dockerfile exposes a single port (for example, EXPOSE 8080), Helion Stackato will forward that port instead.


If there is more than one port exposed in the Dockerfile, the deployment will fail. If there is no process to listen on a port, the docker image will be destroyed.