Git-Push-Deploy

Git-Push-Deploy is the platform’s add-on for push-triggered continuous deployment. When installed, it sets up a webhook on the configured repository. Every push to the tracked branch triggers a redeploy on the application server — no polling delay, no intermediate CI orchestration.

The add-on supports GitHub and GitLab. For other Git providers, fall back to polling-based auto-deploy.

Supported runtimes

Git-Push-Deploy works with all certified application server stacks: Java, PHP, Ruby, Node.js, Python.

The workflow differs by runtime:

• Java — the add-on creates a separate environment with a Maven build node. The build node clones the repository, builds the project, and pushes the artifact to the application server on each commit.
• PHP, Ruby, Node.js, Python — the add-on deploys the project sources directly to the application server’s ROOT context. For Ruby, the dashboard shows a deployment mode instead of a context; the project still lives at the server root.

Constraints

The add-on only deploys to the default ROOT context:

• If an application is already deployed to ROOT, it will be overwritten by the add-on installation. Move it to a custom context first if you need to keep it.
• Push-trigger updates are tracked only for the ROOT context.
• Custom (non-ROOT) contexts and multiple contexts for the same repository are not supported.

Repository pre-configuration

The add-on needs a personal access token from your Git provider to set up the webhook.

GitHub

Navigate to Settings > Developer Settings > Personal access tokens and pick a token type (classic or fine-grained). Click Generate new token.

For a classic token (access to all repositories):

• Note — token description.
• Expiration — validity period.
• Scopes — minimum repo and admin:repo_hook.

For a fine-grained token (access scoped to specific repositories):

• Token name and Description — required.
• Resource owner — the account or organization that owns the repositories.
• Expiration — validity period.
• Repository access — pick the specific repositories.
• Permissions — at minimum, read and write access for Webhooks, read access for Metadata and Contents.

Click Generate token. Copy and store the token value immediately — it is not shown again after you leave the page.

GitLab

Open your account Settings > Access Tokens tab. Specify:

• Name — token name.
• Expiry date — optional.
• Scopes — tick api.

Click Create Personal Access Token and copy the token value.

Java pre-configuration

Java projects routed through Maven need a pom.xml at the repository root. A minimal Project Object Model:

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.mycompany.app</groupId>
   <artifactId>my-app</artifactId>
   <version>1.0</version>
   <packaging>war</packaging>
   <build>
       <finalName>${project.artifactId}</finalName>
   </build>
</project>

groupId, artifactId, and version are project-specific. The remaining elements should stay as shown.

Installing the add-on

1. Click Marketplace at the top of the dashboard and search for Git-Push-Deploy. Click Install.

2. Fill in the installation dialog:

   • Git Repo URL — HTTPS link to the repository (with or without the .git suffix).
   • Branch — the branch to track.
   • User — your Git account login.
   • Token — the access token created earlier.
   • Environment name — the target environment.
   • Nodes — application server name (auto-populated on environment selection).

3. Click Install. The platform fetches the sources and configures a webhook on the repository.

4. Depending on the runtime:

   • Java — a new environment appears with a Maven build node. The build node compiles and deploys the project on each push.
   • PHP, Ruby, Node.js, Python — the project is deployed directly to the application server ROOT context.

For Java, Maven may need a few minutes to compile the first build. Track progress in the vcs_update log file on the Maven node.

Click Open in Browser on the web server to launch the deployed application.

Redeploy policies per stack

The behaviour of each application server after receiving updated code:

For stacks with a Restart policy, scale the application server layer out to multiple instances to avoid downtime. Restarts are then applied sequentially, with a 30-second delay by default between instances.

Testing the flow

Make a small change to the repository (for example, update the start-page text) and commit. The webhook fires, the platform pulls the change, and — after a redeploy — refreshing the application shows the update.

For Java, allow extra time for Maven to build before refreshing.

See also

• Deployment guide
• Auto-deploy from Git / SVN
• Deployment hooks
• PHP zero-downtime deployment