|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Rocket.chat||37,122||2||19 hours ago||5||August 18, 2022||2,983||other||TypeScript|
|The communications platform that puts data protection first.|
|Argo Cd||14,178||54||19 hours ago||334||July 31, 2023||3,004||apache-2.0||Go|
|Declarative continuous deployment for Kubernetes.|
|Caprover||11,007||7 days ago||107||other||TypeScript|
|Scalable PaaS (automated Docker+nginx) - aka Heroku on Steroids|
|Dagger||9,053||2||19 hours ago||81||September 13, 2022||404||apache-2.0||Go|
|A programmable CI/CD engine that runs your pipelines in containers|
|Aws Sam Cli||6,371||31||12||19 hours ago||168||July 27, 2023||386||apache-2.0||Python|
|CLI tool to build, test, debug, and deploy Serverless applications using AWS SAM|
|Ko||6,343||43||a day ago||164||June 20, 2023||68||apache-2.0||Go|
|Build and deploy Go applications|
|Openwhisk||6,163||20 hours ago||388||apache-2.0||Scala|
|Apache OpenWhisk is an open source serverless cloud platform|
|Deis||6,104||6||1||4 years ago||68||January 19, 2017||4||mit||Python|
|Deis v1, the CoreOS and Docker PaaS: Your PaaS. Your Rules.|
|Fate||5,200||1||9 days ago||30||April 18, 2022||786||apache-2.0||Python|
|An Industrial Grade Federated Learning Framework|
|Orchest||3,876||4 months ago||19||December 13, 2022||125||apache-2.0||TypeScript|
|Build data pipelines, the easy way 🛠️|
This is an example Dockerfile with WildFly application server.
WildFly publishes images to run the application server with different JDK versions. The tag of the image identifies the version of WildFly as well as the JDK version in the images.
For each release of WildFly (e.g.
28.0.0.Final), there are fixed tags for each supported JDK version:
There are also floating tags available to pull the latest release of WildFly on the various JDK:
Finally, there is the
latest tag that pull the latest release of WildFly on the latest LTS JDK version:
This floating tag may correspond to a different JDK version in future releases of WildFly images.
Instead of using the
latest tag, we recommend to use the floating tag with the JDK version mention to guarantee the use of the same JDK version across WildFly releases (e.g.
To boot in standalone mode
docker run -it quay.io/wildfly/wildfly
To boot in standalone mode with admin console available remotely
docker run -p 8080:8080 -p 9990:9990 -it quay.io/wildfly/wildfly /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0
To boot in domain mode
docker run -it quay.io/wildfly/wildfly /opt/jboss/wildfly/bin/domain.sh -b 0.0.0.0 -bmanagement 0.0.0.0
With the WildFly server you can deploy your application in multiple ways:
The most popular way of deploying an application is using the deployment scanner. In WildFly this method is enabled by default and the only thing you need to do is to place your application inside of the
deployments/ directory. It can be
/opt/jboss/wildfly/domain/deployments/ depending on which mode you choose (standalone is default in the
jboss/wildfly image -- see above).
The simplest and cleanest way to deploy an application to WildFly running in a container started from the
quay.io/wildfly/wildfly image is to use the deployment scanner method mentioned above.
To do this you just need to extend the
quay.io/wildfly/wildfly image by creating a new one. Place your application inside the
deployments/ directory with the
ADD command (but make sure to include the trailing slash on the deployment folder path, more info). You can also do the changes to the configuration (if any) as additional steps (
A simple example was prepared to show how to do it, but the steps are following:
Dockerfile with following content:
FROM quay.io/wildfly/wildfly ADD your-awesome-app.war /opt/jboss/wildfly/standalone/deployments/
your-awesome-app.war file in the same directory as your
Run the build with
docker build --tag=wildfly-app .
Run the container with
docker run -it wildfly-app. Application will be deployed on the container boot.
This way of deployment is great because of a few things:
Logging can be done in many ways. This blog post describes a lot of them.
Sometimes you need to customize the application server configuration. There are many ways to do it and this blog post tries to summarize it.
To be able to create a management user to access the administration console create a Dockerfile with the following content
FROM quay.io/wildfly/wildfly RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#70365 --silent CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
Then you can build the image:
docker build --tag=jboss/wildfly-admin .
Or for JDK 11:
docker build --build-arg dist=centos7 --build-arg jdk=11 --tag=jboss/wildfly-admin .
Or for JDK 20:
docker build --build-arg dist=ubi9-minimal --build-arg jdk=20 --tag=jboss/wildfly-admin .
docker run -it jboss/wildfly-admin
Administration console will be available on the port
9990 of the container.
You don't need to do this on your own, because we prepared a trusted build for this repository, but if you really want:
docker build --rm=true --tag=jboss/wildfly .
This image extends the
eclipse-temurin JDK. Starting with JDK 20, this base OS used is
ubi9-minimal. Earlier versions, including the LTS JDK 11 and JDK 17, are based on
centos7. A UBI 9 image to validate the build arguments provided.
This image installs the wildfly server and sets up the JBoss environment similar to
jboss/base image. Please refer to the README.md for selected images and more info.
The server is run as the
jboss user which has the uid/gid set to
WildFly is installed in the
The source is available on GitHub.
Please report any issues or file RFEs on GitHub.