What you need before deploying
A Java Discord bot deploys as a single .jar file. Before touching any hosting panel, make sure you have three things: a working bot locally, a build tool configured to produce a fat jar (one file containing your code and every dependency), and your bot token stored outside your source code. If you are starting from scratch, JDA is the standard library choice; Javacord is a simpler alternative for small bots.
Step 1: Build a fat jar
Discord bot hosts run your jar with a plain java -jar command, so all dependencies must be inside it. With Maven, add the Shade plugin and run mvn package. With Gradle, apply the shadow plugin and run gradle shadowJar. Either way, the output in target/ or build/libs/ is the file you will upload — typically a few megabytes for a JDA bot.
Set your main class in the manifest (Shade's ManifestResourceTransformer or shadow's mainClassName) so the jar is directly runnable. Test locally with java -jar yourbot.jar before uploading: if it starts on your machine, it will start on the host.
Step 2: Read the token from the environment
Never hardcode your token. Read it from an environment variable so the same jar works locally and in production:
String token = System.getenv("DISCORD_TOKEN");
JDA jda = JDABuilder.createDefault(token)
.enableIntents(GatewayIntent.MESSAGE_CONTENT)
.build();On MonkeyBytes you set DISCORD_TOKEN in the panel's environment variables, exactly as described in our environment variables guide. If your token has ever appeared in source control, regenerate it in the Discord Developer Portal first — see the security best practices guide.
Step 3: Upload and pick a Java version
Create a Java server in the MonkeyBytes dashboard, then upload your fat jar via SFTP or the panel's file manager. Select the Java runtime version — 8, 11, 17 and 21 are all available. Match it to the version you compiled against: a jar built with a newer JDK will not run on an older JVM.
Point the startup configuration at your jar. A sensible start command caps JVM memory below the container allocation so the JVM never fights the container limit:
java -Xms128M -Xmx1536M -jar yourbot.jarLeaving roughly a quarter of the 2 GB allocation free for off-heap memory (threads, sockets, JIT) keeps the container comfortably inside its limit.
Step 4: Start, watch the console, iterate
Start the server and watch the live console. A healthy JDA bot logs its gateway connection and then sits quietly. The three most common first-start failures:
- UnsupportedClassVersionError: the selected Java runtime is older than the JDK you compiled with — switch the panel to the newer version.
- NoClassDefFoundError: your jar is not shaded; dependencies are missing. Rebuild as a fat jar (Step 1).
- Invalid token / 401: the environment variable is unset or stale — re-check the panel value.
For deeper debugging, our troubleshooting guide covers intents errors, permission problems, and crash loops. Updating the bot later is a two-step routine: upload the new jar over the old one, restart the server.
Why Java bots run well on fixed 2 GB
The JVM's ahead-of-time class loading and mature garbage collectors make long-running Java bots exceptionally stable: months of uptime without a restart is normal. With -Xmx tuned as above, even a JDA bot serving hundreds of servers fits comfortably in the free plan. If your bot grows beyond that, read our scaling guide for sharding strategies.
Frequently asked questions
Can I host a Java Discord bot for free?
Yes. MonkeyBytes hosts Java Discord bots free with 2 GB RAM, 2 GB SSD storage and 300% CPU. You upload a .jar file, choose a Java version (8, 11, 17 or 21), and the bot runs 24/7 with no credit card required.
Which Java version should my Discord bot use?
Use Java 21 for new JDA bots — current JDA releases target modern Java and benefit from its performance improvements. Choose 17 for broad library compatibility, and 8 or 11 only when running an older bot that has not been updated.
How do I keep dependencies inside my .jar?
Build a fat (shaded) jar so every dependency ships inside one file: use the Maven Shade plugin or the Gradle shadow plugin. The host then only needs your single .jar and a start command.