Prepare the project before opening the upload form
Decide exactly what you are publishing: a Java mod, Bedrock add-on, resource pack, modpack, map, or another supported class. The class affects accepted files, filters, and how the CurseForge app treats the project. Do not select a popular category that does not match the download.
Finish a clean release build and test it outside your development environment. For Java, launch the built JAR in a fresh instance with the declared loader, Minecraft version, and dependencies. Test a dedicated server when the mod is meant to support one. For Bedrock, import a newly packaged copy into a clean test world and verify both Behavior and Resource Pack dependencies.
Prepare an original square project icon, screenshots that show actual content, a concise summary, a full English description, installation instructions, license, source or issue links if available, and a changelog. CurseForge states that project titles and descriptions must be in English for submission. Additional translations can appear after the clear English information.
Create a project page people can understand
The project name should be distinct and should not be padded with a Minecraft version or the word "mod" when the name already communicates the project. The summary is one sentence about what the download adds or changes. Avoid claims such as "best" or a list of keywords.
The long description should answer five questions near the top: what it does, which edition or loader it targets, what players can do, whether it needs dependencies, and how to install it. Then add features, media, compatibility notes, known limitations, configuration, support, credits, and license information.
Use real in-game screenshots. Show the feature at a useful scale and include UI only when the UI matters. CurseForge recommends a unique project logo and notes a minimum square format in its submission tips. Do not reuse a game logo or another creator's artwork as the project identity.
Choose one accurate primary category and only relevant additional categories. Incorrect categories can delay moderation and attract the wrong visitors. Enable a feedback channel you can actually monitor, whether comments, an issue tracker, or a clearly linked support server.
Package release files correctly
Java mods
Upload the production JAR from the build output, not a development JAR, sources JAR, Gradle project, or entire workspace. Open the archive and confirm that loader metadata, resources, mixin configuration, and license files are present. The file name should contain the project and version without becoming a paragraph.
Bedrock add-ons and packs
Package only the folders players need. Verify that manifest.json is at the expected level, Behavior and Resource Packs use distinct UUIDs, and dependencies match. Do not include development backups, Blockbench cache, screenshots, or a folder wrapped inside several unnecessary folders.
CurseForge's general upload documentation says most games use a ZIP archive and explicitly warns not to rename another archive type to .zip. The exact accepted formats vary by game and project class, so follow the current Minecraft upload form rather than assuming one format fits every class.
Scan the final artifact for credentials and private files. API keys, webhook URLs, signing keys, personal paths, test accounts, and unpublished assets do not belong in a release. Download your own artifact after upload and test that exact file.
Set game versions, loaders, release type, and dependencies
Select only versions you have tested or can support. Marking every Minecraft version may increase clicks briefly, but it produces failed installs, poor ratings, and support load. A version range should reflect real compatibility, not visual similarity between releases.
For Java, select the correct loader such as Fabric or NeoForge where the form provides it. Do not label one JAR for multiple loaders unless the artifact genuinely supports them. For Bedrock, state stable or Preview requirements prominently and do not market an experimental pack as universally compatible.
Choose release type deliberately. CurseForge describes Release as the normal stable channel, while Beta and Alpha require users to opt into less stable files in relevant contexts. A project needs a Release file before normal app synchronization according to the official submission guide.
Declare required, optional, embedded, and incompatible projects accurately. Required dependencies can be installed automatically by the client. Bundling a dependency without permission is not a substitute. Include version requirements in the description or changelog when the platform relation cannot express all constraints.
Avoid common moderation problems
Moderators need enough information to understand the project and verify ownership and function. A vague description, generic icon, broken archive, irrelevant categories, copied media, or missing license context can lead to changes required. Read the current moderation policies before the first submission and again when introducing monetization or third-party assets.
If a project is returned, read the specific notification and change the requested item. Do not repeatedly upload identical files or create a duplicate project to bypass review. Keep a record of sources and permissions so you can answer ownership questions.
Do not promise a moderation time. Review duration varies. Prepare the public announcement after the file is approved and visible, or clearly label a scheduled release. A Discord post linking to an unavailable project creates support requests before players can download anything.
Publish, download, and verify the live result
- Open the public project page in a signed-out browser.
- Check title, summary, category, icon, description, and screenshots.
- Confirm the default download selects the intended stable file.
- Verify Minecraft versions, loaders, dependencies, and release type.
- Download the public artifact and test a clean installation.
- Check source, wiki, issues, Discord, and website links.
- Publish the announcement with the exact supported versions.
Keep the previous stable file available unless it has a security or licensing problem. Players on older game versions may still need it. Mark obsolete or broken files appropriately instead of deleting history without explanation.
Ship updates without breaking existing users
Use a consistent versioning policy and a specific changelog. Describe added, changed, fixed, and removed behavior. Call out world migration, configuration changes, dependency updates, and compatibility breaks before the feature list.
Test upgrades from the previous public version, not only new installations. For a world-affecting mod or add-on, back up and test representative saves. Never reuse a version number for different bytes; caches, launchers, and support conversations need a unique identity.
Use Beta or Alpha channels for files that need broader testing, then promote a separately tested build to Release. Keep source tags and artifacts aligned where the source is public. Archive build logs or checksums for important releases.
Improve discoverability without keyword stuffing
Write a literal project name and a one-sentence summary that explains the mechanic players search for. Use accurate categories, supported versions, screenshots, and an updated description. Those fields help users filter and decide; repeating keywords in every heading does not.
Create one stable page on your own site with documentation, FAQ, and links to the official CurseForge download. Link back from the project page where allowed. Publish useful tutorials about the mechanics the project uses and connect them naturally, but do not create dozens of near-identical pages for every keyword variation.
Track questions and failed installs. If many users cannot find installation steps or version requirements, improve the project page before creating more promotional posts. Discoverability earns the click; accurate documentation earns the download and retention.
Official sources checked
Primary references used to verify this tutorial:
- CurseForge Support - Creating and Submitting a Project
- CurseForge Support - Project Submission Guide and Tips
- CurseForge Support - Moderation Policies
- CurseForge for Studios - Authors Dashboard