Modifying Applications

All OpenShift applications are built around a Git source control workflow - you code locally, then push your changes to the server. The server then runs a number of hooks to build and configure your application, and finally restarts your application. Optionally, applications can elect to be built using Jenkins, or run using hot deployment which speeds up the deployment of code to OpenShift.

Learn how to use Git by reviewing the basic concepts of Git version control. Try out this 15-minute introductory course by Code School and GitHub. START COURSE

Making Changes to your Application

As a developer on OpenShift, you make code changes on your local machine, check those changes in locally, and then push those changes to OpenShift. One of the primary advantages of Git is that it does not require a continuous online presence in order to run. You can easily check in (in Git terminology, 'commit') and revert changes locally before deciding to upload those changes to OpenShift.

Using the Git Repository

Every OpenShift application you create has its own Git repository that only you can access.

If you create your application from the command line, rhc will automatically download a copy of that repository (Git calls this 'cloning') to your local system.

If you create an application from the web console, you’ll need to tell Git to clone the repository. Find the Git URL from the application page, and then run:

$ git clone <git_url> <directory to create>

Submitting Changes

Once you make changes, you’ll need to add and commit those changes - add tells Git that a file or set of files will become part of a larger check in, and commit completes the check in. Git requires that each commit have a message to describe it.

$ git add .
$ git commit -m "A checkin to my application"

Finally, you’re ready to send your changes to your application - you’ll push these changes with:

$ git push

The output of the push command will contain information from OpenShift about your deployment.

When you Push…​

Building without Jenkins uses your application space as part of the build and test process. Because of this, the application is shut down so its memory can be used for building. The following steps take place:

  • You run a git push on your computer - your changes are sent to your OpenShift application

  • The application is shut down

  • Your changes are copied on the server into the correct location

  • OpenShift invokes your build hooks - script files you’ve placed in your Git repository

  • Your application is started

Customizing OpenShift’s Build Process

OpenShift will execute script files checked into your Git repository at specific points during the deployment process. If the corresponding script file does not exist, the deployment process will continue normally. All hooks must be placed in the .openshift/action_hooks/ directory in your application repository.

The individual phases of each build are:

  • Pre-Receive During your push, OpenShift checks to ensure that your application is in a consistent state. There is no hook for this step.

  • Pre-Build This happens after the application is stopped and the new repo dir has been deployed but before the build. Runs the .openshift/action_hooks/pre_build script

  • Build This builds your application, downloads required deps, executes the .openshift/action_hooks/build script and preps everything for deployment.

  • Deploy This step happens right before the application is issued a start. Any required prep work to get the application ready to be started should be done in the .openshift/action_hooks/deploy hook.

  • Post-Deploy Some applications may need to interact with the running application to complete the deployment process. After the application starts, the .openshift/action_hooks/post_deploy hook will be executed.

For example, if you want to download a file from another site during your build step, you would do the following:

$ mkdir -p .openshift/action_hooks

Edit .openshift/action_hooks/build to contain:

echo Downloading
curl -o $OPENSHIFT_DATA_DIR/ http://myserver/

Add the hooks to Git version control and push to the server:

$ git add .openshift
$ git commit -m "Adding a build hook"
$ git push

During the push, you should see "Downloading…​" printed to your screen.

Continuous Delivery with Jenkins

Building with Jenkins uses dedicated application space that can be larger than the application runtime space. Because the build happens in its own dedicated gear, the running application is not shut down or changed in any way until after the build succeeds. If it fails, the running application code will not be changed. However, a failure during the deploy process such as missing dependencies, bad runtime code, or incorrect build output may leave the app partially deployed or inaccessible.

Hot Deployment


When the git push command is run to upload code modifications, OpenShift Online stops, builds, deploys, and restarts an application. This entire process takes time to complete and is unnecessary for many types of code changes. With hot deployment the changes to application code are applied without restarting the application cartridge, resulting in increased deployment speed and minimized application downtime.

OpenShift Online provides support for hot deployment through a hot_deploy marker file. If the marker is present, supported application cartridges automatically hot deploy when the git push command is executed.

Enabling and Disabling Hot Deployment


Enable hot deployment by creating the hot_deploy marker file in the application’s root directory with the following command:

C:\app_directory> copy NUL > .openshift\markers\hot_deploy

Disable hot deployment by deleting the hot_deploy marker file.

Mac OS X and Linux

Enable hot deployment by creating the hot_deploy marker file in the application’s root directory:

$ touch .openshift/markers/hot_deploy

Disable hot deployment by deleting the hot_deploy marker file.

Hot Deployment Build Details

JBoss AS, JBoss EAP, Tomcat 6, and Tomcat 7

When JBoss AS, JBoss EAP, Tomcat 6, and Tomcat 7 applications are hot deployed, the Maven build is executed (either with Jenkins or without), but the server does not restart. Following the build, the JBoss HDScanner notices any modifications and redeploys them. If previously deployed artifacts are removed as part of the update, they are undeployed automatically.

PHP, Zend Server, Perl, Python, and Node.js

When PHP, Zend Server, Perl, Python, and Node.js applications are hot deployed, the application code is built (dependencies are processed and user build action_hooks are run) and deployed to the application server. The server does not restart. This is true regardless of whether an application has Jenkins enabled or not. For applications that have Jenkins enabled, the build is performed on a Jenkins slave instance and then synced to the gear(s) where the application server is running.


When a Ruby application is hot deployed, the Passenger restart.txt file is touched, and the application server serves the new code without requiring a full server restart. See the Passenger Documentation for more information.

Application Types That Can or Cannot Be Hot Deployed

Type of Application Hot Deploy

JBoss Application Server


JBoss Enterprise Application Platform


Tomcat 6 (JBoss Enterprise Web Server 1.0)


Tomcat 7 (JBoss Enterprise Web Server 2.0)












Zend Server