This page covers application deployment on Stack Harbor PaaS — the act of moving a build artifact onto a running application server in an environment. The platform supports three deployment sources and three driver surfaces, all backed by the same underlying mechanism.
Deployment sources
- Archive — a packaged build (
.zip,.tar.gz,.tar.bz2,.tar,.war,.jar) supplied as a local file or fetched from a URL. The archive is uploaded into the platform’s Deployment Manager and can be deployed to any compatible environment. - VCS — a Git or SVN repository registered with credentials in the Deployment Manager. The platform clones the repository into the application server. Subsequent updates can be triggered manually, polled on a schedule, or pushed via webhook.
- Container registry — for Docker-based application servers, an image is pulled from a public or private registry, including private registries that require credentials.
How each source is processed
The flow depends on the runtime:
- Java — VCS-based deployments go through a Maven build node. The build node clones the repository, runs the Maven build, and pushes the resulting artifact to the application server. Archive deployments skip the build step and deploy the artifact directly.
- PHP, Ruby, Python, Node.js, Go — VCS-based deployments run the project sources directly on the application server. Archive deployments unpack the archive into the deployment path.
- .NET on IIS — handled through a Windows-specific deploy flow that differs from the standardized pipeline above.
Deployment configuration
Each deployment is configured through a deploy dialog. Common parameters:
- Source — local file, URL, registered Git/SVN repository, or Docker image.
- Environment — the target environment containing the application server.
- Path — the context path (e.g.,
ROOT,/myapp). Python and Node.js use a single predefined path. - Hooks — pre- and post-deploy scripts to run as part of the operation.
- Deploy strategy — for scaled layers, either Simultaneous (faster, brief downtime) or Sequential with delay (no downtime, slower).
- Zero-downtime deployment — for PHP application servers, swaps the document root atomically.
For VCS sources, additional parameters apply:
- Branch — the branch to deploy (defaults to
master). - Build — for Java, the Maven build node to use.
- Check and auto-deploy updates — enables periodic polling at a configurable interval.
- Auto-resolve conflicts — discards local changes on the application server in favour of the repository version.
Kubernetes application deployment
For Kubernetes-based environments, applications are deployed through Kubernetes-native methods: YAML manifests, Helm charts, or Kubernetes API calls. Internal networking, service exposure, and ingress configuration are covered separately in the Kubernetes documentation.
Driver surfaces
Three ways to initiate a deployment:
- Dashboard — the Deployments row on each application server opens the deploy dialog. The Deployment Manager panel at the bottom of the dashboard stores reusable archives and VCS projects.
- CLI —
~/jelastic/environment/vcs/createproject,~/jelastic/environment/file/upload, and related commands cover every deploy action. - API — the same operations are accessible via REST API calls with a session token.
Automating deployments
Two patterns for automation:
- Polling-based auto-deploy — for any Git or SVN repository registered in the Deployment Manager. Enable Check and auto-deploy updates, set the polling interval, and the platform redeploys when new commits appear.
- Push-triggered deploy — for GitHub and GitLab, the Git-Push-Deploy add-on configures a webhook on the repository. Every push triggers a redeploy. No polling delay.
For CI pipelines (Jenkins, GitLab CI, GitHub Actions), call the CLI or the API to deploy a built artifact directly.