Skip to content

Deployment and CI/CD Updated 2026-05-27

Application lifecycle management

How to run a production, build, database, and test environment on Stack Harbor PaaS, then deploy and upgrade your application without downtime via domain swap.

Applications with custom logic and user interfaces need a development workflow that lets you iterate without breaking what end users see. Even a small project benefits from separating dev, test, and production environments. This page walks through the platform pattern: a production environment, a build environment, a shared database, and a test environment that you swap into production when a release is ready.

The recommended pattern keeps the test environment as close to production as possible, with a periodic refresh of the test database from production data. Both environments can point at the same database tier when you want a single source of truth, or at separate databases when you want test isolation.

The flow below uses a Java/GlassFish application as the example, but the same pattern works for any runtime supported by the platform.

Create the production environment

  1. Log into the platform dashboard.
  2. Create a new environment.
  3. Select the application server (for example, GlassFish), set the resource limit, name the environment (for example, prodenv), and click Create.

The environment is ready in about a minute.

Create the build environment

You can build applications on the platform instead of compiling locally and uploading WAR archives. The build runs in the cloud, takes less of your bandwidth, and pulls source code directly from your Git or SVN repository.

  1. Create a new environment with Maven as the build tool. Name it, for example, buildenv. You don’t need a compute node — Maven runs standalone.
  2. The environment is created in a couple of minutes.

A single build environment can build projects for any number of target environments.

Build and deploy the project

  1. Add your project to Maven. In the dialog, switch to the Git tab (or SVN). Specify project name, repo path, branch, credentials, target environment, and deployment context. Click Add.
  2. Click Build and deploy next to your project.

The compiled artifact lands in the production environment at the context you specified.

Create the database environment

A separate database environment lets multiple application environments share one data tier.

  1. Create a new environment and pick the database engine (for example, MySQL).
  2. When the environment is up, click Open in Browser for the database node. The platform sends a notification with credentials. Create the database account and schema for your application.

Configure the database connection

  1. Click Config next to the application server in your production environment.
  2. In the file manager, create mydb.cfg under /opt/glassfish3/temp/ with the connection details:
host=jdbc:mysql://mysql{node_id}-{your_env_name}.{hoster_domain}/{db_name}
username={from email}
password={from email}
driver=com.mysql.jdbc.Driver

You can also keep these values directly in your application code. The config file approach just keeps them out of the JAR.

  1. Upload the MySQL connector to /opt/glassfish3/glassfish/domains/domain1/lib/.
  2. Restart GlassFish and open the application in a browser.
  3. Bind a custom domain to the production environment. Click the Settings button for the environment, open Custom Domains, and add your domain via CNAME. The production URL becomes, for example, production.com.

Create the test environment

The fastest way to get a representative test environment is to clone production. The clone includes every container, every deployed WAR/JAR, and a snapshot of the database.

  1. Clone your production environment. Name the clone testenv.
  2. Open it in a browser to confirm it works.

You now have two identical environments — one serving traffic, one for staging changes.

Upgrade the application

When you have changes to ship:

  1. Add the new project version to Maven.
  2. Click Build and deploy for the new project against testenv. The artifact lands in the context you specified.
  3. Bind a staging domain (for example, test.com) to testenv via Settings.
  4. Open the staging URL and verify the new version.
  5. Once the staging build is validated, swap domains: open Settings for either environment, go to Custom domains, and click Swap.

The swap is instant — production.com now points at the freshly built environment, and test.com points at the previous production. End users see no downtime. If the new version misbehaves, swap back.

See also