miraheze.org

Miraheze is a genuinely free, ad-free wiki host: it runs MediaWiki, is operated by a non-profit, and its own site states that none of its wikis feature or will ever feature ads. That makes it the clearest starting point if "free" and "no ads" are your hard requirements. The catch is that "free" never means unlimited — every host, including Miraheze, sets its own limits on customization, domain names, and long-term guarantees, and you should check those before you commit years of editing.

What "free wiki hosting" usually hides

Most hosts that advertise free hosting make their money somewhere. That shapes what you actually get:

• Ads on your wiki. The host injects advertising to cover costs. You often can't remove it.
• Feature paywalls. Custom domains, extra extensions, or removing branding may require a paid tier.
• Content licensing and ownership. Some platforms claim broad rights over what you write, or make exporting difficult.
• Shutdown risk. A free service with no revenue model can disappear, taking your content with it.

Miraheze's model is different in kind: it is a non-profit, its stated mission is to serve users, and its site explicitly guarantees no ads. That removes the ad and paywall problems, but not the shutdown or limit problems — no host is immune to those.

Comparing the main options on the same dimensions

Two rows deserve emphasis. First, custom domains: the source material does not state Miraheze's policy, so treat this as something to confirm on their FAQ rather than assume. Second, export: because Miraheze runs MediaWiki, standard MediaWiki export and dump tools apply, which is the practical insurance policy against any host shutting down.

When each choice fits

• Choose Miraheze if you want a MediaWiki wiki, no ads, no hosting bill, and you're comfortable with a volunteer-run non-profit. Its own examples span technology, games, TV/entertainment, sciences, and education — so niche fan wikis and documentation projects both fit.
• Choose an ad-supported commercial host only if its network effect matters more to you than ad-free pages — for example, you want your wiki to be discoverable inside a large existing community.
• Choose self-hosting if you need a custom domain, unusual extensions, or total control and are willing to pay for a server and handle updates yourself. DokuWiki and Wiki.js suit smaller, simpler sites; MediaWiki suits large, link-heavy encyclopedias.

How to judge whether a "free" host is really free

Run these checks before you start writing:

1. Read the ad policy, not the marketing. Look for an explicit statement like Miraheze's guarantee, not just the absence of ads today.
2. Find the limits page. Search the FAQ for storage, file uploads, number of wikis, and custom domains.
3. Test the export path. On MediaWiki, confirm Special:Export works and that you can request a database dump.
4. Check who pays the bills. A non-profit with a donation page is a different risk profile from an anonymous free host.
5. Look at the age and activity. A host with years of history and an active help center is less likely to vanish.

Creating your first wiki on Miraheze

The flow is self-service, and the source describes an interface where administrators configure "almost every aspect" of their wiki.

1. Create an account and sign in.
2. Start a wiki — the site's primary call to action. You'll choose a name and subdomain and describe your topic.
3. Wait for approval. New wikis are typically reviewed before going live; this is normal for a volunteer-run service.
4. Configure it. From the admin panel, select skins and extensions. The site cites over 300 available, so start minimal and add as needed.
5. Set permissions. Decide who can edit, and whether registration is open.
6. Back up early. Export key pages once you have real content, not after a problem appears.

Expected result: a live, ad-free MediaWiki wiki you can edit and customize. Common snags: approval delays, extension conflicts after enabling too many at once, and assuming a feature (like a custom domain) that the source doesn't confirm — verify first.

If your priority is simply "free and no ads," Miraheze matches that description directly. If your priority is a custom domain or deep technical control, plan on self-hosting instead, and treat any free host's feature list as something to verify rather than assume.

A wiki is a website whose pages any permitted visitor can edit directly in the browser, with every change saved as a version you can review or revert. That single feature—open editing plus a full revision history—is what separates a wiki from a blog, a forum, or a static site. If you want to build one, the practical path is: pick a narrow topic, choose a MediaWiki-based host, create the main page and a category structure, then invite a few editors before you publicize it. Miraheze is one concrete option: it advertises free, ad-free wiki hosting powered by MediaWiki and run by a non-profit, with self-service configuration and a choice of over 300 extensions and skins.

What actually makes something a wiki

Four mechanics do the work. Remove any one and you have a different kind of site.

• Editable pages. Content lives in pages that authorized users change in place, not in a publishing queue.
• Version history. Every save creates a revision. You can compare versions, see who changed what, and roll back vandalism or mistakes.
• Links as structure. Internal links between pages form the real navigation. A wiki's shape emerges from how pages point at each other, not from a fixed menu.
• Talk/discussion pages. Each page can carry a companion discussion space for resolving disagreements about content without editing the article itself.

How a wiki differs from a blog, forum, or static site

A wiki is the right tool when the goal is a shared, evolving reference. It is the wrong tool when you need a single authoritative voice or a simple brochure site.

How to create and run a wiki

1. Define the scope before anything else

Write one sentence: "This wiki documents X for Y." A topic that is too broad ("all games") collapses under its own weight; a topic that is too narrow runs out of pages in a week. Miraheze's own examples suggest the useful range—technology documentation and knowledge bases, game encyclopedias covering mods and hidden features, TV and entertainment references, science topics, and education material such as curricula and research.

2. Choose a platform or host

MediaWiki is the software behind Wikipedia and the engine Miraheze runs on. Your realistic choices are:

• Self-hosted MediaWiki — maximum control, but you own servers, upgrades, backups, and spam defense.
• A wiki farm / free host — someone else runs the infrastructure. Miraheze positions itself here: free, ad-free, non-profit, with a self-service admin interface and a large extension and skin library.
• A different wiki engine — lighter alternatives exist, but you give up MediaWiki's extension ecosystem and the familiarity many editors already have.

If your priority is getting content written rather than running servers, a farm is the lower-friction start. If you need deep customization or data control, self-hosting is the trade.

3. Set up the basic structure

Once your wiki exists, do these in order:

1. Main page — a short orientation plus links to your top-level categories.
2. Categories — group pages by type (e.g., Characters, Locations, Guides). Categories are how readers browse when they don't know a page name.
3. Naming and style conventions — decide page-title format and a basic article layout now; retrofitting hundreds of pages later is painful.
4. Core templates — infoboxes, stub notices, and citation templates save enormous time once reused.

4. Configure extensions and skins

Miraheze states administrators can configure almost every aspect of their wiki through a self-service interface and choose from over 300 extensions and skins. Practically, you'll want a handful early: an anti-spam tool, a visual editor if your contributors aren't comfortable with wikitext, and a skin that matches your subject. Add more only when a real need appears—every extension is something to maintain and learn.

5. Invite editors and set expectations

A wiki with one editor is a personal notebook. Recruit a few people who care about the topic, then agree on the boring but essential rules: what counts as a reliable source, how to handle disputes, and who can delete pages. Write these down on a policy page so you're not renegotiating them in every argument.

6. Plan for moderation and spam

Open editing attracts spam. The standard defenses are account requirements for editing, CAPTCHAs, moderation of new-page creation, and watchlists so admins see changes as they happen. Decide your posture before launch: fully open, or open-with-review. Most new wikis are better off starting stricter and loosening later.

Common problems new wiki owners hit

• Nobody edits. Usually a scope problem—the topic is too broad to feel "yours," or there's no seed content. Write 20–30 solid pages yourself first; empty wikis repel contributors.
• Spam floods. Tighten account and editing permissions, enable anti-spam extensions, and use recent-changes patrols.
• Structure chaos. Contributors invent conflicting page names and categories. Publish conventions early and fix drift while the wiki is small.
• Edit wars. Use talk pages to resolve content disputes rather than reverting back and forth, and give admins a clear escalation path.
• Abandonment. Wikis die when the founding editor stops. Recruit a second admin before you need one.

Choosing a host: what to weigh

Compare options on the same axes: cost model, ads, software, customization, and who handles maintenance. Miraheze's stated position is free, ad-free, MediaWiki-based, non-profit, self-service, with 300+ extensions and skins—a fit if you want MediaWiki without running servers and you accept a hosted platform's constraints. Self-hosting wins if you need full control over data, versions, or unusual configuration. The site's pricing page and sign-in terms aren't covered in the material here, so confirm current cost and account requirements directly before committing.

Wiki hosting is a service that runs the server, wiki software, and maintenance for you so you only manage content and community. It fits most projects that want a working wiki without building infrastructure, while self-hosting suits teams that need deep server control or have strict data-residency rules. The main decision factors are cost model, ads, software flexibility, and how much technical work you want to keep.

What wiki hosting actually covers

A hosting provider typically supplies:

• Server infrastructure — web servers, databases, storage, and bandwidth.
• Wiki software — most commonly MediaWiki, the engine behind Wikipedia, though some hosts use other engines.
• Maintenance — software updates, security patches, backups, and uptime monitoring.
• A management interface — where you create the wiki, assign administrators, and adjust settings.

You focus on pages, templates, categories, and community rules. The provider handles the stack underneath.

Self-hosting vs. managed hosting

Choose self-hosting if you need custom server-level changes, specific data residency, or full control over every extension. Choose managed hosting if you want to start quickly and keep effort on content.

Key features to check before committing

• Ad policy — Some hosts inject ads; others guarantee none. Confirm the policy in writing, not just on a marketing page.
• Software and extensions — If you need specific MediaWiki extensions or skins, verify they are available or can be requested.
• Custom domain — Check whether you can map your own domain and whether that costs extra.
• Backups and export — Confirm you can export your content and database, and how often backups run.
• Privacy and data handling — Review where data is stored and what the host logs.
• Community and support — Look for active help channels, documentation, and response times.
• Governance — Non-profit or community-run hosts may have different long-term incentives than ad-driven commercial hosts.

Free vs. paid hosting: typical differences

Free wiki hosting usually means the provider covers server costs through donations, grants, or a parent organization. Common trade-offs:

• Fewer or no ads (some free hosts are ad-free; others are not).
• Limits on storage, bandwidth, or number of wikis.
• A subdomain instead of a custom domain, or a paid upgrade for one.
• A fixed set of extensions rather than arbitrary installs.
• Less individualized support.

Paid hosting often adds custom domains, higher resource limits, priority support, and more configuration freedom. Neither model is automatically better; match it to your project's scale and needs.

How use case shapes the choice

• Encyclopedia or fandom wiki — Needs many extensions, templates, and a large editor community. Prioritize extension availability and community tools.
• Internal documentation or knowledge base — Needs access control, reliable backups, and possibly private wikis. Check privacy settings and export options.
• Educational or research wiki — Needs stable hosting, citation-friendly features, and sometimes institutional data rules. Verify data handling and uptime.
• Small personal or hobby wiki — A free, ad-free host with a subdomain is often enough.

Example: Miraheze as a MediaWiki host

Miraheze is a non-profit wiki hosting service that runs MediaWiki and states its wikis are ad-free, with no ads "guaranteed." Its self-service interface lets administrators configure many aspects of a wiki, and it offers over 300 extensions and skins for customization. It lists use cases including technology, games, TV/entertainment, sciences, and education, and it is operated by volunteers with a mission to serve users.

If your project fits MediaWiki, wants no ads, and you are comfortable with a volunteer-run, non-profit model, Miraheze is a reasonable candidate to evaluate. Check its current extension list, domain options, and backup/export policies against your requirements before starting, since those details determine whether it fits a specific project.

Miraheze is a non-profit wiki hosting service that runs on MediaWiki, the same software that powers Wikipedia. It is ad-free, and its own site says wikis on the platform "feature or will ever feature any ads, guaranteed." It suits communities and projects that want a ready-made wiki without running their own server, especially in technology, games, TV/entertainment, sciences, and education. The trade-off is that you are working within Miraheze's MediaWiki setup and its volunteer-run governance rather than owning the full stack yourself.

What Miraheze actually is

Miraheze is a hosting service, not a wiki you edit. You bring the topic and the community; Miraheze provides the MediaWiki installation, the infrastructure, and the technical upkeep. Its homepage describes it as "powered by expert MediaWiki volunteers" and run by "a non-profit whose mission is to serve you."

That distinction matters. You are not installing MediaWiki, configuring a database, or patching security updates. You are creating a wiki inside an existing farm, where many wikis share the same platform and are managed through a self-service interface.

Who it fits

Miraheze's own homepage lists these use cases:

It also states that "experts and novices alike can come together to collaborate on wikis of various topics, from astronomy to physics." If your project is a community knowledge base on a defined topic, that is the core fit. If you need a private corporate intranet, a heavily customized application, or full control over the server, a wiki farm is usually the wrong shape for the job.

Key features

• Ad-free. The site guarantees no ads on hosted wikis.
• Self-service setup. Administrators configure "almost every aspect of their wiki" through the interface.
• Customizability. The site says you can choose and configure "over 300 extensions and skins."
• MediaWiki foundation. You get the same editing model, templates, and extension ecosystem as Wikipedia-style wikis.
• Non-profit operation. The platform is run by a non-profit rather than a commercial host.

The site also exposes a Donate link, which is consistent with a non-profit funding model. The provided page material does not state prices or paid tiers, so treat cost claims beyond "free hosting, no ads" as unverified here.

How it compares to other free wiki hosts

Use the same dimensions when you evaluate alternatives:

• Ads: Miraheze guarantees none. Check whether a competitor injects ads or upsells on free plans.
• Software: Miraheze is MediaWiki. Other hosts may use different engines, which changes templates, extensions, and editing conventions.
• Control: Miraheze gives you a self-service admin panel over your wiki, but not root access to the server. If you need server-level control, self-hosting MediaWiki is the alternative.
• Customization depth: 300+ extensions and skins is broad, but it is still a curated set. If you need an extension Miraheze does not offer, that is a real constraint.
• Governance and continuity: A volunteer-run non-profit is not the same as a company with a support contract. For a long-lived community project, understand how the platform is governed before you commit years of content.

There is no single "best" answer. If your priority is zero cost, no ads, and MediaWiki without maintenance, Miraheze is a strong candidate. If your priority is full control or guaranteed commercial support, it is not.

Getting started

1. Create an account. The site has a Sign in entry point; you need an account before you can start a wiki.
2. Start a wiki. Use the "Start a wiki" action from the homepage. You will describe your wiki and its purpose as part of the request.
3. Configure it. Once approved and created, use the self-service admin interface to set skins, extensions, and permissions.
4. Build content. Edit pages the way you would on any MediaWiki site, using templates and categories.
5. Get help. The site links to an FAQ and a Help Center, plus a Donate page if you want to support the platform.

What to verify before you commit: the current request and approval process, whether your intended extensions are available, and how your wiki's content and configuration are handled if you ever want to leave. The provided page material does not cover migration or export specifics, so confirm those directly with Miraheze's help resources.

Common sticking points

• Assuming "free" means no conditions. Free hosting still comes with platform rules, a request process, and community governance. Read them before you invest effort.
• Assuming you get root access. You configure your wiki, not the server. Extensions outside the supported set are typically not installable.
• Skipping the help docs. The FAQ and Help Center exist precisely because MediaWiki configuration has a learning curve. Use them early rather than after you have built a structure you need to undo.
• Treating it as a commercial SLA. A volunteer non-profit is not a vendor with a support contract. Plan accordingly for a project you care about long-term.

If your project is a topic-focused, community-edited knowledge base and you want MediaWiki without the server work, Miraheze is built for exactly that. If you need server-level control or contractual guarantees, look at self-hosting instead.

A handheld gaming wiki is a community-maintained reference site that catalogs handheld gaming devices and organizes practical information about them: specifications, custom firmware (CFW), flashing guides, hardware mods, compatibility lists, and buying advice. You use one when you need to look up a specific device, compare models, or find instructions for changing its software — rather than when you want a single reviewer's opinion. Handhelds Wiki is one example: it describes itself as covering "specifications, guides, troubleshooting, firmware, themes, hardware mods, downloads, and more" for handheld gaming devices, and its main page is organized around categories and device-specific pages rather than articles.

What a handheld wiki actually contains

The content on a wiki like this falls into a few recurring types. On Handhelds Wiki's main page, the "Useful Pages" section links to things such as a Custom Firmware Guide, a Firmware Flashing Guide, a Handheld Buying Guide, Compatibility Lists, and PortMaster. Alongside those general references, the site maintains device-specific wikis — for example an R36S Wiki, an Anbernic RG40XX H Wiki, and a BATLEXP G350 Wiki — plus individual pages on narrower topics like an R36S grip test, an internal WiFi mod, a shoulder button upgrade, and a long-term review with a battery test.

That mix tells you what a wiki is good for:

• Specifications — screen size and resolution, form factor, and manufacturer, indexed so you can filter across many devices.
• Firmware and CFW — which custom firmware options exist for a device, and how to flash them.
• Mods and repairs — hardware changes and fixes documented by people who did them.
• Compatibility lists — what runs and what doesn't.
• Buying guidance — general advice plus model-to-model comparisons.

How to navigate a handheld wiki

Wikis are usually indexed several ways at once, so you can enter from whichever detail you already know. Handhelds Wiki's category structure includes:

If you already know the device name, go straight to its page or device-specific wiki. If you don't, pick the attribute you care about most — a 3.5" screen, a clamshell body, an Anbernic device — and browse that category to build a shortlist.

Using device pages to compare models and check known issues

A device page is where a wiki earns its keep over a review. Because entries are structured the same way, you can line up two or three candidates on the same fields instead of reading three unrelated articles. Handhelds Wiki also hosts direct comparisons, such as "R36S vs R36XX vs R36Plus vs R36H," which is the kind of page to look for when two models share a name family and you need to know which one you're actually buying.

Device pages and their linked notes are also where known issues surface. The R36S entries on the main page — a grip test, an internal WiFi mod, a shoulder button upgrade, a long-term review and battery test — are examples of the practical, model-specific detail a wiki collects: ergonomics, connectivity limitations, button feel, and battery behavior over time. When you're researching a device, check whether its page links to this kind of follow-up note, not just a spec sheet.

Finding firmware and CFW instructions

Firmware is one of the main reasons people visit a handheld wiki. Two entry points matter:

1. The general guides — a Custom Firmware Guide and a Firmware Flashing Guide explain the concepts and the process in the abstract.
2. The device-specific page — tells you which firmware options are actually available for your model and links to the relevant files or steps.

The site's Linux firmware category, for instance, lists both active projects (AmberELEC, Batocera, KNULLI, muOS, ROCKNIX, and others) and inactive ones (ArkOS, JELOS, MinUI, RetroFW, and others), while the Android category separates current versions from inactive ones. That active/inactive split is worth checking before you commit to a firmware: a project listed as inactive may still work, but it isn't where ongoing development is happening.

How a wiki differs from reviews and forums

These three sources answer different questions, and the fastest research usually uses all three in sequence:

• A wiki answers "what are the specs, what firmware does it take, what's known to go wrong, and how does it compare on paper?" It's structured, indexed, and edited over time.
• A review answers "what is this one device like to actually use?" It's a single perspective, often tied to a moment in time.
• A forum or community answers "what's happening right now, and what do other owners say?" Handhelds Wiki points to r/SBCGaming and the Retro Handhelds Discord for exactly this.

A practical order: shortlist on the wiki using specs and categories, read a review or long-term note for the feel of the device, then check the community for current problems or workarounds before buying or flashing.

Things to keep in mind

Handhelds Wiki's main page carries a visible "Site under construction" notice and a to-do list that includes adding devices and improving page and category navigation. Treat any wiki — this one included — as a work in progress: coverage will be uneven across devices, and a page may be incomplete or out of date. Cross-check anything you're about to act on, especially firmware files and flashing steps, against the device-specific page and, where possible, a second source. The wiki is a map of the territory, not a guarantee about any single device.