Java on Falix

The Java application runs one runnable jar. Build a fat jar locally (or with a Git post-deploy step), upload it, and start — here's how to package it so it runs the first time.

The Java application on Falix has exactly one job: it runs a single jar. When you press Start, it executes the equivalent of java -jar app.jar in your server folder — and that's the whole model. Nothing compiles on the server, so the trick to Java hosting here is packaging your project into a jar that's ready to run before it ever reaches Falix.

At a glance
You need A Falix server running the Java application; Maven or Gradle on your own computer to build a jar
Plan Any — on free it runs while your session timer has time left, premium runs 24/7
Time Twenty minutes
No server yet? Create your first app server

The one rule: a runnable jar

Falix runs the file named by the JAR FILE variable on the Settings page, which defaults to app.jar. For that to work, the jar has to be runnable: its manifest must declare a Main-Class, and — this is the part people miss — every library it depends on must be packed inside it. Falix doesn't run a build tool, so there's nothing on the server to fetch your dependencies. The jar you upload is the whole application.

A plain jar with a Main-Class is fine only if your code has no external dependencies. The moment you use a library, you need a fat jar (also called an "uber jar" or "shaded jar") that bundles those libraries inside it.

Building a fat jar

Use whichever build tool your project already has:

Build tool Plugin Command Name the output
Maven Shade mvn package <finalName>app.jar
Gradle Shadow gradle shadowJar archive name → app.jar

Naming it app.jar matches the JAR FILE variable, and either way you end up with a single self-contained app.jar in your build output folder. Test it locally first: java -jar app.jar should start your program on your own machine. If it runs there, it'll run on Falix.

Getting the jar onto the server

Path A — upload it (simplest). Open the File Manager and drag app.jar into your server folder, or connect over SFTP (the host, port, and username are shown on the SFTP page; the password is your Falix account password) and copy it up. Then press Start.

Path B — build on deploy. If you'd rather push code than upload binaries, connect your repository on the Git page and add a post-deploy command that builds the jar for you (for example mvn package). This keeps your workflow to a git push. See Build steps for how post-deploy commands work; the build path only works when your build tool is available in the deploy step, so if in doubt, the upload path above always works.

A different jar, several apps, and reinstalls

Falix runs whatever the JAR FILE variable names, so to run a different jar you just point that variable at it — no need to rename files. To run a genuinely separate app, though — a second bot, another service — give it its own Instance: an isolated application, files, and startup on the same server.

⚠️ Heads up: Unlike Node or Python, nothing on the Java server reinstalls itself. A reinstall — or switching the server to a different application — can wipe your files, app.jar included, and it won't come back on its own. Keep the jar where you can re-upload it, or use the Git build-on-deploy path so a redeploy rebuilds it.

Picking a Java version

The application defaults to a current LTS. You can switch anywhere from Java 8 to Java 25 on the Settings page (the runtime version dropdown) on any plan.

⚠️ Heads up: Choose a version at least as new as the one you compiled with — running an old runtime against a jar built with a newer JDK is the single most common Java startup failure here (see below).

What about Discord bots?

A JDA bot (the Java Discord API) is just a Java program, so it fits this application perfectly: build your bot into a fat app.jar, upload it, and start. A pure bot makes only outbound connections, so it doesn't need SERVER_PORT at all. The general setup — creating the bot, getting a token, enabling intents — is covered in Your first Discord bot.

💡 Tip: Keep your token out of the jar — have your code read it from a small file next to the jar (say token.txt, created in the File Manager) so you can rotate it without rebuilding.

No Packages page here

Unlike Node or Python, the Java application has no Packages page — dependency management is your build tool's job. You declare libraries in your pom.xml or build.gradle, and the Shade/Shadow plugin packs them into the jar. There's nothing to install on the server because everything your app needs is already inside app.jar.

When things go wrong

  • no main manifest attribute, in app.jar — your jar doesn't declare a Main-Class. You built a plain library jar, not a runnable one. Rebuild with the Shade/Shadow plugin (or set the manifest's Main-Class).
  • NoClassDefFoundError / ClassNotFoundException at runtime — a dependency isn't inside the jar. Your fat-jar plugin isn't shading the libraries in; check that mvn package / gradle shadowJar really produced the bundled jar, and that you uploaded that one.
  • UnsupportedClassVersionError — the runtime is older than the JDK you compiled with. Bump the Java version in Settings to match, or recompile targeting an older version.
  • Starts, then stops with no error — if your program's main method just runs and returns, the process exits and the server shows as stopped. That's expected for a one-shot job; a bot or server stays up because it keeps a connection open. See My app won't start.
Cheat sheet
Entry file One runnable app.jar (JAR FILE variable) with a Main-Class and every dependency shaded in
Dependencies No Packages page — bundle them into the fat jar with your build tool
Versions Java 8 to Java 25 on the Settings page (any plan)

Next steps

Was this guide helpful?