Your Question is really too broad for this web site. And you do not provide specifics on which to make a particular recommendation. So I'll be briefly cover some possibilities.
Java Applet was the old way to run a Java app within a web browser. Indeed the original purpose of Java was applets. But the connection between Java and the web browsers proved to be flawed in many ways including notorious security vulnerabilities. Similarly, running Adobe Flash in the browser proved unsafe and unworkable. Java Applet technology is now being deprecated by both Oracle and the browser makers, as is Flash.
Java Web Start
Java Web Start is a framework for distributing your app conveniently to the user via web browser. The app actually downloads to the user’s machine to be run locally, outside of the web browser. This is a good way to distribute apps with a user interface based on JavaFX, Swing, or Standard Widget Toolkit (SWT). Java itself is designed for security. This concern for security includes putting apps deployed with Java Web Start in a “sandbox” to limit the app’s access to the user’s computer’s resources without additional permissions extended by the user.
You mention JavaFX in your Question. This confuses me as you also state the app is command-line driven. If you actually have written a JavaFX interface app, then Java Web Start might be the avenue to explore. However, you also mention a database and running on your server, in which case you should read on to learn about servlets.
Java Servlet technology is what has driven much of the Web for many years now. You can write very small apps (servlet) that are automatically invoked when a user’s web browser makes a request to your web server. Your servlet app dynamically generates the text of the HTML for a web page to be delivered back to the web browser. You deploy your servlet in a servlet container on your server computer. That container handles all the work of interacting with the web browser, accepting an incoming request, invoking your servlet, and returning your generated HTML back to the web browser. You servlet app need not do any of that “plumbing”.
You can choose among a couple dozen Servlet containers. Pick the lightest, simplest container laden with the fewest libraries/technologies that happen to meet your needs.
- If you only need the Java Servlet and maybe JavaServer Pages technologies, choose a simpler lighter container such as Apache Tomcat or Eclipse Jetty.
- If you make use of additional Java technologies, you may be able to add libraries to Tomcat/Jetty, or you can adopt a product bundling those libraries in complying with the Java EE Web Profile, such as Apache TomEE.
- If you make use of even more Java technologies, you may want to move up to the still bigger and heavier products that comply with the full Java EE edition.
Caveat: Java Servlet technology is inherently multi-threaded. You must learn about concurrency to avoid terrible conflicts in the operation of your app.
For a simple app, you could write your own servlet by hand. For a more complicated app, you will want to leverage a framework for generating the content. There are many such frameworks from which you may choose.
I have built a few Vaadin apps, deployed on Apache Tomcat, with Java SE 8, on macOS, storing data in the enterprise-quality Postgres database.
Try the Vaadin Grid demo, the QuickTickets Dashboard example app, the Sampler, and the older Reindeer Demo.
Vaadin works with all three common IDEs: IntelliJ, NetBeans, and Eclipse. Vaadin is now entirely Maven-driven. So you may not need the formerly common Vaadin plugin available in an edition for each IDE. At least with IntelliJ and NetBeans (and maybe Eclipse - not sure), you can just use pure Maven without any Vaadin-specific plugin. The Vaadin company provides a pair of Maven archetypes from which you can build your app: a single module for learning and possibly deploying, and a multi-module for when you have more experience (or you already are a multi-module Maven maven).
I have used all three IDEs for Vaadin work (long story, don't ask). I have found all of them to be extremely powerful and flexible as well as quite awkwardly-designed and clumsy-to-use. So expect a learning curve in any case. IntelliJ Ultimate is becoming my favorite, but any of the three can get the job done. Maven itself is a challenge to learn and master, but at least that learning will be useful in most all your Java work, not just Vaadin.