The Flare profiler for Minecraft servers

How To Use Your Own Flare Profiler

That time I brought back the Flare profiler from the dead, just for funnies

4st Jan 2026

6 min read

profilingperformance

What is Flare?

Flare is a profiling suite for Minecraft dating from the 1.16 era.
Used to be a competitor to spark and timings, where timings got deprecated and stopped receiving updates and Flare got abandoned due to the owner's new schedule and therefore lack of time.

Why bringing it back?

No particular reason.
I learned Nuxt and wanted to put my new skills to the test.
Out of a couple of ideas, Flare looked like the most complex one. And given that there was no public instances available even if the profiler itself has been open source and still remained untouched for years, it looked like a promising idea to bring it back.

Flare vs spark

There are not many reasons to use Flare nowadays compared to spark, most of its features have already been merged into spark and have been enjoyed by server owners for years.
It still has very few features that are not part of spark yet, which are also very niche and not required by everyone, therefore, more than a competitor to spark it serves as another tool for your repertoire. \

Compared to spark, Flare does not execute in the background, so you don't have to worry about two tools taking doing the same thing at the same time.
Both use the same engine and don't interfere with each other, which means starting the Flare profiler will not cause spark to stop, and the performance impact will be as negligible as spark's is.

Features

Most of the features Flare used to advertise are now (and have been) a thing in spark for years.
There's little to no reason for me to try to compete with spark using an abandoned software from the 1.16 days, while also trying to keep it compatible with the original profiler.
As such, any new feature will be something that spark doesn't cover and is possible to handle using the old engine Flare currently has.

Old features

  1. CPU and Allocation profiling. ✨
  2. Profiling modes ITIMER, CPU, ALLOC, LOCK and WALL.
  3. View server configurations.
  4. View system information.

You can get similar results with spark by using /spark profiler start --thread * --not-combined for CPU profiling and /spark profiler start --alloc --thread * --not-combined for Allocation profiling.
The only advantage Flare still holds in this regard is being able to profile both at the same time.

New features

  1. TPS and MSPT monitoring.
  2. RAM and CPU usage monitoring.
  3. Players, Entities, Block entities and Chunk monitoring.
  4. Packet sending monitoring. ✨
  5. Garbage collector monitoring. ✨
  6. Thread usage and allocation monitoring. ✨

Most of these features were already bundled in Flare but were never used due to the UI lacking a tab to display the collected data.
The only new additions are the packet and thread monitoring, which in addition to the pre-existing garbage collector monitoring, are features that spark does not display as intuitively as Flare, which shows a graph for each.

Getting started

First, identify your server software.
If you're running Pufferfish or any of its forks, flare its already bundled! No need to install anything!

In your pufferfish.yml file, look for this section and fill up the details.
You will need to provide a URL to the flare instance (the viewer) you're going to use and an authorization token:

# Configures Flare, the built-in profiler
flare:
  # Sets the server to use for profiles.
  url: "https://flare.airplane.gg"

# Options for connecting to Pufferfish/Airplane's online utilities
web-services:
  token: ""

If you're not using a pufferfish-based software, you can still use the Flare plugin made by @Toffikk.
In your /plugins/Flare/config.yml you'll find the same details, but the URL will be split into backend and frontend.
You only need to provide backend-url with the URL to the flare instance, unless stated by the flare instance you're using.

profiling:
  token: ""
  backend-url: "https://flare.airplane.gg"
  frontend-url: ""

Now, optionally, you can add the following JVM flags to your startup script to improve accuracy when profiling.
These flags are not required for Flare to work, but when async-profiler, the tool that makes both spark and Flare possible, is loaded as a library instead of an agent (way past the JVM startup), the team recommends to add them.

-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints

Once you have provided both a URL and your token, you can start profiling!
In the original Pufferfish and the Flare plugin, you can start profiling by using the command:

/flare start

In unofficial implementations of Pufferfish like Puffernot you will use the command:

/flare profiler start

No public instances available?

You might be asking: Why does it require a token compared to spark?
Flare, at least the viewer, used to be a paid product, which required a token to access.

I, with the help of @Toffikk, have built a viewer from the ground up.
The new flare-viewer is fully open source, but we have kept the token functionality, mostly as a way to keep control over your own instance without having to set up a firewall, for those that want to keep it for themselves.

Still, you're able to deploy your own instance and share it with your friends, or with the whole community!
I do not share mine, because my vps is dogshit
For this you will need two projects:

  1. flare-viewer, the web UI for Flare.
  2. Jet, the backend for the viewer.

Compared to spark, Jet would be the equivalent to bytebin, and flare-viewer to spark-viewer.

You can compile each project by following the instructions on their respective repositories.
Or you can use the provided docker images, available in the GitHub Container Registry (ghcr). You can find the compose.yml entries I use inside each repository.

As you might notice, there are two projects that, by default, will hold different paths.
This is why the Flare plugin provides a backend and frontend URLs. If you're unable to configure any sort of forwarding, you can just rely on that feature, where backend-url will be the path for Jet, and frontend-url will be the path for flare-viewer.

If you're using docker, have both projects in the same machine, and are using Caddy, you can take my configuration to make yours forward the connection, and only require to provide a single url (which will also make it compatible with the original Pufferfish).

flare.biquaternions.me {

    @jet {
        path /create /license /api/thumbnail/*
    }
    reverse_proxy @jet jet:9420

    @profiling {
        path_regexp flare_keys ^/[A-Za-z0-9_-]+/[A-Za-z0-9_-]+(/timeline)?$
    }
    reverse_proxy @profiling jet:9420

    reverse_proxy flare:3000

}

jet.biquaternions.me {
    reverse_proxy jet:9420
}

jet-live.biquaternions.me {
    reverse_proxy jet:9430
}