There are a number of options to deploy your source code from a Git repo to containers, including a whole container redeployment, instant redeploy via volumes, or a “git clone” approach. However, when it comes to automation of this process and moving to continuous deployment, many developers can face the complexity, as they need to know how to properly combine all the application components with the required interconnection points.
Specifically in the containers world, you have to manage builds of your stack images and deal with the extra complexity of the CI/CD pipeline. And the whole container redeploy may not be the best approach if you make frequent commits without configuration changes in the operating system, application server stack, or its dependencies.

To ease deployment automation, the PaaS platform prepared a special dedicated Git-Push-Deploy package for code delivery into the pre-built container images. This package implements a number of configurations to set up automatic deployment of committed changes within your Git application source repository to the cloud, making them available for further testing with minimal delays.
Git-Push-Deploy Specifics
The Git-Push-Deploy package can be integrated with GitHub and GitLab repositories. It is developed for automatic delivery of updates within your Java, PHP, Ruby, Node.js, and Python application sources and can be applied to all application servers’ certified stack templates.
The workflow depends on the programming language used in your project:
- For Java-based projects, the package initiates the creation of a separate environment with a Maven build node, which will be responsible for interaction with the remote Git repository, triggering your application builds, and their deployment to the application server.
- For PHP/Ruby/Node.js/Python applications, the package sets up a pipeline for project deployment directly to the ROOT context on a web server (here, consider that Ruby app servers are supplied with a deployment mode instead of a context within the dashboard, though the actual project location is the same).
Repository Pre-Configurations
For a proper add-on installation, you’ll need to provide a Personal API Token for your Git account. This enables the package to set up a webhook for the corresponding repository, which will initiate application redeployment each time any change is contributed to its code.
So let’s generate one. Below, we provide instructions for both GitHub and GitLab repositories. If you are using another Git VCS, please refer to its documentation for similar steps.
Generating Access Token on GitHub
To get a personal access token for your GitHub account, navigate to the Settings > Developer Settings > Personal access tokens and select the preferred token type (classic or fine-grained). Click the Generate new token button.

- For the classic token (give access to all your repositories), specify:
- Note – token description
- Expiration – validity period for the token
- Select scopes – for our example, tick at least repo and admin:repo_hook scopes

- For the fine-grained token (give access to a specific repository), specify:
- Token name and Description – token unique name and description (optional)
- Resource owner – token will only be able to make changes to resources owned by the selected resource owner
- Expiration – validity period for the token
- Repository access – select the required repositories
- Permissions – allow at least read and write access for Webhooks and read access for Metadata and Contents

Click Generate token at the bottom of the page, review and confirm in the pop-up window.
Make sure to copy and save the generated token value now, as you won’t be able to see it again after leaving this page.

Now, you can proceed to the Install Git-Push-Deploy Package section below.
Generating Access Token on GitLab
To generate a personal access token on GitLab, enter your account Settings and switch to the Access Tokens tab.
Here, specify the optional token Name, its Expiry date (can be left blank), and tick the api permission scope.

Click the Create Personal Access Token button.
In the opened page, copy and temporarily store your access token value anywhere else (as you won’t be able to see it again after leaving this page).

Now, you are ready for package installation.
Extra Pre-Configurations for Java Projects
If running a Java-based project, you need to ensure its proper interaction with the Maven build node by adding a special Project Object Model (POM) file to its structure.
So, create a pom.xml file in your project repository root, with the following content as an obligatory basis:
|
|
Where optional values are:
- groupId – group of a project (e.g., company name)
- artifactId – name of a project
- version – your application version
The remaining parameters should be left unchanged.
Install Git-Push-Deploy Package
Git-Push-Deploy package is an add-on, so it can be installed only on top of an environment. We have prepared two separate environments with Tomcat and Apache PHP application servers to show the workflow for different programming languages.
If you are going to use a previously created environment, note that the package will overwrite the application deployed to the ROOT context. So, to keep your already deployed application, move it to the custom context. We recommend creating a new environment and then proceeding to the installation:
1. Click the Marketplace button at the top pane of the dashboard and search for the Git-Push-Deploy add-on:

Click Install to continue.
2. In the opened frame, specify the following details about your repository and target environment:
- Git Repo URL – HTTPS link to your application repo (either regular or .git one). You can fork our sample Hello World application to test the flow
- Branch – a project branch to be used
- User – enter your Git account login
- Token – specify the access token you’ve previously created for webhook generation
- Environment name – choose an environment your application will be deployed to
- Nodes – application server name (is fetched automatically upon selecting the environment)

Click Install to continue.
3. Wait a minute for the platform to fetch your application sources from GitHub and configure a webhook for continuous deployment.

Close the notification frame when installation is finished.
4. Depending on the project type, the result will be the following:
- For Java-based infrastructure, you’ll see a new environment appear on your dashboard with a Maven build node inside. It will build and deploy your application to the ROOT context on a web server each time the source code is updated.
Pay attention that it might take some time for Maven to compile a project (though the package installation itself has already finished), so you need to wait a few minutes before launching it. The current progress of this operation can be tracked in real time via the vcs_update log file on Maven.
- For PHP-based infrastructure (and other supported languages), your application will be deployed directly to the chosen server ROOT
Note: For Ruby application servers, the similar Projects section provides information on the used deployment mode (development by default) instead of a context, while the actual app location refers to the server root as well.
To start your application, click on Open in Browser next to your web server.

That’s it! Now, a new version of your application is automatically delivered to the application server upon each commit to a repository.
Redeployment Policies for Different Stacks
The table below lists the behavior of different application servers after receiving the updated code.
| Stack Name | Policy |
|---|---|
| Tomcat | Restart |
| TomEE | Restart |
| GlassFish | Hot Redeploy via Server API |
| Jetty | Restart |
| JBoss | Restart |
| WildFly | Restart |
| SpringBoot | Restart |
| Apache PHP | Advanced ZDT |
| NGINX PHP | Advanced ZDT |
| Apache Ruby | Graceful Reload |
| NGINX Ruby | Graceful Reload |
| NodeJS | Restart |
| Python | Restart |
To eliminate possible application downtime for a server with a Restart update policy, scale it out to be run over multiple containers. In this case, the required updates will be applied to the instances sequentially, with a 30-second delay by default.
Test Automated Deploy from Git
And now let’s check how this process actually works. Make some minor adjustments to the code in a repo and ensure everything is automated:
1. Click Edit this file for some item within your project repository and Commit changes to it – for example, we’ll modify the text at our HelloWorld start page.

2. As a result, the appropriate webhook will be triggered to deploy the made changes into your hosting environment – refer to the repository Settings > Webhooks section for the details.

Upon clicking on this string, you’ll see the list of Recent Deliveries that were initiated by the webhook and the result of their execution.
3. As the last checkpoint, return to your application page and refresh it (whilst remembering that it may take an extra minute for Maven to build and deploy your Java-based project).

That’s it! As you can see, the modifications were successfully applied, so the solution works as intended.
Simply update your code, make commits as you usually do, and all the changes will be pushed to your PaaS environment automatically. No need to switch between processes or make manual updates, which eliminates human errors and accelerates time to market for your application.