Skip to content

Deployment and CI/CD Updated 2026-05-27

Application deployment overview

Overview of the deployment surfaces on Stack Harbor PaaS — archive upload, VCS auto-deploy, container image redeploy, deployment hooks, and zero-downtime strategies.

Stack Harbor PaaS exposes several ways to ship application code into a running environment. You can upload an archive, hand the platform a Git or SVN URL, pull a container image from a registry, or trigger any of the above through the CLI or the API. This page is the index for the deployment surfaces — each one is documented separately.

What this section covers

  • Application deployment — the end-to-end story across archives, VCS projects, and Docker-based deployments.
  • Deployment Manager — the dashboard panel that stores reusable archives and registered VCS repositories.
  • Deployment Guide — the configuration reference for the deploy dialog: paths, branches, hooks, deploy strategy, zero-downtime toggles.
  • Deployment hooks — pre- and post-deploy scripts that run as part of every deploy.
  • Auto-deploy from Git / SVN — periodic polling of a remote repository, with auto-deployment on detected changes.
  • Git-Push-Deploy — push-triggered deployment via repository webhooks, integrated with GitHub and GitLab.
  • Blue/green deployment — zero-downtime release using two parallel environments behind a traffic distributor.
  • CLI VCS deploy — manage VCS projects from the command line.
  • Redeploy — switching a container to a new image tag while preserving configuration and data.

Deployment surfaces

Three primary sources feed the deployment pipeline:

  • Archive — a packaged build (.zip, .tar.gz, .tar.bz2, .tar, .war, .jar) uploaded from a local file or fetched from a URL. Supported across all runtimes (Java, PHP, Ruby, Python, Node.js, .NET, Go).
  • VCS — a Git or SVN repository registered in the Deployment Manager. The platform clones the repository into the application server, with optional polling for new commits.
  • Container registry — for Docker-based application servers, the platform pulls an image from a public or private registry and runs it.

For Java applications, deployment from VCS uses a Maven build node that compiles the project and pushes the resulting artifact to the application server. For PHP, Ruby, Python, Node.js, and Go, the application server runs the project sources directly.

Avoiding downtime

Two strategies are available, depending on the application server:

  • Sequential deployment with delay — for scaled application server layers, instances are redeployed one at a time with a configurable delay. Other instances keep serving traffic.
  • Zero-downtime deployment (PHP) — for Apache PHP and NGINX PHP application servers, the deploy flow swaps the document root atomically and avoids interrupting in-flight requests.

For more substantial release patterns, the blue/green deployment approach uses two parallel environments behind a traffic distributor, with traffic shifted between them.

Automation paths

  • Auto-deploy — register a Git or SVN repository with the Check and auto-deploy updates option enabled. The platform polls at a configurable interval and redeploys when new commits are detected.
  • Git-Push-Deploy — for GitHub and GitLab, a webhook on the repository triggers redeployment on every push. No polling delay.
  • CLI — every deploy action exposed in the dashboard is available through the CLI, suitable for build pipelines.
  • API — the same operations are accessible programmatically via the REST API.

See also