11 min read

How to Get Players on a Brand-New Minecraft Server

A week-one playbook for filling a new Minecraft server — listing, voting, Discord seeding, events, and escaping the empty-server death spiral.

How to Get Players on a Brand-New Minecraft Server

The hardest part of running a new server isn't the setup, it's the first twenty concurrent players. Everything before that is plugins and config files you can fix at your own pace. Once you're live, you're up against a simple, ugly problem: an empty server scares off the exact people who showed up to play. Someone connects, sees 0 online and leaves within a minute, and the next person sees the same 0 and does the same thing, so nobody ever stays long enough to make the place feel alive. That's the empty-server death spiral, and beating it in week one is most of the job.

The good news is that a new server isn't starting from behind on the rankings here. The board is ordered by votes earned in the current calendar month, and it resets to zero for everyone when the month rolls over, so you're competing on the same clean slate as servers that have been around for years. The rankings guide covers the mechanics.

First, kill the empty-server death spiral

The thing that makes the spiral so stubborn is that emptiness feeds on itself. So the goal of week one isn't "lots of players" — it's "never zero" during the hours you actually care about. You don't need a crowd, you need to not be a ghost town when someone walks in.

The way you do that on a tiny player base is to concentrate instead of scatter. Pick a daily window of two or three hours that lines up with where most of your people live, and ask your initial group to all be online together in that window. Ten players spread randomly across the day reads as empty all day. The same ten players overlapping for two hours reads as a server worth staying on.

That initial group is worth recruiting deliberately. Ten to fifteen friends and Discord contacts who genuinely agree to be active and chatty for the first couple of weeks is a real nucleus, and it's usually the difference between a server that clicks and one that quietly dies. While you're at it, make the spawn feel inhabited even at low counts — clear signage, a rules board, a "start here" path, and a few visible builds so a lone visitor has something to do and a reason to wait around for the next person to show up.

One more thing worth saying out loud: a new server bounces around for a while before it settles. That's normal. Surviving week one is about being consistent, not about a huge launch-day spike that empties out by Wednesday.

Get listed where players actually look

Listing your server is the single highest-leverage move you'll make this week, because directories are where people go specifically to find new servers to try. Add yours from the owner dashboard, and treat the listing like something a player skims in two seconds, because that's what happens. Lead the first line with your gamemode and what makes you different, then say which versions you support, your region, and whether you're Java, Bedrock, or both.

Make sure the listing lands you next to the right players. A survival server belongs alongside the ranked survival list; a skyblock server wants to be on the skyblock list. People browse by category, so being in the right one is half of being found.

Keep your supported version accurate, too. Players filter by version, and if yours is wrong they'll skip you before they ever try to connect — point at 26.2 for the current release or 26.1 for the prior one, using the dotted format. Beyond the directory, post the same clear pitch in community spaces players already hang out in, like relevant subreddits and Discord server-advertising channels, with the exact join address spelled out. Get a single character wrong in that address and it'll still look right to you, but nobody will be able to connect.

Turn on voting from day one

Because the board resets monthly, early and consistent votes move a new server up fast — there's no all-time total sitting above you that you have to grind past. So you want voting working from the moment you launch, not bolted on three weeks later. Again, the rankings guide has the full picture.

The piece that makes votes flow back to your server is NuVotifier, the maintained successor to the original Votifier. Drop the .jar into your /plugins folder and restart the server to generate its config.yml, and it opens a dedicated port to listen for vote notifications from listing sites. NuVotifier sets that port to 8192 by default — leave it there unless something else on the box is already using it — and copy that exact port plus the token out of config.yml into the listing site's Votifier settings so votes are delivered securely.

Here's the part that trips up almost every new owner: NuVotifier only receives votes. It does not hand out rewards by itself. It fires a vote event on your server, and you need a separate listener plugin — VotingPlugin or SuperbVote are the common picks — to actually do something when that event happens. Install both, or players will vote and see nothing change in-game. There's a full walkthrough in the Votifier setup guide if you get stuck.

Building a daily voting habit is then just a matter of asking. Thank people, remind them voting is free and repeats every day, and keep any in-game acknowledgement light. Votes are how the community lifts your rank.

Seed and run a Discord

A Discord is the off-server home base where your founding crew stays connected during all the hours your in-game count would otherwise read zero. The server can be empty at 3pm and the chat can still be busy, which is what holds people between peak windows.

Stand it up before or on launch day even if it has no members yet. Channels for announcements, rules, general chat, support, and a "who's online / let's play now" channel to coordinate that daily peak are plenty to start. The point is to coordinate, not just broadcast — a quick "event in 10 minutes" or "we need two more for the build" ping is what turns a quiet evening into a full lobby.

Seed the conversation on purpose, too. Your founding members chatting, asking questions, and dropping screenshots is what makes the space feel alive to a newcomer, and a space that feels alive is what makes them stick around. Keep pulling people back with low-effort hooks: event recaps, player builds, little milestones. Pin your join address and listing link somewhere obvious so members can re-share it without hunting for it.

Run events that give people a reason to log in

Events are the cleanest fix for the cold-start problem because they manufacture a moment when everyone's online at once. You're breaking the spiral on purpose, on a schedule.

For a brand-new server, the event that earns its keep is whatever pulls your whole founding crew into the same place during your peak window — a build competition or a shared community project usually does that best, because everyone can join regardless of how far along they are. Save the PvP tournaments, KOTH, island races, or prison grinds for once you've got the numbers to fill them; on day three they tend to leave half the server standing around. Announce a fixed time in Discord and on your spawn signage, run it inside your peak window, and keep every reward purely in-game and gameplay-based — cosmetics, titles, bragging rights.

Make it recurring so people can plan around it. A weekly anchor event gives newcomers a predictable reason to come back, and that's the mechanism that turns week-one curiosity into month-two regulars. After it wraps, grab a few screenshots and clips and post them back to Discord and your socials, so the event keeps recruiting for you even after it's over.

Keep first impressions perfect

All of the above is wasted if people join to lag or hit a server that's down half the time. A fast, stable server is the floor everything else stands on, so size your hardware honestly. For a vanilla SMP at around 10–20 players you generally want about 4–6 GB of RAM; plugin-heavy setups lean toward 6–8 GB, and you can add roughly 0.5–1 GB per 10–20 plugins, scaling with how heavy they are.

Two cautions are worth stating plainly. Don't allocate more than about 75% of the machine's total RAM, since Java's garbage collection gets worse on very large heaps. And size for concurrent players, not max slots — a 50-slot server with 15 people on it needs RAM for 15, not 50.

Uptime shows on your listing, and it reads as a trust signal whether you mean it to or not. Reliable hosting plus a sensible auto-restart keeps a grey, offline ping from quietly costing you the players you just worked to recruit. Moderation matters just as much early on, because week one sets the culture. Answer questions fast, enforce clear rules, and you turn first-time visitors into the regulars who vote for you month after month.

Optional: open the door to Bedrock players

Letting Bedrock players onto a Java server widens your pool, and a wider pool helps a new server hit critical mass sooner. The way it works is Geyser, a proxy that translates Bedrock network traffic into Java in real time, listening on a separate UDP port from your Java TCP port. Pair it with Floodgate, which handles login so Bedrock players can join without owning a Java account — without Floodgate, they'd each need one.

Check that it fits your stack before committing. Geyser runs on common server software including Paper, Spigot, Fabric, and NeoForge, plus proxies like Velocity and BungeeCord. The honest trade-off is performance: the translation layer adds roughly 5–10% overhead, so factor that into your RAM and tuning and test it before you launch, not after. If you do go crossplay, list yourself on the crossplay category and make your Bedrock port clear so those players can actually find their way in.

Your realistic week-one checklist

Here's the whole thing as a do-this-now list:

  1. List the server accurately, in the right category, with the correct version.
  2. Set up NuVotifier plus a listener plugin like VotingPlugin or SuperbVote.
  3. Stand up a Discord, even empty, with an announcements and a "who's online" channel.
  4. Recruit 10–15 active founders who'll genuinely show up.
  5. Pick a daily peak window and get everyone overlapping in it.
  6. Schedule a first event for that window.
  7. Confirm your RAM and uptime are solid before you market anything.

Work that list, then watch where you land against the survival list or whichever category fits you, and keep the loop running into week two and the week after.

FAQ

How many players do I need to recruit before launch?

Aim for a small, committed founding crew of about 10–15 friends or Discord contacts who agree to be genuinely active for the first couple of weeks. The number matters less than the overlap: if even five of them are online together during your daily peak window, anyone who drops in sees a living server instead of an empty one, which is what breaks the death spiral.

What's the fastest way to break the spiral if I'm already live and empty?

Stop trying to be online all day and collapse everyone into one window. Message your founders, agree on a single two-hour block tonight, and get five or six people in at the same time so the count is never zero while anyone's likely to look. Then schedule that same block daily for the next two weeks. One reliably-busy window beats a server that's technically up sixteen hours a day but shows 0 every time someone checks.

Does NuVotifier give players their vote rewards automatically?

No, and this trips up a lot of new owners. NuVotifier only receives vote notifications from listing sites and fires a vote event on your server; it doesn't hand out anything by itself. You need a separate listener plugin such as VotingPlugin or SuperbVote to respond to that event. Install both, or players will vote and see nothing happen in-game.

Do I have to support crossplay to get players?

No, it's optional. Plenty of successful new servers are Java-only or Bedrock-only. Crossplay — via Geyser, plus Floodgate so Bedrock players can join without a Java account — simply widens your potential audience, which can help a new server reach critical mass faster. Just weigh the roughly 5–10% performance overhead from the translation layer against your hosting headroom.