Platform.sh User Documentation

Moving a Java application to Platform.sh

Upsun Beta

Access our newest offering - Upsun!

Get your free trial by clicking the link below.

Get your Upsun free trial

It is common to have a Java application that you want to migrate to Platform.sh. Platform.sh supports several styles of Java application, such as monolith, microservices, stateful, and stateless.

Minimum Requirement Anchor to this heading

To run a Java application at Platform.sh you need:

Monolith/Single Application Anchor to this heading

To start a Java application, you need to understand the Platform.sh structure. You will need to configure your application, routes, and services.

Application Anchor to this heading

.platform.app.yaml
name: app
type: 'java:<VERSION>' [1]
disk: 1024
hooks:
    build: [2]
web:
    commands:
        start: [3]
  1. A Java version, e,g.: java:21
  2. Hooks define what happens when building the application. This build process typically generates an executable file such as a uber-jar e.g.: mvn clean package
  3. The commands key defines the command to launch the application. E.g.: java -jar file.jar
  4. In the start’s command needs to receive the port where the application will execute thought the PORT environment. That’s best when your app follows the port bind principle. E.g.: java -jar jar --port=$PORT

Route Anchor to this heading

.platform/routes.yaml
"https://{default}/":
    type: upstream
    upstream: "app:http" [1]
"https://www.{default}/":
    type: redirect
    to: "https://{default}/"
  1. It defines the application will link in the route, e.g.: "app:http"

Microservices Anchor to this heading

You have the option to use several languages in microservices. If you’re using Java there are several options to aggregate these services into a microservices:

Platform.sh supports multiple applications and there are two options:

  • One application YAML file to each application
  • Aggregate all applications in a single file with an .platform/applications.yaml file
Article Content
Microservices in the cloud, part two Source
Microservices in the cloud, part one Source
Multiple Applications Source
Configure multi-applications with .platform/applications.yaml Source

Access to managed services Anchor to this heading

Platform.sh provides managed services such as databases, cache and search engines. However, you can use a database or any services such as a transition process, just be aware of the firewall.

When applications need to access a service, it is important to include the relationships key. By default an application may not talk to any other container without a relationship explicitly allowing access.

To connect to a service from your deployed application, you need to pass the relationships information into your application’s configuration. The way to do so varies with the application. The most common mechanisms are listed below.

Overwrite Anchor to this heading

If you are using a framework that follows the Twelve-Factor App methodology, particularly the third point, you can configure the application directly from environment variables. Examples of such frameworks include Spring, Eclipse MicroProfile Config, Quarkus, and Micronauts.

Service credentials are available within the PLATFORM_RELATIONSHIPS environment variable. This variable is a base64-encoded JSON object with keys of the relationship name and values of arrays of relationship endpoint definitions.

Platform.sh supports the jq tool, which allows to extract information from this JSON.

export DB_HOST=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host"`
Article Source
Spring Data MongoDB Source
Jakarta EE/MicroProfile Config Source
Spring Data JPA Source
Payara JPA Source

To reduce the number of lines in the application file and to make it cleaner, you have the option to move the variable environment to another file: a .environment file.

E.g.:

export DB_HOST=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host"`
export DB_PASSWORD=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].password"`
export DB_USER=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].username"`
export DB_DATABASE=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].path"`
export JDBC=jdbc:postgresql://${HOST}/${DATABASE}
export JAVA_MEMORY=-Xmx$(jq .info.limits.memory /run/config.json)m
export JAVA_OPTS="$JAVA_MEMORY -XX:+ExitOnOutOfMemoryError"

This .environment can interact to each application file. E.g.:

name: app
type: "java:11"
disk: 1024
hooks:
    build: ./mvnw package -DskipTests -Dquarkus.package.uber-jar=true
relationships:
    database: "db:postgresql"
web:
    commands:
        start: java -jar $JAVA_OPTS $CREDENTIAL -Dquarkus.http.port=$PORT jarfile.jar

Using Java Config Reader Anchor to this heading

If your framework doesn’t support configuration via environment variables, use the Config Reader. This library provides a streamlined way to interact with a Platform.sh environment. It offers utility methods to access routes and relationships more cleanly than reading the raw environment variables yourself. See the maven dependency.

import Config;

Config config = new Config();
MySQL database = config.getCredential("database", MySQL::new);
DataSource dataSource = database.get();

Is this page helpful?