nhanaz.io.vn
Dossier - 003
  • 30.06.2026
  • Updated 15.07.2026
  • 52 min read

What Is PocketMine-MP? Complete PMMP History, 2012-2026

A PHP server that opened Minecraft Pocket Edition to custom multiplayer, survived several generations of APIs, and ended when the cost of following Bedrock exceeded the maintainer capacity left behind it.

PocketMine-MP, commonly shortened to PMMP, is open-source server software for Minecraft Bedrock Edition rebuilt primarily in PHP. It is not Mojang's Bedrock Dedicated Server, and it is not a plugin installed on top of BDS. PMMP accepts Bedrock clients, implements the protocol, players, worlds, blocks, items, entities and commands itself, then exposes those systems to plugins.

The project began with its first commit on October 19, 2012. Nearly fourteen years later, the last official release was 5.44.3 for Minecraft Bedrock 1.26.30, published on July 6, 2026. The main repository was archived on July 9, and the PMMP team announced that it would no longer update the software for new Minecraft versions.

PocketMine-MP is no longer maintained by the PMMP team. Its source, documentation and ability to be forked remain. “Official support has ended” is more precise than “the software disappeared.”

To understand why the end of updates for a PHP repository felt like the death of an era, release counts are not enough. PocketMine-MP once occupied the gap between a beloved mobile game and the multiplayer infrastructure its developer had not yet provided. It did more than run servers. It gave a community permission to build what was missing, then became a programming school, a business foundation and a childhood memory for several generations of Minecraft PE players.

Before PocketMine, Minecraft PE multiplayer barely had a shape

Mobile Minecraft was not yet Bedrock as we know it

In 2012, Minecraft Pocket Edition was still a small branch missing much of Minecraft Java. “Bedrock Edition” did not yet exist as the modern brand. Players mainly had single-player and local network multiplayer. One device opened a world, other devices on the same Wi-Fi discovered it, and the world disappeared from the network when its host left. There was no downloadable official dedicated server, no featured-server list, no Marketplace and no mature Add-On system.

This matters because it is easy to imagine PocketMine-MP as an alternative created in opposition to BDS. At the first commit, BDS did not exist to be opposed. The original question was not “BDS or PocketMine?” It was “how can a Minecraft PE client connect to a server process that runs on its own?”

Shoghi Cervantes Pueyo began answering that question by observing client traffic, identifying packets, recreating the login flow and building enough of a world to stop the client disconnecting. PMMP's explanation of why PHP was used describes the project as a quick prototype for reverse engineering a protocol that lacked complete documentation. It was not planned as production infrastructure.

“It was never intended for use on production servers.”

Source - PMMP documentation, “Why was PHP chosen?”

That sentence explains several tensions that followed PocketMine throughout its life. PHP was chosen for experimentation speed, not because an architecture committee declared it the perfect game-server language. Early abstractions were written while the protocol itself was still being discovered. Once the prototype became infrastructure, the community had to keep live servers running while replacing the foundations beneath them.

In 2013, PocketMine Realms came before external servers

One of the most forgotten pieces of the story is PocketMine Realms. On June 19, 2013, Shoghi launched a free service that let MCPE 0.7.0 players discover and join community servers through the Realms interface. Android users changed DNS settings. iOS users installed a configuration profile. The service stood between the client and server discovery, turning a door designed for Realms into an entrance to community-run multiplayer.

This was more than a server-list website. The game did not yet expose an official external-server button. PocketMine Realms modified the discovery layer so ordinary players could find PocketMine-MP servers through an interface they understood. The PocketMine team did not wait for Mojang to finish a path and then walk down it. They built the path first.

A Wayback Machine capture from October 1, 2013 preserves the shutdown notice. Its central sentence is not forum folklore. It was published by PocketMine itself.

“Mojang ... asked us to end our PocketMine Realms service.”

Source - 2013 PocketMine Realms shutdown notice

The archived PocketMine Realms notice says Mojang asked that the service end and offered official external-server connections in MCPE 0.7.4. Players could then press External, enter a name, IP and the default port 19132. The PocketMine Realms database was deleted because it was no longer needed.

The event deserves a fair reading without becoming bloodless. Mojang opened a better official path for users, and the immediate result helped the PocketMine ecosystem. It also established that Mojang was not entirely outside PocketMine's history. The company directly requested the end of a PocketMine-operated service when it touched the Realms surface. Years later, when the community suspected a conflict between Shoghi's Mojang employment and PocketMine, that precedent made the theory more than an invention formed in a vacuum.

Why PocketMine-MP mattered

PocketMine-MP filled the gap with a package users could operate themselves. Someone with a PC, a VPS, rented hosting or even a sufficiently stubborn Android device could obtain the PHP binary, run a PHAR, expose UDP port 19132, type an IP into the game and install plugins. The earliest clearly preserved GitHub release, Alpha 1.3.3 on July 4, 2013, supported Minecraft PE 0.7.2. Contemporary guides covered Linux, macOS, Windows, Android and even jailbroken iOS environments.

That setup was not friendly by modern standards. Operators had to understand local and external IP addresses, forward UDP through a router, configure firewalls and match the client protocol exactly. Windows 10 later added UWP loopback restrictions. Yet difficult was different from impossible. PocketMine turned independent multiplayer from something only a game studio could ship into a weekend project a student could struggle through and eventually understand.

Mojang did not put Bedrock Dedicated Server into public alpha until Bedrock 1.6.1 in 2018. For most of 2012-2018, PocketMine-MP was not a secondary option beside a complete official server. For many operators, it was the practical route to IP-addressable multiplayer with custom logic.

PMMP's value was never perfect Minecraft simulation. It was control. Server owners could create survival games, lobbies, prison, factions, skyblock, economies, ranks, kits, forms and rules that did not need to exist in the base game. A missing core feature often became a plugin's job. That pattern produced hosting markets, paid development, large networks and an ecosystem of ideas.

PMMP's documentation names Lifeboat Survival Games as one of the first large MCPE servers built on PocketMine-MP. This created a remarkable circle. PocketMine helped early networks grow. Those networks generated demand for plugins, hosting and protocol updates. Lifeboat eventually hired dktapps, funded public work and helped keep PMMP alive for years longer.

How PocketMine-MP worked

An independent server, not a BDS wrapper

When a player connected, the Bedrock client spoke RakNet over UDP. RakLib handled the RakNet transport layer, while BedrockProtocol defined how Minecraft Bedrock packets were encoded and decoded. The core translated network data into meaningful server actions such as login, movement, block interaction, inventory transactions and commands.

The core maintained player and world state on a tick loop. Plugins registered listeners, commands, permissions and tasks that could observe or change that state. Outgoing packets were encoded, compressed and sent back to the client. The player still launched an ordinary Bedrock client. Everything different lived behind the server address.

Modern PMMP depended on specialized packages and extensions for NBT, LevelDB, block states, item mappings, encryption, compression and threading. This is why “written in PHP” is correct but incomplete. Most application logic was PHP, while C, C++ and custom extensions reinforced an environment that looked nothing like a standard web-hosting PHP installation.

PHP lowered the entry barrier without removing the hard problems

PHP was an unusual game-server language and part of PocketMine's accessibility. The syntax was approachable, the edit-and-run loop was short, plugins shipped as PHAR files, and a first plugin could begin with a few classes. Many people first understood events, objects, namespaces, dependencies and persistent data while trying to stop a server plugin from throwing errors.

The tradeoff was that PHP was not designed for a long-running multithreaded game server. PMMP's own threading documentation explains that most PHP data structures cannot be shared safely across threads, and copying data can cost more than the parallel work saves. PMMP used threads for suitable tasks including world generation, lighting, network compression and occasional cURL requests, while gameplay and plugin work still had to respect the main thread.

PHP did not make PMMP automatically slow, nor did it make the server infinitely easy to scale. Performance depended on core design, plugins, disk access, networking, entities, chunks and the amount of work done each tick. A plugin blocking the main thread with a query or heavy loop could stall the entire server even when the machine had idle CPU cores.

The plugin platform was the product

The official documentation defines a plugin as an external module that adds features or changes default behavior. Plugins could listen to events, cancel actions, modify outcomes, register commands, manage permissions, change inventories, send forms, schedule tasks and connect to outside services.

This is also why PMMP should never be graded as a BDS clone. The official README explicitly warned that it was poorly suited to vanilla survival and lacked systems such as vanilla world generation, redstone, mob AI and other gameplay. PMMP was strongest when a server wanted to depart from Minecraft. BDS was usually the more sensible choice when the goal was survival close to the original game.

PocketMine-MP history, 2012-2026

2012-2013, from Pocket Minecraft PHP to an MCPE server

Shoghi Cervantes Pueyo, known as shoghicp, started the project in October 2012. It was originally called Pocket Minecraft PHP. The first commit on October 19, 2012 carried only the message “First commit”, but an independent server slowly formed from it inside the PocketMine organization.

The early team was writing code while discovering the protocol of a mobile game that changed rapidly. There was no complete specification to follow. Packets, world formats and client reactions had to be observed, tested and reimplemented. Unknown client data did not produce a neat error. It could cause a disconnect, malformed world state, inventory desynchronization or a crash.

The Alpha 1.3.x releases in 2013 mark the prototype becoming software with real users. PocketMine's version did not match Minecraft PE's version, a source of confusion for years. PocketMine Alpha 1.3.3 supported MCPE 0.7.2. Whenever a mobile store updated the client, server owners had to find a compatible build or hold players on an older game version.

A running server immediately produced new demands. Users wanted commands, whitelists, permissions, multiple worlds, anti-grief tools, economies and minigames. The core could not contain every idea. Plugins let community demand move faster than a small core roadmap. PocketMine was no longer only reverse engineering a protocol. It was building a social API through which people unable to rewrite the core could still reshape their servers.

2014-2015, community infrastructure takes shape

Over the next two years PocketMine-MP gained a website, forums, a plugin repository, Jenkins builds, documentation, IRC channels and a broader contributor group. The website was where people downloaded the server. Jenkins supplied development builds. The forum combined setup support, plugin distribution and API debate. GitHub held the code, but most operators lived in a chain of websites, forum posts, PHAR files and tutorials found through search.

The 1.4 line, named “Zekkou Cake”, passed through many betas before stabilizing in early 2015. Release 1.4 on January 2, 2015 supported MCPE 0.10.4, raised the API to 1.10.0, changed the RakLib interface and improved world generation, memory use and IP blocking. Its notes admitted that the former stable release had become completely outdated, so 1.4 shipped despite missing features. The client did not wait for the server to become complete.

Popular plugins gave the community its own vocabulary. EconomyAPI underpinned currencies. PurePerms and PureChat handled groups, permissions and prefixes. EssentialsPE or essentialsTP collected convenience commands. FactionsPro, WorldProtect, ManyWorlds and SimpleAuth helped turn an incomplete gameplay core into a recognizable server. Many plugins outlived their authors through forks, API ports or transfer into Poggit Orphanage.

Small operators assembled dozens of public plugins. Large networks often built one private “core plugin” containing matchmaking, economy, ranks, moderation and game loops to reduce dependencies. This private-core culture means PocketMine's impact was always larger than the surviving public plugin list.

The old PocketMine repository preserves 4,718 commits and 30 releases from the legacy organization. Yet code was only one part of a living project. Domains, forums, plugin repositories, build servers and the ability to add collaborators determined who could operate the community. The most consequential governance flaw was not in PHP. Nearly all infrastructure keys were concentrated in one person.

By early 2015, a prototype had become an institution

When a small project fails, users move elsewhere. When PocketMine slowed in 2015, servers, hosts and plugins already depended on it. Every MCPE protocol change became a business deadline. Every API break created hundreds of support questions. A late release could stop newly updated clients from joining a network they played every day.

Dependency grew faster than governance. PocketMine had contributors, moderators and developers, but its central infrastructure did not distribute authority accordingly. That bus factor was hard to see while the founder remained active. Only when Shoghi became busy, fell out of contact and stopped regular development did the community discover that permission to edit code was not the same as permission to maintain the project.

Late 2015-2016, the founder leaves and forks multiply

According to the PocketMine-versus-PMMP history, Shoghi was forced to stop developing in late 2015 because it conflicted with his work at Mojang. He also held exclusive administrator access over almost all legacy infrastructure, including the GitHub organization, forums and website. When he fell out of contact, the remaining team could not add collaborators, maintain infrastructure or moderate the forums properly.

The word “conflict” does not tell us whether the constraint was contractual, organizational, intellectual-property related, concerned with Realms, or a combination. The context makes it hard to reduce to a lack of spare time. Shoghi worked for the company that owned the protocol PocketMine had to reverse engineer. Mojang had already requested the closure of PocketMine Realms. He retained the project's infrastructure keys without a clean handover. The most coherent reading is that his Mojang role created legal or interest constraints he could not publicly resolve.

A November 2016 forum history connected the departure directly to Realms while explicitly marking that part as “Theory”. The label does not make it worthless. It tells us contemporaries lacked complete information but could see the same sequence. The founder joined Mojang, development slowed, authority was not transferred and the official Realms ecosystem was expanding. History does not provide the internal email, but it does not require us to pretend those events were unrelated.

In 2016, PocketMine forked in a million directions

The vacuum produced an era of forks. Genisys, ClearSky, ImagicalMine, RedstoneLamp and many other projects tried to keep pace with new clients, add missing gameplay or serve a particular network. Genisys was created on February 27, 2016 and described itself as feature-rich MCPE server software based on PocketMine-MP. It appealed to operators who needed mobs, gameplay and compatibility now rather than a long core redesign.

ClearSky and ImagicalMine lived under similar pressure. A fork could take an older build, accept quick patches, backport packets, merge work from elsewhere and preserve the API for plugins. This was rational for an operator losing players each day. It was frustrating for maintainers trying to produce typed, testable code without another layer of debt.

In January 2017, a parent who only wanted a LAN server for his child described the search experience on PMMP Forums.

“Pocketmine forked off into a million directions.”

Source - PMMP Forums, “Pocketmine history: What happened?”

The “Pocketmine history: What happened?” thread listed ClearSky, RedstoneLamp, Genisys and PMMP, then asked why people had not rallied around one fork. It captured what search results could not explain. Old guides still pointed to PocketMine, the main project looked dead, many forks claimed continuity and plugins supported only selected branches.

In PMMP culture, a carelessly copied fork was often called a spoon. The joke that forks and spoons belonged in a kitchen cupboard concealed a serious dispute about quality and attribution. PMMP did not want to import Genisys features directly when the code was viewed as hacky, difficult to maintain or ethically sourced poorly. Operators saw working features and asked why upstream would not copy them. One side optimized for today. The other tried to avoid making tomorrow worse.

This era cannot be represented as a clean family tree. Projects borrowed from one another, changed names, lost Git history, moved organizations or existed only for one network. Public repositories sometimes lagged private development. Some projects were forks of forks. Some plugins depended on behavior available in only one spoon. The map was messy because the underlying needs were messy.

Steadfast, Lifeboat and history outside the upstream

Steadfast demonstrates another path. It was built on old PocketMine and heavily modified for Lifeboat. It could support protocol ranges or behavior the commercial network required, but it was not a complete protocol reference and did not need to implement features Lifeboat never used.

This explains why “large servers still work” does not mean the public upstream is healthy. A revenue-producing network can pay developers, control its supported client range, build proxies, omit unused gameplay and keep code private. A small operator needs public releases, public plugins and public documentation. Both may call their software PocketMine, but their survival conditions are very different.

September 2016-2017, PMMP becomes the successor

In September 2016, several members of the old PocketMine team and a new developer, Dylan or dktapps, formed the PMMP organization. They did more than fork a repository. They created a GitHub organization, website, forums, build services and accounts whose access could be shared. It was an institutional reconstruction after the project learned that open source did not automatically mean open infrastructure.

Intyre, a trusted member of the old PocketMine team, was quoted explaining the decision to leave the legacy infrastructure in one sentence.

“It is time to stop asking and to move on.”

Source - Intyre on PMMP Forums

In the same 2017 history thread, staff said they had repeatedly requested more access without receiving it. Dktapps explained that the old forums remained online not because the new team chose to preserve them, but because they did not even have permission to shut them down. PMMP was therefore both a technical name and a governance declaration. If the keys could not be recovered, the community would build another house.

PMMP was not an unrelated product that happened to share a name. It continued the code and people of PocketMine-MP in infrastructure the team could operate. In late 2017 Shoghi endorsed PMMP as PocketMine's successor, redirected several pocketmine.net addresses to pmmp.io and granted access to the old organization. PMMP already had more than a year of issues, pull requests, forum history and identity, so the team archived the legacy repositories rather than moving back.

That choice shows that software history is larger than commits. Issues preserve bugs and arguments. Pull requests preserve attribution. Forum links, CI URLs and package namespaces become habits for thousands of users. Moving back to the “official” organization could destroy more history than it restored. PMMP became PocketMine's upstream because the community had already treated it as one long enough for succession to become fact.

2017-2018, Poggit and API 3 pull the ecosystem back toward one centre

Once the old forums and plugin repository became unreliable, PMMP had another survival problem beyond the server core. Where would users find plugins, and why should they trust a PHAR offered for download? In early 2017, developers still complained that publishing a GitHub repository did not reach the audience of the old PocketMine plugin repository. Other forum members answered that there was not yet an “official PocketMine-style” release path and that Poggit was still in alpha.

A public consultation from December 2016 described Poggit in one technical sentence that would have long social consequences.

“Poggit consists of a continuous-integration (CI) and a plugin list.”

Source - PMMP Forums, “Poggit public consultation”

Poggit-CI connected to a GitHub repository, built its source into a PHAR after commits or pull requests and ran checks such as PHP syntax validation and plugin-structure inspection. Poggit Release did not let a developer upload an unexplained binary. An artifact had to be produced from source known to the service, then pass through review layers. Open source stopped being only an ethical claim and became part of the distribution pipeline.

The early proposal was ambitious. Staff would perform a quick malware and minimum-quality check. Users with GitHub accounts could participate in reviews. Official reviewers could inspect a release more deeply, and strong releases could be featured. Not every part of that original model survived unchanged, but its central principle did. A public plugin should remain traceable to source, and its download should be reproducible from that source.

Poggit also created an orphanage for abandoned plugins. EconomyAPI, PurePerms, PureChat, WorldProtect, ManyWorlds and many other familiar names were at various times moved into a shared organization so that the community could keep repairing them. The orphanage could not bring an author back, but it stopped merge and release authority from dying with one personal account. It was the same governance lesson for which the PocketMine core had already paid dearly.

API 3 was not a version bump, but eighteen months of surgery

On December 20, 2016, dktapps made the MCPE 1.0 branch public as API 3.0.0-ALPHA1 and warned operators not to use it in production because it could corrupt worlds. The journey from ALPHA1 to stable took about eighteen months. Each alpha could break plugins written for the previous alpha. Operators who simply wanted a working server saw a bewildering row of version labels. Maintainers saw a narrow opportunity to repair prototype-era decisions before those decisions hardened for another decade.

In the thread “Why is the API always changing?”, Intyre answered the title with characteristically dry humour.

“Why is your age always changing?”

Source - Intyre on PMMP Forums, “Why is the API always changing?”

The December 26, 2016 discussion then reached the serious reason. API versions protected servers from plugins calling classes and methods that no longer meant the same thing. A major version increased for incompatible changes. A minor version added capability while preserving compatibility. A patch fixed bugs. The ALPHA, BETA and RC suffixes tolerated no compatibility expectations because their interfaces were still under active construction.

API 3 brought strict typing deeper into the code, dropped 32-bit support, required a newer PHP, and changed entity performance, inventory transactions, skins, NBT, world providers and networking. Composer gradually replaced Git submodules for package management. Xbox Live authentication arrived. Newer LevelDB worlds became readable. Every change answered a real problem, but together they formed a migration wall.

The 3.0 alpha changelog is a better historical document than many retrospective summaries. A server release involved far more than tracking a Minecraft version. It records UUID problems, NBT signedness, memory leaks, thread safety, desktop crafting, resource packs and hundreds of method signatures. After reading the actual workload, “just bump the protocol” stops sounding like advice.

On June 18, 2018, PocketMine-MP 3.0.0 finally shipped for Bedrock 1.4.0. Server and plugin API versions now shared one semantic-versioning system. The 3.0.x line received fixes, 3.1 could add compatible features and master could prepare 4.0. The release-flow announcement turned a process that had once felt arbitrary into a more legible contract between core and plugins.

The price was still visible. Plugins without maintainers stayed behind. Operators had to find a fork, pay somebody to port the code or remain on an old core. Yet keeping every behaviour from 2013 so old plugins never broke would have trapped PMMP inside obsolete PHP, protocol and architecture. The API break was not simply a failure of compatibility. It was the fee charged for carrying a 2012 prototype into Bedrock in 2018.

2018-2023, PMMP matures while Bedrock gains an official BDS

BDS entered public alpha in 2018, six years after PocketMine's first commit. That changed the comparison. Operators who only wanted survival close to vanilla finally had an official server with the game's mobs, redstone, world generation and behaviour. PMMP no longer had to pretend to be the answer to every possible Bedrock multiplayer need.

BDS did not remove PMMP's reason to exist. BDS served vanilla behaviour and the extension boundaries designed by Mojang. PMMP served operators who wanted PHP plugins, several worlds in one process, cancellable events, intercepted packets and gameplay rewritten on the server. A prison network did not require perfect redstone. It required control over mining, economy, ranks, anti-cheat, forms and movement between lobbies.

PocketMine's vanilla weakness was therefore also a condition of its freedom. Because the core did not carry every BDS behaviour, plugins did not have to negotiate with every vanilla assumption. A server could treat a block as an interface button, an entity as an NPC, an item as a menu and a world as a disposable arena. For a minigame, “not like vanilla Minecraft” could be a requirement rather than a bug.

2019, the Titanic warning describes the ending years in advance

In September 2019, a Bedrock 1.13 beta removed debugging symbols from the Android binary. To a player, the change was almost invisible. To an independent server developer, symbols supplied function names, constants and other landmarks for reading an executable. The binary still ran without them, but the map for understanding its interior disappeared.

In an announcement titled “1.13, debug symbols and the Titanic”, dktapps explained that a protocol update then usually took days, while the same work without symbols might take weeks or months. Tools built over three years could become useless. Manual reverse engineering was far harder. He said plainly that he had considered leaving PocketMine development because the cost had begun to outweigh what he received from it.

“Third-party servers are just collateral damage.”

Source - dktapps on PMMP Forums, “1.13, debug symbols and the Titanic”

That line appeared when users asked whether Mojang was trying to kill third-party servers. Dktapps believed the stated target was hacking and that independent servers had been caught in the blast. This was not an allegation of a secret campaign aimed only at PocketMine. In one sense, it was more troubling. An ecosystem can be eroded without anybody hating it, merely because the people making platform decisions consider its damage acceptable.

The thread also rejected the idea that PMMP could simply copy Steadfast2. Lifeboat's fork implemented what its network required, contained incorrect or incomplete pieces and was not a substitute for understanding the protocol. MiNET, NukkitX and other independent servers depended on similar information. The problem was not PHP. It affected anyone trying to reproduce a closed platform's protocol without sufficient documentation.

The 2019 warning did not become terminal immediately. Useful symbols remained available through BDS for a while, tooling shifted toward that binary and PMMP kept updating. The dependency had moved rather than vanished. When public symbol-bearing BDS builds disappeared after 1.21.40, the temporary lifeboat described in the Titanic thread was finally withdrawn from the general public.

2020-2021, Lifeboat turns dependence into paid work

In April 2020, Lifeboat hired Dylan to migrate its network to PMMP 4, support newer Minecraft versions and perform PocketMine work the network needed. It was a rare point where commercial value flowed back into the upstream. Lifeboat had run a heavily modified descendant of old PocketMine for years. Instead of keeping every improvement inside another private fork, it paid a maintainer and allowed the generally useful work to be released publicly.

There is no need to romanticize that arrangement. A company funds work because it has a business need. Open source does not require pure motives, only mechanisms through which private benefit can also produce common infrastructure. Lifeboat needed PMMP 4. The community received protocol updates, refactoring and maintenance that an exhausted volunteer could not indefinitely provide. The 2026 farewell emphasized that the network could have commissioned closed-source work but chose not to.

PocketMine-MP 4.0.0 shipped on December 1, 2021 for Bedrock 1.18.0 after years of development. Its changelog exceeds 1,500 lines. World formats, networking, blocks, items, entities, commands and dependencies all changed. BedrockProtocol became a separate package. More PHP extensions became mandatory. Security and performance constraints tightened.

For plugin developers, PM4 meant another large migration. Namespaces changed, old methods disappeared and the world and block models were rebuilt. For operators, the familiar story returned. A favourite plugin had no new version, a YouTube video advised changing an API number, the console produced a TypeError and the developer forum explained that one line could not repair it. The frustration was real. So were the engineering reasons.

2022-2023, API 5 arrives as the forum becomes an archive

PMMP 3 support ended after 4.0 became stable. The team explained that maintaining two major lines consumed time that could instead improve 4.x and prepare 5.0. Every old branch required security fixes, Minecraft compatibility, PHP binaries and support answers. An open-source license does not make duplicated labour disappear.

PocketMine-MP 5.0.0 arrived on June 1, 2023 for Bedrock 1.19.80, added many blocks and items, read Bedrock worlds from 1.13 onward and changed the API. World and player data upgraded in a way that could not return to PM4 without a backup. The PHP runtime changed again. PM5 was not the governance revolution that PM3 had been, but it showed a core still moving toward modern Bedrock data instead of freezing around old abstractions.

In March 2023, PMMP Forums became read-only. A long-time member said goodbye and kept a list titled “Souls of PocketMine” in his signature. IvanCraft623 answered briefly.

“The party continues on the Discord server.”

Source - IvanCraft623 on PMMP Forums, “Goodbye forums”

The forum farewell sounds cheerful, but the migration carried an archival cost. A forum supplied public URLs, dates, relatively stable identities and search-engine indexing. Discord offered faster conversation and better real-time support, yet answers could sink into scrollback, accounts could disappear and outsiders could no longer reconstruct history through an ordinary web search.

This article can quote a 2016 argument about APIs and a 2019 warning about symbols. Many decisions after 2023 survive only through issues, commits or somebody's memory of Discord. Closing the forum did not kill PMMP. It made PMMP's later history harder to write.

2024, dktapps leaves and describes the human cost

On March 21, 2024, Dylan opened the “I'm retiring” issue. It was not a changelog or a short corporate notice. He described arriving in PocketMine in 2016 amid study pressure, unemployment and mental-health difficulties, then spending eight years on the server despite losing interest in Minecraft long before. For stretches of time, he opened the game only to test PMMP changes.

That detail breaks a common myth about maintainers. A project does not survive for a decade only because somebody remains endlessly passionate. It can survive through responsibility, circumstance, friendship, routine and the knowledge that leaving would create problems for thousands of other people. That persistence deserves gratitude, but it cannot be treated as a financing model.

Dylan said Lifeboat had transformed his circumstances from 2020 onward. Paid work let him use his strongest skills in a lower-pressure environment. By 2024, however, he wanted to leave the entire Minecraft space. He did not expect anyone to replace him as a “benevolent dictator.” If PMMP survived, it would have to become a team effort.

Five maintainers received access for game-update work, but none was paid to carry that responsibility. Merge access is necessary, but it is not motivation. Documentation is necessary, but it is not free time. A skilled person can still choose work that supports a family, or a project that brings more joy.

“All the large servers maintain their own forks, and the smaller servers die off.”

Source - dktapps, GitHub issue #6295

Dylan described that as the future he could most easily imagine. It was not supernatural prophecy. It was an incentive calculation. Large networks had revenue and direct need, so they could pay the cost of a fork. Smaller servers depended on public releases. Once the shared upstream disappeared, organizations with money retained an advantage while the commons contracted. Two years later, the upstream did end, and his prediction became the clearest frame for the post-PMMP period.

2024-2026, protocol costs rise and the upstream ends

Updating PMMP for a new Bedrock release was never a matter of changing one protocol number. The update guide left by the team requires PocketMine-MP, BedrockProtocol, BedrockData, BedrockBlockUpgradeSchema and BedrockItemUpgradeSchema repositories. The updater needs Linux, the matching BDS build, test worlds, protocol-dump tools, BDS modifications and the ability to use reverse-engineering software.

The process begins with packet IDs and version data. Some information must be dumped through a BDS mod because public documentation does not contain it. Packet traces between a vanilla client and BDS are collected with Frida or a proxy. The developer then changes encoders and decoders in BedrockProtocol, updates enums, determines packet directions, runs code generation and uses PHPStan to find places where the core no longer agrees.

Networking is only the beginning. Creative inventory, recipes, block palettes and item mappings must be regenerated. Schemas are needed so old worlds can upgrade block states and item data into the new version. World-data constants must prevent the client from opening a world with features the server cannot understand. Only then come unit tests, real playtesting, synchronized commits across repositories and compatible PHP binary releases.

Beginning with Bedrock 1.21.40, Mojang no longer made BDS builds with debugging symbols publicly available. PMMP's documentation says an updater needs a build supplied to a server or Marketplace partner to generate some required data. Public protocol documentation can provide part of the picture, but not all of it. The note ends with a severe conclusion. Third-party servers have become dependent on the goodwill of Minecraft partners.

This is where platform power matters more than the source license. Anyone can fork an LGPL repository. Not everyone has the binary, symbols, contacts and tools required to understand the next Bedrock version. An open license protects the right to modify what already exists. It does not compel the platform owner to disclose what is about to change.

PMMP continued to publish updates for many versions after Dylan announced his retirement. That proved the remaining team had ability. It did not prove succession was stable. Update work still rested with a handful of people, and every departure reduced the group possessing the skill, access and willingness to donate time at once.

In early July 2026, @driesboy left Minecraft. The farewell notice did not use vague language about a hiatus.

“No one is left willing to do updates for new Minecraft versions.”

Source - PMMP project closure notice

The team assembled update documentation for anyone willing to continue through a fork, but confirmed that PMMP itself would not publish more releases. It thanked Lifeboat, maintainers, moderators, reviewers, Patreon supporters and the wider community. The acknowledgements also became an inventory of labour that often remained invisible until nobody was left to perform it.

Release 5.44.3 for Bedrock 1.26.30 arrived on July 6, 2026. The repository was archived on July 9 at 18,965 commits. This was an explicit ending for the PMMP-maintained upstream, not a quiet month or a Discord rumour.

July 15, 2026, why did dktapps not hand PMMP to a successor?

In an exchange that began at 06:06 on July 15, 2026 in Vietnam, or 23:06 on July 14 in UTC, a member asked dktapps why he archived PMMP instead of handing it to someone still willing to update it. The first answer from Dylan T., PMMP's principal technical and governance lead for much of the period after 2016, supplies context missing from the farewell notice. A GitHub transfer can move a repository. It cannot transfer memory of the codebase, review ability, release credibility or a commitment to stay for several more years.

“i tried that once already and then the new people i brought in faded and left me holding the bag again”

Source - dktapps in the PocketMine-MP Discord, July 15, 2026 in Vietnam

Dylan then said training somebody to take over costs substantial time and energy. He also did not believe anyone at that moment was serious enough to stay long enough to justify that investment, and did not want to hand his legacy to a random person who might lower its quality. That is Dylan's judgment, not proof that the community can never produce a capable successor. It is nevertheless the judgment of someone who says he had already paid the cost of a failed succession attempt, so it cannot be dismissed as simple possessiveness.

“the community needs to start figuring this stuff out and fending for itself instead of waiting for the messiah to save y'all”

Source - dktapps in the PocketMine-MP Discord, July 15, 2026 in Vietnam

Before that sentence, Dylan said he had considered giving control to IvanCraft623, a core contributor and member of the PMMP organization. In his 2024 retirement issue, Dylan named Ivan among five people given access to code needed for future maintenance and game updates. The consideration of Ivan shows that individual succession was evaluated before the archive. The final choice was still not to build another centre of authority around a person appointed from above.

“shoghi didn't hand over control, that's why pmmp exists, we had to create a new team”

Source - dktapps in the PocketMine-MP Discord, July 15, 2026 in Vietnam

The two moments, ten years apart, form a useful symmetry without being identical. In 2016, the PMMP group had to establish a new organization and infrastructure because Shoghi did not make a clean transfer of control. In 2026, PMMP archived its upstream, but the LGPL-3.0 source, releases and update documentation remained, while Dylan explicitly told the community to fork. Both moments could produce a new team. The difference is that the community was locked out of the old infrastructure the first time, while the upstream was deliberately closed so the next branches would have to prove themselves the second.

“i think it's better that people fork and figure out how to do this stuff without my supervision”

Source - dktapps in the PocketMine-MP Discord, July 15, 2026 in Vietnam

Dylan continued that supervision would constantly tempt him to come back and boss people around. That makes the archive a governance boundary, not only an act of giving up. If the old upstream retained its authority and every fork still sought his approval, he could remain its unofficial manager after retiring. Archiving breaks that loop. It ends PMMP as an upstream organization, but also forces the next branches to prove their ability instead of borrowing dktapps' credibility.

A day earlier in the support channel, dktapps told a member working on a fork that he had seen many low-quality forks appear and disappear over ten years. In his view, the serious team's advantage was not preventing copying. It was being first and understanding enough to support users when things broke. A branch that only copied files would remain in catch-up mode, hoping it had not missed something.

Fork and star counts immediately after an archive therefore measure attention, not succession. A new upstream must sustain updates, review changes, handle security, publish binaries, retain plugin developers and answer when servers break. If a fork eventually does those jobs and earns trust, it will not make this history look foolish. It will show that the community did what Dylan asked and learned to stand without waiting for an upstream-appointed heir.

PocketMine, PocketMine-MP and PMMP

PocketMine was the original project and organization associated with Shoghi. PocketMine-MP was the server software. The MP suffix referred to multiplayer. PMMP was the organization created in 2016 to continue PocketMine-MP, and it became the community's short name for the software and its newer ecosystem.

Saying “PMMP was a fork of PocketMine-MP” is technically understandable in Git and infrastructure terms, but misleading if it suggests a competing product like Genisys. The PMMP team carried PocketMine-MP's code history into infrastructure it could govern, then received recognition from the original founder as the successor.

In everyday use, “PocketMine” could mean any core descended from this family. An operator saying “my PocketMine server” in 2017 might actually have been running Genisys. A plugin advertising “PocketMine API 2” might accidentally rely on behaviour only ImagicalMine preserved. A network whose /about command reported Steadfast still carried PocketMine history underneath. The name identifies a family, not guaranteed compatibility.

An incomplete map of memorable forks

  • Genisys prioritized features and immediate usability while the old PocketMine upstream slowed. It became one of the most visible choices around MCPE 0.14-1.0 and produced descendants such as GenisysPro.
  • ClearSky occupied the same era, offering builds for newer clients and more gameplay than the old core. Its name frequently appeared in tutorials, hosting panels and questions about which core to choose.
  • ImagicalMine was another fork from the fragmentation period, with its own documentation and operator-oriented changes. Its surviving Read the Docs pages show how a project can disappear while its instructions remain in search results for years.
  • RedstoneLamp belonged to the cluster of names a newcomer encountered while looking for support for a new MCPE release. Its repository history is less complete than PMMP's, an example of how vanished code hosting makes family trees difficult to reconstruct.
  • Steadfast and Steadfast2 were associated with Lifeboat, descended from old PocketMine and backported the protocol and features that the network needed. They demonstrated that a commercial private fork could evolve under different incentives from a public upstream.
  • Nukkit was not merely a PHP fork of PocketMine, but a Java server shaped by the same early MCPE-server demand. It showed that the unmet need was large enough for several independent implementations to emerge.

This list is not a contest with one winner. Each project answered a different pressure. Support the newest client immediately, preserve old plugins, add mobs, improve performance, serve a private network or clean up the API. Confusion began when users assumed every related name could replace every other one without losing plugins or data.

Forks also kept knowledge alive. Without PMMP in 2016, another fork might have become the practical upstream. Yet forks dispersed maintainers, bug reports and plugin targets at the same time. If five projects patch the same protocol in private branches, the community repeats one job five times and can still finish without a common reference.

Poggit, PHAR and a plugin's lifecycle

A PocketMine-MP plugin normally used plugin.yml to declare its name, version, main class, compatible API, commands, permissions and dependencies. Source could run from a folder during development, while releases were usually packaged as .phar files and placed in the plugins directory.

Early plugins were normally posted to PocketMine Forum or its old plugin repository. Operators downloaded an attached PHAR. Sometimes the source was on GitHub and sometimes it was not. Files were mirrored through MediaFire, Dropbox, blogs and YouTube descriptions. When a link died, an entire plugin could disappear even after hundreds of servers had depended on it.

DevTools supported folder-based development, skeleton generation and PHAR builds. ExamplePlugin showed a minimal structure for the current API. Virions were small libraries that could be bundled into plugins at build time. Together these tools formed a path from “where does a plugin begin?” to a release another operator could install.

Poggit turned a GitHub repository into a downloadable artifact while preserving the path back to source. It did not make every plugin safe or permanently maintained, but it provided a more consistent release route than binaries passed through temporary file hosts. Requiring source for public releases mattered in an ecosystem full of young developers, abandoned plugins and servers that had to port their own stack after every major API change.

What old plugins reveal about the servers people actually wanted

The download list in Poggit Orphanage is an archaeological record of operator demand. EconomyAPI became more than a simple money plugin because shops, land and jobs plugins built on it. PurePerms and PureChat supplied groups, permissions and prefixes. WorldProtect, ManyWorlds, AlwaysSpawn and SignPortal filled administrative functions that operators considered basic.

Those plugins also show why PocketMine's missing gameplay was not only a defect. Because the core did not impose one complicated economy or permission system, communities assembled their own stacks. Two servers on the same PocketMine release could differ completely in commands, ranks and storage. That freedom encouraged experimentation, but it made dependency graphs fragile. The disappearance of one economy plugin could break five others.

Poggit Orphanage was a social response to that fragility. When an author no longer maintained a project, its repository could move to a shared organization where another contributor could merge compatibility fixes. The model was imperfect. Review capacity remained finite, and understanding old business logic was difficult. It was still better than allowing the final binary to disappear with its author's account.

Why PHAR was both convenient and deceptive

To an operator, a PHAR made a plugin feel like a finished product. Download the file, place it in a directory, restart and watch the console. A PHAR is only an executable PHP archive. It can contain readable source, bundled dependencies, metadata and anything else its author wrote. Without a repository, build instructions and a release tag, users cannot easily identify the commit from which a file came.

Poggit-CI made the route from commit to PHAR more inspectable. Many servers nevertheless relied on Discord builds, private forks or binaries that had passed through several hands. That became serious during a vulnerability, backdoor investigation or API migration. “A file still runs” is not the same statement as “the project is still alive.”

Why PocketMine-MP plugins broke after updates

A plugin declared the API versions it supported. If the server API was incompatible, PMMP refused to load it instead of pretending everything was fine. That was annoying when an old plugin needed only a small fix, but it prevented code written for removed classes, methods or behavior from failing silently on a new server.

Three forces drove change. Minecraft Bedrock kept changing packets and gameplay data. PHP added language features and removed old approaches. PMMP itself had to pay technical debt so the core remained testable and maintainable. Major releases such as 3.0, 4.0 and 5.0 concentrated incompatible changes at recognizable boundaries, but each plugin maintainer still paid the porting cost.

Changing only the API number in plugin.yml was not always an update. A plugin using renamed methods, internal networking, obsolete NBT or accidental behavior needed to be read and repaired. Old support threads are full of “can I just bump the API?” because the distance between source code still existing and someone still understanding it is enormous.

A 2018 answer by SOFe separated the causes into technical debt inherited from old PocketMine code, changes in Minecraft itself and changes in PHP. All three layers could arrive together. A plugin calling an old core method, running on a new PHP and handling a packet Bedrock had replaced would not have a magical one-line repair.

From API 2 to API 3

This migration added scalar type hints and return types to many interfaces. A changed signature for onCommand() or Task::onRun() alone could make PHP reject a plugin implementing the old method. Network classes, entities, tiles, chunks, NBT and the scheduler were cleaned up. Plugins reaching into internal packet code suffered most because internals were never a compatibility promise.

Operators often opened plugin.yml, changed api: 2.0.0 to 3.0.0 and felt cheated when the server still refused it. In practice, refusing the plugin before loading was kinder than allowing it to enter the server, mishandle an inventory transaction and lose players' items. An irritating compatibility gate was preferable to silent corruption.

From API 3 to API 4 and API 5

PM4 changed the world model, blocks, items, players, commands and many dependencies. A plugin might need new namespaces, object types and ways to access worlds. PM5 modernized block states and item data again. A plugin using only common events could be ported quickly. A plugin implementing custom blocks, packet handling, inventory transactions or world conversion could require a substantial rewrite.

Compatibility was also a network problem in the mathematical sense. If SkyWars existed only for PM3 while a required mob plugin existed only for PM4, an operator could not install both through determination alone. They had to port one plugin, replace their stack or keep the old core. Every major API divided the ecosystem into islands until the important plugins caught up.

Why PMMP accepted the pain

Permanent compatibility sounds friendly, but moves its cost into the core. Broken methods can never disappear, old data models must coexist with new ones, bugs become behaviour on which plugins depend and maintainers must understand every historical layer. For a small team chasing a new protocol, that is a slow route to the same death.

PMMP chose explicit major releases, deprecations where practical and rejection of incompatible APIs. The choice produced recurring complaints, but also let PHPStan, strict types and tests catch failures earlier. The project survived nearly fourteen years partly because it was willing to discard baggage, not in spite of doing so.

Why PocketMine-MP ended support

The direct cause was human

The official announcement was specific. A key maintainer left, and nobody else on the team was willing to perform updates for new Minecraft versions. No single technical defect made the source impossible to run. No public legal order forced the repository closed. The project exhausted its upstream maintenance capacity before it exhausted its ability to exist on disk.

This is a familiar open-source failure mode. Thousands of servers can depend on a project while the hardest responsibility remains concentrated in a few people. Downloads do not turn into review time. Profitable servers do not automatically produce maintainer salaries. Every game release creates another deadline that volunteers do not control.

“Nobody is willing” is also different from “nobody is intelligent enough.” Maintainer access had been distributed. Update documentation existed. The source and tools remained. What disappeared was the rare combination of time, expertise, technical access, release responsibility and desire to keep serving a game that its maintainers might have stopped loving years earlier.

The structural cause was the cost of following a closed platform

PMMP reimplemented a game its team did not own. Bedrock could change packets, block states, item data, authentication and world formats on Mojang's schedule. When documentation was missing or wrong, maintainers observed clients, traced packets, analyzed BDS and built data-generation tools.

The loss of public debugging symbols after 1.21.40 did not delete PMMP. It narrowed the group capable of performing the update. A server partner with the required build had an advantage an independent developer did not. When people holding both the skill and access left, replacement became much harder than the phrase “someone can always fork it” suggests.

Bedrock also updates automatically on most mobile and console devices. An operator cannot expect the entire audience to freeze on one client release as a modded Java community sometimes can. A delay of days loses traffic. A delay of weeks can lose a community. Mojang's release rhythm became a compulsory work schedule for PMMP volunteers.

The economic cause was a commons used more than it was sustained

Server networks could earn money from ranks, passes, cosmetics, advertising or Marketplace relationships. Hosts sold PocketMine plans. Developers sold private plugins. Video creators built tutorial audiences. PMMP supported all of those economic activities, but only a small and unstable share of the value returned to core maintainers.

Lifeboat was the positive exception because it paid for work that remained useful to everyone. The fact that this exception stands out tells us what the normal arrangement looked like. Most beneficiaries had an incentive to wait for somebody else to finance the upstream. When everybody waited, maintainers carried the cost as a moral duty toward an ecosystem they did not own.

Did Mojang contribute to the death of PocketMine-MP?

A “kill order” is not required to produce a killing result

This question is usually forced into two simplistic choices. Either a Microsoft email ordered PMMP to close, or Mojang bears no responsibility at all. Real platform history lives between those poles. A company can leave a project technically legal while changing the surrounding conditions until independent continuation becomes steadily less viable.

There is no public trace of a cease-and-desist against the PocketMine-MP core or an instruction to archive the repository in 2026. There is, however, a thirteen-year sequence of observable events.

  • In 2013, Mojang directly asked PocketMine Realms to stop, while opening official external-server connections in return.
  • In late 2015, Shoghi stopped PocketMine because it conflicted with his work at Mojang, and the infrastructure was not handed over cleanly.
  • In 2019, symbols disappeared from the client, reverse engineering became harder and dktapps described independent servers as collateral damage.
  • BDS later served as the replacement source, until symbol-bearing builds also disappeared from public access beginning with 1.21.40.
  • Protocol documentation remained insufficient for all required data, leaving independent servers dependent on Minecraft partners.
  • Bedrock's update rhythm kept demanding fast compatibility while community maintainers lacked stable compensation.

Each event can be explained individually through product, security or organizational priorities. Together they produce a consistent force. The power to understand and extend Bedrock shifted gradually away from the public and toward Mojang and selected partners. PocketMine was not struck by one bullet. Its room to breathe was narrowed layer by layer.

How should the Shoghi, Mojang and Realms theory be read?

A 2016 forum history theorized that Mojang prevented Shoghi from continuing because of Realms. No public record reveals the precise language of his contract or the internal conversation. Yet “we do not know the wording” is not the same as “the theory has no foundation.” Mojang had previously intervened in PocketMine Realms. Shoghi later became a Mojang employee. PMMP documentation confirms that he was forced to stop because of a work conflict. Infrastructure concentrated around him was then left where the rest of the team could not govern it.

The most persuasive reading is that a real conflict existed and was tied to Shoghi's dual position. Realms may have been the entire cause, or merely the clearest symbol visible to outsiders. The lack of detail could reflect confidentiality obligations, a desire to avoid dispute or a personal choice not to tell the story. Silence does not prove every community theory. It does not erase the structure of interests already in view either.

From collateral damage to partner-only access

In 2019, dktapps believed Mojang was targeting hackers rather than servers and that independent implementations suffered as a side effect. That explanation does not absolve the result. If a company knows a security change will damage a legitimate ecosystem, proceeds anyway and does not provide an adequate documented alternative, the damage remains a consequence of the company's choice.

Once symbols became accessible only through partners, the boundary became economic and political. A selected network possessed access useful for maintaining software. An independent developer had to request data, depend on goodwill or reverse engineer a more hostile binary. This was not an open field in which the best code simply won. It was a gated ecosystem, and the gatekeeper decided who could see the map.

The most reasonable conclusion

Mojang was not the sole author of PMMP's death. Bus factor, technical debt, burnout, weak funding and community governance choices all mattered. Saying that Mojang was uninvolved only because it never published a notice reading “we are closing PocketMine” is nevertheless an impoverished account.

Mojang's decisions helped create an environment in which independent servers had to perform more reverse engineering, received less public technical information and raced against an update schedule they did not control. When the final maintainers left, the project broke precisely at that pressure point. The fair conclusion is not that Mojang secretly ordered PMMP killed. It is that Mojang designed and narrowed Bedrock in ways that made a project like PMMP progressively harder to succeed.

The broader argument appears in Minecraft Bedrock is killing the things that helped it grow. This page stays focused on PocketMine-MP's history and mechanics.

Is PocketMine-MP dead?

If PocketMine-MP means the upstream updated by the PMMP team for each new Bedrock release, yes. That work has ended. The main repository is read-only, and the official announcement says there will be no more updates.

If PocketMine-MP means all of the source, plugins, documentation, running servers and community it created, no. Release 5.44.3 still works with compatible clients. LGPL-3.0 source can be forked. The update process is documented. Networks with their own forks do not disappear because the upstream was archived.

The problem begins when the next incompatible Minecraft client arrives. A server may hold an old client version for a while, use proxies or backport within limits, but mobile and console players cannot be expected to remain on one release forever. A successor must maintain protocol, data, PHP builds, security fixes, plugins and trust that someone will also make the next release.

It helps to separate four kinds of death. A repository dies when it receives no more commits. An upstream dies when nobody publishes releases. An ecosystem dies when plugins, hosts and developers stop following it. Memory dies when links, forums, binaries and personal accounts disappear. PMMP is dead at the upstream layer. The other layers remain alive at different speeds.

How long can a 5.44.3 server keep running?

Technically, it can run for years if the matching client, PHP binary, operating system and dependencies are preserved. Communities still revive servers for PE 0.8, 0.11 and 0.15 through archives, forks and old APKs. Even in 2026, people search for PocketMine 0.15.10, patch it for modern Android and ask how to build an offline server. Software does not decompose on a calendar.

The difficulty is Bedrock distribution. Mobile stores push new clients. Consoles restrict custom server entry and version rollback. Authentication endpoints can change. Operating systems drop compatibility. Preserving an old server therefore means preserving a path for players to connect, not merely placing one ZIP in cold storage.

A successor fork needs more than a name and logo

Pressing Fork on GitHub copies code in seconds. Building a new upstream requires trusted maintainers, CI, PHP binaries, release signing, security response, protocol expertise, plugin coordination, documentation and relationships with people who possess Bedrock data. It also requires governance rules that avoid concentrating every important key in one account again.

A successor must choose its compatibility boundary. Keeping API 5 protects current plugins but limits refactoring. Creating API 6 opens room to clean the core but may fragment the ecosystem at its weakest moment. Deeper vanilla behaviour costs more people. A minigame focus makes the scope more realistic but abandons survival operators. None of these choices is neutral.

The technical and community legacy

The obvious legacy is code. Nearly 19,000 commits in the current repository, more than 400 releases, and packages such as RakLib, BedrockProtocol, NBT, Math, Snooze, Log, BedrockData and the upgrade schemas preserve a large body of knowledge about Bedrock server behavior.

The larger legacy is people. PocketMine-MP turned server development from an opaque idea into something people could download, run, break and repair. It led students and small operators into PHP, GitHub, Linux, VPS hosting, networking, databases, continuous integration, code review and open source. Not everyone became a professional developer, but many first learned that software was not a black box.

It also left a governance lesson. A project needs more than an open license. It needs shared access, reproducible builds, documentation for difficult work, funding that does not close the source, and several people capable of making decisions. PocketMine nearly lost its path because infrastructure was concentrated in one account. PMMP later ended when version-update capacity was concentrated in too few people. The events were a decade apart and pointed to the same bus-factor problem.

Lifeboat's place in the farewell deserves preservation. The network could have funded a closed fork only for itself, but it allowed the work Dylan and the team performed to remain public. It is a clear example of commercial interest and shared infrastructure coexisting.

The legacy of learning by repairing plugins

Many PocketMine developers did not begin with a computer-science curriculum. They wanted a new command, a different message, a rank system or a fix for a plugin that no longer loaded. They opened a PHP file, copied an event listener, met a namespace error and searched the forum. From a small practical need, they learned object-oriented programming, Git, SQL, asynchronous tasks and networking.

That education was messy and produced plenty of bad code, but it was democratic. A teenager did not need permission from a game studio to change the rules. Their server became a laboratory. The forums could be blunt, but public code and public answers allowed beginners to move from copying snippets toward understanding systems.

The legacy of protocol knowledge as a public resource

BedrockProtocol, BedrockData and dump tools did more than support PMMP. They recorded packet structures, enums, items, blocks and upgrade schemas that official documentation could omit or misdescribe. Dktapps argued that the PMMP implementation itself served as protocol documentation. An encoder tested through millions of real connections is a form of living specification.

Archiving the upstream does not erase that value, but the record freezes at its final version unless somebody continues it. Every unrecorded Bedrock update widens the distance between public history and the current protocol. Losing PMMP therefore means more than losing one server option. The community has lost an institution that observed Bedrock from the outside.

What the Internet has already lost

Writing PocketMine history is difficult not because nobody spoke, but because they spoke on forums that closed, Discord channels that search engines cannot index, websites that changed domains, Jenkins instances that were replaced, file hosts that expired and repositories that were deleted. A tutorial with hundreds of thousands of views can point to a binary that no longer exists. A widely used plugin may survive only as a fork with unclear origins.

Old PocketMine Forum was once kept “for historical purposes,” but not every asset or attachment survived. PMMP Forums are fortunate to remain read-only. The Wayback Machine preserved PocketMine Realms. GitHub kept commits and releases. Poggit kept plugin source. Each service preserves a different part, and none preserves the community's whole life.

Discord makes knowledge fast and temporary. A search engine cannot cite a discussion from a deleted channel. Later writers may conclude that no evidence exists and retreat to official announcements, even though social evidence once existed but the platform architecture made it inaccessible. “Not on Google” does not mean “never happened.”

What should be preserved now

  • Release PHARs, PHP binaries and checksums for important Minecraft versions.
  • Plugin repositories with tags, artifacts and dependencies rather than only the last downloadable file.
  • Historically useful forum threads, announcements and attached images.
  • Protocol-update documents, dump tools, schemas and build instructions before their original links move.
  • Accounts from maintainers, network operators, plugin developers and moderators before memory collapses into a short timeline.

Preservation is not worship of the past. It reduces the amount of work a successor must invent again. A new fork can learn why an API was removed, avoid repeating repaired bugs and distinguish choices forced by historical limits from universal engineering truths.

What may happen after PMMP

The first possibility is a community successor fork. The difficult part is not clicking Fork on GitHub. It is assembling maintainers with protocol experience, access to required data, release infrastructure and a review process. A new name does not provide those conditions.

The second is continued private forks at large networks. That keeps their servers alive but risks fragmenting or closing knowledge. When useful changes do not return to a shared upstream, smaller operators must repeat the work or stop.

The third is migration toward BDS extensions, other server software or proxy architectures. There is no automatic path. APIs, gameplay models and threading assumptions differ. A PMMP plugin cannot run on BDS by changing a file extension.

The realistic future may combine all three. Some public forks, some commercial forks, old servers remaining on 5.44.3, and developers moving elsewhere. PocketMine-MP may not return as one upstream, but its code and people will continue appearing across the Bedrock ecosystem.

The most concerning future is still the model Dylan described in 2024. Networks with money quietly move forward while the public commons stops. Bedrock would still have customized servers, but the ability to build one at scale would increasingly belong to organizations that already possess capital, partner access and private tooling. PocketMine's legacy was lowering the gate. The post-PMMP world risks raising it again.

A history that should not end with “deprecated”

Treating PocketMine-MP as an obsolete package misses the important story. It appeared before official external servers, reconstructed the protocol, helped the first MCPE networks grow, survived a founder crisis, fork fragmentation, three API reconstructions and almost fourteen years of updates to a closed game.

Its history also shows open source as both powerful and vulnerable. Open code allowed PMMP to revive in 2016. Centralized infrastructure almost stranded the community. Lifeboat funding extended the upstream. Narrower technical access made successors rarer. No single factor tells the entire story.

PocketMine-MP did not die because PHP suddenly stopped executing. It ended because the system of people, money and information around the code no longer produced the conditions for one more version. That is why this history is worth preserving. It is not only about Minecraft. It is about who may understand a platform, who pays the cost of freedom and what happens when an entire ecosystem uses a commons that only a few people still sustain.

Sources and verification method

This article does not treat official material as the ceiling of truth. Announcements, releases and commits are strong tools for fixing dates. Contemporary forum discussions show what the community observed, suspected and endured. The sequence of events, institutional interests, silences and later outcomes together support the most coherent explanation.

An inference does not become weak merely because the organization concerned never published it. An official statement does not become complete merely because the correct logo appears above it. This article separates what was stated, what can be observed and what is argued, but allows those layers to form a conclusion instead of using the absence of internal documents as a reason to stop thinking.

Quick reference after the long read Common PocketMine-MP questions
What is PocketMine-MP?

PocketMine-MP, commonly shortened to PMMP, is open-source Minecraft Bedrock Edition server software rebuilt primarily in PHP. It accepts Bedrock clients, implements its own world and gameplay systems, and provides an API for extending the server with plugins.

Is PocketMine-MP the official Bedrock Dedicated Server?

No. PocketMine-MP is neither a modification of nor a wrapper around Bedrock Dedicated Server. Both accept Bedrock clients, but they have separate codebases, gameplay implementations and extension systems.

Is PocketMine-MP dead?

The PMMP team stopped providing updates for new Minecraft versions and archived the main repository on July 9, 2026. The source, releases and documentation remain open, so compatible servers can still run and a new fork can continue the project.

Why did PocketMine-MP end support?

The direct reason was that nobody left on the team was willing to update the software for new Minecraft versions. After the archive, dktapps said a previous succession attempt had left him carrying the project again, so he chose community forks over lending the upstream's authority to one appointed individual.

What kinds of servers was PocketMine-MP best for?

PocketMine-MP was best suited to heavily customized servers such as minigames, lobbies, prison, skyblock and networks with their own rules. Bedrock Dedicated Server is usually a better fit when the goal is vanilla-like survival.

What was PocketMine Realms?

PocketMine Realms was a 2013 service that let players discover and connect to PocketMine-MP servers through the Realms interface before Minecraft PE had an official external-server button. It closed at Mojang's request when MCPE 0.7.4 added direct IP and port entry.

How did PocketMine, PocketMine-MP and PMMP differ?

PocketMine was the original project and organization, PocketMine-MP was the server software, and PMMP was the organization formed in 2016 to continue it on new infrastructure. The original founder later recognized PMMP as PocketMine-MP's successor.

Did Mojang contribute to the end of PocketMine-MP?

Yes, structurally, although no public direct shutdown order is known. Protocol changes, reduced access to debugging symbols and useful data shifting toward partners made independent updates harder, while the immediate cause remained the absence of maintainers willing to continue.

- NhanAZ - 30.06.2026, expanded 15.07.2026