Install it, point it at a server,
and see what it will not do

Requirements

Linux is the supported platform. Everything here follows from that.

.NET 10 runtime

x86-64 or aarch64. On Arch, dotnet-runtime-10.0 from the official repositories. Published builds are self-contained, so you can also run the binary with no runtime installed at all.

The launcher

Grab the latest tarball from the downloads section. Both linux-x64 and linux-arm64 are published. Latest release: v0.2.0

A Wayland or X11 session

On Wayland the launcher runs under XWayland, because Avalonia's backend targets X11. There is no native Wayland backend in this build.

Optional: libsecret

Account tokens go to the system keyring through secret-tool. Without it the launcher falls back to a machine-bound file store and says so on the Accounts page. It never writes tokens somewhere without telling you.

Install

One archive. There is no installer and nothing to configure first.

# 1. unpack it anywhere you can write to
$ tar xzf viblauncher-0.2.0-linux-x64.tar.gz

# 2. make it executable and run it
$ chmod +x viblauncher
$ ./viblauncher

From pacman

Arch packages are built from the same tag and published to a pacman repository. Add it once, then updates arrive with the rest of the system.

printf '[viblauncher]\nServer = https://vib-studios.github.io/viblauncher/repo/$arch\n' \
  | sudo tee /etc/pacman.d/viblauncher.conf
$ sudo pacman -Sy
$ sudo pacman -S viblauncher

The Arch package is framework-dependent and depends on dotnet-runtime-10.0. The tarball above is self-contained and needs no runtime installed — on any other Linux, take the tarball.

From source

The build needs the .NET 10 SDK. Clone, build, run — no editor and no native toolchain beyond what the SDK pulls in.

git clone https://github.com/vib-studios/viblauncher
$ dotnet build -c Release
$ dotnet run --project src/VibLauncher.App

Instances

An instance is a Minecraft client the launcher installs and starts. Several can coexist; a second instance on a version already installed costs almost nothing, because the client jar, libraries and assets are shared.

An instance is a client. A server is a separate concept, covered under local servers. They never share a directory.

Nothing from Minecraft is bundled. Client jars, libraries and assets are fetched from Mojang's own servers, so a version the launcher does not know about will not resolve.

Accounts

Offline accounts work immediately. Microsoft sign-in needs a client id supplied by whoever ships the build.

The full auth chain is implemented and works once a client id is configured. An unsigned build will tell you it cannot sign in rather than failing at the launcher window.

Mods

Search Modrinth, filtered by the instance's Minecraft version and loader before the query leaves the launcher, so every result shown is installable.

The specific file is checked again at install time, and a mismatch is refused with both sides named rather than installed and left to crash:

"Sodium 0.5.8" cannot be installed into "Fabric Survival".

That release supports Minecraft 1.20.1 on fabric. This instance is
Minecraft 1.21.8 on Fabric. Pick a different release, or change the
instance's version.

Fabric and Quilt are complete. Disabling a mod renames it to .jar.disabled, which every loader ignores — nothing is deleted, so enabling it again is a rename back.

Local servers

The launcher can run a vib-MC server on this machine, as a child process with its own folder per server. It is never run inside the launcher, so a server crash cannot take the launcher down.

Server jars come from the vib-MC project's GitHub releases rather than from scraping a web page. The server needs a Java runtime of its own — the launcher's .NET runtime is not Java. See the server requirements.

stdout and stderr feed the console view and a per-run log file; typed commands go to stdin. A crash is reported with its exit code and a route to the log, and the launcher never auto-restarts.

Ports are checked before a start and a conflict offers the next free port. The port is never changed automatically: a server that silently moves is a server nobody can connect to. An update replaces only the jar — worlds, player data, plugins and server.properties are never touched, and a backup is taken first.

What it will not do

Stated plainly rather than hidden behind a disabled button.

• Forge and NeoForge cannot be installed. Versions are listed; the install step is not implemented. Fabric and Quilt are complete.
• CurseForge is not implemented. The provider abstraction is there for it. CurseForge packs cannot be imported either — that needs the CurseForge API to resolve mods, and the import says so instead of failing quietly.
• No managed Java downloads. The launcher finds installed runtimes and tells you which release a version needs, but does not fetch one for you.
• Server plugin management is not implemented. Servers get a plugins/ folder and a button to open it.
• Player counts and server memory use are not shown, because nothing available reports them reliably. The fields show what is actually known rather than invented numbers.
• Windows is untested. It builds from the same sources and the shared logic is covered by tests, but nobody on the project runs Windows, so nothing on it is verified by hand.

Report a bug

Opens a prefilled issue on GitHub in a new tab.