
Leading the Way: Payara Platform Community 7 Beta Now Fully Jakarta EE 11 Certified
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
We work hard to make Payara Server robust, reliable, and innovative so that it’s perfect for production deployments. But we never forget about the users and developers. For them, we target flexibility and ease of use in every new feature we add and every tool in the ecosystem we maintain. Our Payara Docker images are an example of it and we’re happy about the positive feedback from the user community we receive, as well as the constructive suggestions that help us improve user experience in the future.
Learn How to Use the Payara Platform with Docker in our User Guides:
{{cta(‘faa4a554-5e7f-45a3-b808-23d25d47c7db’,’justifycenter’)}}
{{cta(‘d6b8c40d-dda1-4d52-a511-328ac193ec85′,’justifycenter’)}}
We’ve designed the Payara Docker images so that the image can be used from scratch and also everything can be easily configured without building a custom Docker image:
While most of the above aims at ease of use, the last point is especially important to give users flexibility. The startup sequence of the Docker container is split into separate scripts, which you may reuse if you need complete control over how the container is started.
The Payara Docker image uses Tini in the entrypoint, which manages all the child processes properly and guarantees that the Payara Server process runs seamlessly as the main docker process.
The default CMD
argument runs the bin/entrypoint.sh
script, which in turn runs the following:
${SCRIPT_DIR}/init_*.sh
scripts that you may provide for custom use as waiting or initializing during startup, before Payara Server starts. The docker image already contains one such script, init_1_generate_deploy_commands.sh, which generates a command file with commands to deploy applications in the deployment directory${SCRIPT_DIR}/startInForeground.sh
. This script starts the server in the foreground, after all init scripts are finished, in a manner that allows the Payara instance to be controlled by the docker host. If you need to modify the command file script, e.g. to add a datasource during server start-up, you can create a custom command file and append the generated command file to it. Since version 5.184, it’s no longer necessary to modify the entrypoint. Instead, it’s enough just to create a custom $POSTBOOT_COMMANDS file:
FROM payara/server-full:5.201
COPY application.war $DEPLOY_DIR
RUN echo 'create-jdbc-connection-pool --datasourceclassname org.postgresql.ds.PGConnectionPoolDataSource --restype javax.sql.ConnectionPoolDataSource --property user=postgres:password=password:DatabaseName=fin_dev:ServerName=${ENV=HOST_IP}:port=5432 fing-pool'
> $POSTBOOT_COMMANDS
The above will:
As in the above example, you can use Payara Server variable references in the POSTBOOT_COMMANDS file and Payara Server will replace them with the value of an environment variable or system property before executing the commands.
We can further customize the startup sequence, e.g. to change the order of commands in the postboot command file. To do that, we can create an init script create_conn_pool.sh which will be executed after the deploy commands are generated:
echo 'create-jdbc-connection-pool --datasourceclassname org.postgresql.ds.PGConnectionPoolDataSource --restype javax.sql.ConnectionPoolDataSource --property user=postgres:password=password:DatabaseName=fin_dev:ServerName=${ENV=HOST_IP}:port=5432 fing-pool'
>> $POSTBOOT_COMMANDS
We’ll copy the script to the Docker image into the “bin” directory with a name that starts with “init_” and so that the name is ordered alphanumerically after the script init_1_generate_deploy_commands.sh. A good name would be init_2_create_conn_pool.sh.
Having a file create_conn_pool.sh with the custom asadmin commands, the Dockerfile would then look like this:
FROM payara/server-full
COPY application.war $DEPLOY_DIR
COPY create_conn_pool.sh ${SCRIPT_DIR}/init_2_create_conn_pool.sh
This will:
You can create even more complex scripts that completely rewrite the postboot command file or even apply configuration changes which aren’t possible using boot command files.
Share:
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
Managing Payara Server Just Got Smarter Imagine managing your Jakarta EE applications not just with Maven goals, but by […]
Welcome aboard the August 2025 issue of The Payara Monthly Catch! With summer in full swing, things may have felt […]
I want to create a docker payara image based on Redhat. Will I have to just completely rebuild my own Dockerfile, or can I use bits of yours?
Hi, our docker images don’t use anything specific to Ubuntu so if you take the Dockerfile from our github repository and change the base image to RedHat all should work.
If you’re OK with using Cent OS, you may save time and use docker images provided by the Docklands project here: https://github.com/AdamBien/docklands/blob/master/payara5/Dockerfile. Those images are regularly updated with the latest changes in our official Dockerfile.
Hi Ondro Mihalyi. Good Afternoon.
I’m trying to customize the startup sequence to run asadmin commands to configure Handles.
I’ve tried
“echo “create-jvm-options ‘-Ddataverse.handlenet.admcredfile=/hs/svr_1/admpriv.bin'” >> ${DV_POSTBOOT}
echo “create-jvm-options ‘-Ddataverse.handlenet.index=300′” >> ${DV_POSTBOOT}
”
but I had no success… Could you help me, please?
echo “create-jvm-options ‘-Ddataverse.handlenet.admcredfile=/hs/svr_1/admpriv.bin'” >> ${DV_POSTBOOT}
echo “create-jvm-options ‘-Ddataverse.handlenet.index=300′” >> ${DV_POSTBOOT}
Hi Alexandre, the post boot instructions are applied on a running instance of Payara Server when it’s already too late to set the JVM options. You need to set the JVM options before.
One option is to run the asadmin CLI tool as here (first start the server, then run your commands, then stop the server): https://github.com/payara/Payara/blob/payara-server-5.2021.1/appserver/extras/docker-images/server-full/src/main/docker/Dockerfile#L23, for example:
RUN ${PAYARA_DIR}/bin/asadmin –user=${ADMIN_USER} –passwordfile=${PASSWORD_FILE} start-domain ${DOMAIN_NAME}
&& ${PAYARA_DIR}/bin/asadmin –user=${ADMIN_USER} –passwordfile=${PASSWORD_FILE} create-jvm-options ‘-Ddataverse.handlenet.admcredfile=/hs/svr_1/admpriv.bin’
&& ${PAYARA_DIR}/bin/asadmin –user=${ADMIN_USER} –passwordfile=${PASSWORD_FILE} stop-domain ${DOMAIN_NAME}
If you need to generate the configuration dynamically when the Docker container starts (e.g. you want to make it configurable using environment variables), then you can provide a script in the ${SCRIPT_DIR}. This script would execute the same as above, but during container execution, not during image build time. This is documented here: https://docs.payara.fish/community/docs/5.2021.1/documentation/ecosystem/docker-server-usage.html#_configuration. For example:
COPY init_jvm_options.sh ${SCRIPT_DIR}/init_jvm_options.sh
Hi Ondro,
We currently have a python script which does a lot of setup. Instead of rewriting this as a bash/asadmin script, is there any way of running a python after booting? I’ve tried creating a ${SCRIPT_DIR}/init_run_python_script.sh but i can’t see any output.
Thanks
Alex
Hi Alex, you can execute anything within your init_run_python_script.sh, it gets executed before Payara Server is started. Note that Python isn’t installed in the Docker image, so make sure you install it before you attempt to write it. If you need to configure Payara Server with that script, you’ll first need to start Payara Server with asadmin start-domain command, execute your python script, and then stop the server, all within your init script.
The init scripts run when you start the Docker container and before Payara Server is started. However, maybe it’s better to apply the configuration earlier, when the Docker image is built, and have the configuration in place already when you start the Docker container. The container would start faster, and if you use Multistage build (https://docs.docker.com/develop/develop-images/multistage-build/), you can temporarily install Python, run the configuration scripts, and avoid having Python installed in the resulting Docker image, where it would just take space.