Get the right installer
Forge publishes its builds at files.minecraftforge.net, one page per Minecraft version. Two things on that page matter and one does not.
Each Minecraft version has a Latest build and a Recommended build, listed side by side at the top with their dates. Latest carries the newest changes; Recommended is the one Forge stand behind for that version. Under them is a full list of every build with its own Installer, Changelog and Mdk download.
The version string is the thing to read carefully. It pairs a Minecraft version with a Forge build, written as one label, so a single number identifies both halves and there is no guessing about which Forge goes with which Minecraft. Copy that whole label out of your modpack's description and match it exactly.
Ignore Mdk entirely. That is the Mod Developer Kit, a Gradle workspace for writing mods, and it is no use for running a server. You want Installer.
Install the server
The installer is a jar, and it has a command-line mode. Forge's own installer source lists the actions it accepts: --installServer to install a server to a given directory, --installClient for the client files, --extract, and --makeOffline. Alongside those it takes --offline, --debug, --mirror and --help. So the whole install is:
java -jar forge-<version>-installer.jar --installServer ./myserver
Three behaviours are worth knowing before they confuse you. Run the installer with no arguments in a terminal with no graphical display and it prints "No options found. Try running with --help for a list of options." rather than doing anything. It refuses to run from a folder path containing an exclamation mark, which is a Java limitation rather than a Forge choice. And it checks the certificates of files.minecraftforge.net and Mojang's launcher metadata host before it starts; if that check fails it tells you the failure typically means an outdated Java, which is the right thing to fix first.
It also writes a log beside itself as it goes. When an install fails, read that before you read a forum.
On the Java version, Forge's own documentation for the current branch names Java 21 and a 64-bit Java runtime, and says the project recommends and officially supports Eclipse Temurin. Older Minecraft versions pair with older Java versions, so a pack from a few years ago may want an older runtime rather than the newest one you happen to have.
The first start, and the stop that looks like a crash
Start the server and it will shut down immediately. That is not a failure. Forge document it plainly: the server shuts down at once on the first run, and you have to accept the Minecraft end user licence agreement by editing the eula.txt file that appeared in the run directory. Change the line to say the licence is accepted, save, start it again.
Once it is up you can reach it from a client on the same machine with a direct connect to localhost, which is the fastest way to confirm the server works before you touch a router.
Dropping in the modpack
A modpack for servers ships as a server pack: a folder of jars plus, usually, config files. Forge's documentation is short on this because the answer is short. Mods go in the mods folder of a Forge-enabled Minecraft setup. Copy the pack's mod jars in there, copy any config folder the pack ships alongside them, and start the server.
What matters is which jars go in. Three rules, in the order they bite:
The Forge build has to match the pack. Not "the same Minecraft version" but the same paired version string from the files page. A pack built against one Forge build and run on another will often start and then fail somewhere specific and confusing.
Client and server run different sets, and that is normal. Forge's own documentation says a mod file can declare that it should be skipped on a dedicated server, and Forge then sets the version-check behaviour correctly for it, so a well-behaved client-only mod does not need to be on the server at all. Their guidance to mod authors is to always test in a dedicated server environment, including client-only mods, precisely because those should do nothing when loaded on the server. In practice: use the pack's own server pack rather than copying your client's mods folder wholesale, and if the pack does not ship one, expect to remove the client-only mods by hand and to find out which they are from the pack's own notes.
Everything else has to be identical. Players whose mods differ from the server's will be turned away at the door. That is the whole reason packs exist as a fixed list.
Where worlds live
The server keeps its world in a folder named by the level-name setting in server.properties, which defaults to world. That setting is both the world's name and its directory path: if a valid world already exists at that path the server loads it, and if not, the server generates a new one there and creates the directories it needs. It accepts an absolute path as well as one relative to the working directory, which is how people keep worlds outside the install.
That is the practical backup rule. The world folder is the thing that cannot be re-downloaded; the mods and the Forge install can. Copy the world folder with the server stopped, and copy it before every pack update, because a pack update can change how the world's chunks are read.
While you are in server.properties: server-port defaults to 25565 and is TCP, and it has to be forwarded if the server sits behind a home router. If you have not done that before, we wrote a separate page on port forwarding for game servers.
Updating a pack
A pack update usually means a new Forge build as well as new jars, and a new Forge build means running the installer again into a clean directory. The sequence that avoids grief: stop the server, copy the world folder somewhere safe, install the new Forge build fresh, drop in the new server pack's mods and configs, put the world folder back, start it, and only then tell your players to update their side.
Self-hosting or renting
If you already have a machine that stays on, running a Forge server at home costs nothing but attention, and everything stays in your hands. For a pack played by a handful of friends, that is frequently the right answer.
The honest costs are these. The machine has to be awake whenever anyone wants to play, which usually rules out the computer you play on. Many home connections cannot accept incoming connections at all, and no amount of careful forwarding fixes that. Modded servers ask more of a machine than vanilla ones. And every pack update is a small project: a new install, a world you must not lose, and a version string every player has to match.
Renting moves that work rather than removing it. The pack, the config, the version you sit on and the backups you actually keep are still your decisions.
Where RadarHost fits
RadarHost rents Minecraft servers hosted in Beauharnois, Quebec, Canada, and Forge is one of the three worlds we run alongside Paper and Vanilla. There are three plans, Standard, Premium and Diamond, priced in Canadian dollars, with no setup fee and cancel any time. Renting changes who keeps the machine on; the pack, the Forge build and the world above are still yours to choose. After payment, our team reviews the order and emails setup details or next steps within 24 hours. Current plans and prices are on the Minecraft availability page.