Skip to content

Deployment and CI/CD Updated 2026-05-27

Auto-deploy from Git / SVN

Polling-based auto-deployment of Git and SVN repositories on Stack Harbor PaaS — configuration, polling interval, conflict resolution, and tracking auto-update runs.

Auto-deploy is the platform’s polling-based mechanism for continuous deployment from a Git or SVN repository. After you register a repository in the Deployment Manager and enable the Check and auto-deploy updates option, the platform periodically checks the repository for new commits and redeploys when changes are detected.

Unlike Git server-side hooks, auto-deploy works on the platform side and requires no configuration on the repository. It also supports SVN, which webhook-based approaches do not.

For push-triggered deployment (no polling delay), see the Git-Push-Deploy add-on.

Preparing the environment

Auto-deploy requires:

  • An environment with an application server layer (PHP, Ruby, Python, Node.js, Go, or Java).
  • For Java projects, an additional Maven build node in the same environment. The Maven node handles the build step and pushes the resulting artifact to the application server. For non-Java runtimes, the application server handles the deployment directly.

This page uses the Maven path as the example. Other runtimes follow the same dialog flow, minus the Maven-specific options.

Adding a project with auto-deploy

In the environment, click Add project next to the appropriate node — Maven for Java, or the application server for other runtimes.

In the dialog, switch to the tab matching your VCS type (Git or SVN) and fill in:

  • URL — the repository URL.
  • Authentication — credentials, token, or SSH key, depending on what the repository requires.
  • Context — the path the application should be deployed to.

For Java projects routed through Maven, also fill in:

  • Name — project name.
  • Environment — the environment where the build artifact should be deployed.

The remaining parameters match the deployment guide for VCS deployments.

Enabling auto-deploy

Tick Check and auto-deploy updates. The expanded section reveals the polling interval:

  • Check every (min) — frequency in minutes at which the platform checks the repository for new commits.

Set the interval based on how often you commit and how quickly you want deploys to roll out. A 1-minute interval gives near-immediate deploys; a 1440-minute interval gives once-daily deploys.

Notes:

  • If the polling interval is shorter than the time required to build and deploy, the next check waits in a queue until the current operation completes.
  • For application server layers with multiple nodes, review the multi-container update sequence before tightening the interval.

Additional options

The dialog exposes several options that affect auto-deploy behaviour:

  • Checkout now — present for non-Java runtimes. Controls whether the project is deployed immediately on registration, or whether the first deploy happens at the next polling cycle (or manually).
  • Auto-resolve conflict — on by default. Behaves like git reset --hard: if a file diverged between the repository and the application server, the application server copy is overwritten with the repository version. Local edits on the application server are discarded. Leave this on unless you have a specific reason to keep server-side edits.
  • Enable zero-downtime deployment — PHP only. When enabled, the choice is remembered for every subsequent auto-deploy. Avoids interruptions for applications deployed to the ROOT context.

Click Add to confirm.

Tracking auto-deploy runs

Each auto-deploy run is logged. The log file is named vcs_update and lives on:

  • The Maven build node for Java projects.
  • The application server for non-Java projects.

Open Logs on the relevant node to inspect the polling history, build output (for Java), and deploy outcome.

Adjusting a configured project

To change any setting after registration — switch branch, change polling interval, toggle zero-downtime — navigate to the environment and click Edit next to the project entry. The dialog opens with the current values populated. Adjust and click Apply.

When to use auto-deploy vs push-triggered

  • Auto-deploy — works with any Git or SVN provider. Acceptable polling delay (1 minute and up). Configurable per environment.
  • Push-triggered (Git-Push-Deploy) — GitHub and GitLab only. Zero polling delay. Requires a personal access token to set up the webhook.

For most workflows, push-triggered is preferable when the provider supports it. Auto-deploy fills the gap for SVN and for Git providers without webhook support.

See also