# Sapphire: a C++ Final Fantasy XIV server emulator kept as research code > Sapphire is a C++ reimplementation of the Final Fantasy XIV server side, targeting the 3.3 client from 2016 and licensed AGPL-3.0. Its own documentation calls it a research project that is insecure and incomplete, which tells you how to read every other claim about it. **SapphireServer/Sapphire** — A Final Fantasy XIV 4.0+ Server Emulator written in C++ - Repository: https://github.com/SapphireServer/Sapphire - Stars: 840 · Forks: 238 - Language: C++ - License: AGPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/sapphireserver-sapphire ## A server emulator that describes itself as research code Sapphire is a Final Fantasy XIV server emulator written in C++. The repository description calls it a server emulator for Final Fantasy XIV 4.0 and later, but the project page is more specific and considerably more cautious: it says the project is currently in development, that this branch is specifically for version 3.3, and that it is a research project to learn how retail servers work and currently not production code. That framing matters for an engineer deciding whether to build it. You are not looking at a drop-in private server. You are looking at a readable implementation of the server side of a large commercial MMO, with the schema, the configuration and the C++ sources in one tree, and with the explicit warning that many things are unimplemented or broken. The audience is therefore people who want to understand how a retail server works, or who want to modify it. The project says contributions are always welcome, and the presence of a CONTRIBUTING.md, a wiki and a Discord badge points to a community around that goal. Two facts frame everything else. The project is insecure by its own admission, so the documentation tells you to use throwaway passwords for accounts. And it cannot ship the game client, since Square Enix content cannot be redistributed, so the emulator is useless to you without a client you already own. ## The master branch still speaks the language of the 3.3 client The client target is pinned precisely. This branch currently targets FFXIV 3.3, with the game build recorded as 2016.07.05.0000.0001 and the expansion EX1 at 2016.05.21.0000.0001. Those identifiers are the point. A server emulator has to agree with the client on packet formats, on content identifiers and on database state, and the client from that era is roughly three years older than the current one. The project also points to a wiki page called Patch list for the full set of patch names, which suggests the compatibility story is expressed as a mapping between patches. Here is the discrepancy worth resolving before you commit an afternoon to it. The short repository description advertises Final Fantasy XIV 4.0 and later, while the documentation for this branch states 3.3. Those are different targets, and the branch document is the one that describes the code in front of you, so treat the branch as a 3.3 emulator. If you need a newer client, this master branch is the wrong thing to build, and nothing published here explains how the two version lines relate. There are also no tagged releases to sort this out. The repository has no GitHub releases at all, so there is no version history to diff against and no artefact to download. ## Building needs CMake, a C++17 compiler and MySQL 5.7 The dependency list is short enough to state completely, and it is explicit about the per-OS choices. A CMake 3.0.2 or newer with a C++17 capable compiler is required: Visual Studio 2022 on Windows, or gcc 7 and g++ 7 or newer on Linux. For the database the project expects MySQL Server 5.7, where Windows users are pointed at MariaDB 10.7 for x64 and Linux users at the MySQL server from their distribution's package manager. The project page does not print build commands. Instead it sends you to the wiki guide called Getting Started, under the installation and build instructions for your OS. That is where the CMake invocation, the build directory layout and the database setup steps live, and it is the first thing to read before cloning. What the repository tree tells you about the build is still informative. There is a CMakeLists.txt at the root, a CMakePresets.json for editor and CI presets, a cmake directory for helper modules, and a deps directory that is paired with a .gitmodules file, meaning some dependencies arrive as submodules rather than being vendored directly. There is also an .appveyor.yml, an older continuous integration service, and a build badge that points at a GitHub Actions workflow. Two CI systems for one project suggests the older one has not been retired, which is a small sign of how the project's tooling has aged. ## The tree shows a database-first server with a web component The layout of the source tree is the best available description of the architecture, since the documentation does not describe the internals. Six directories carry most of the weight: src for the C++ server code, sql for the database layer, config for configuration, data for data files, web for a web component, and doxygen for generated documentation. The sql directory and the sql_import.sh script at the root suggest that the database schema is a first-class part of the project rather than an afterthought. A script named for an import sitting next to a sql directory is how a research emulator gets a playable database without a tool to design one, and it also means the schema is the part you are most likely to have to adapt, since the MySQL 5.7 assumption constrains the types you can use. The web directory is the other structural hint. It suggests a component outside the game protocol, most plausibly an account or management surface, though nothing published describes what it serves or how to configure it, so the directory name is all you have to go on. For a reader trying to answer how retail servers work, that set of directories is a good map. For someone trying to get a working server, it is a promise that most of the effort sits in configuration and database setup rather than in the code. ## Insecure and incomplete is the documented default state The limitation section of this project is unusually clear, and it belongs in any honest evaluation. The documentation states that at this time the project is insecure and that you should use throwaway passwords for accounts, and that a lot of things are unimplemented or broken. There are two separate reasons to take that seriously. The first is security. A server emulator stores account credentials, character data and inventory in a database that you configure, and the project explicitly declines to promise that the authentication path is safe. Running it against credentials you care about is not a risk worth taking for a research tool. The second is coverage. A server emulator that implements a subset of the protocol is not a broken version of a finished thing, it is a partial implementation, and the two kinds of bug behave differently. Missing features produce errors you can see and work around. Incorrect feature behaviour produces a world that looks right and is subtly wrong, which is far more expensive to diagnose. The honest comparison is with the retail server itself. A retail server is production code with account security, support and years of accumulated fixes. Sapphire trades that for something a retail operator will never give you: the ability to read the server implementation, change it, and inspect the database directly. If you need a functioning game service, this is the wrong tool in a way that no amount of engineering effort on the branch will fix. ## AGPL-3.0 and a project with no releases to install The licence is AGPL-3.0, with the text in LICENSE.md at the repository root. That matters more than it does for a library, because the AGPL's copyleft reaches beyond your own source files to code you offer to users over a network. If you deploy a modified Sapphire as a service, the licensing obligations you inherit are wider than MIT or Apache-2.0 would give you. This is a reading of the licence terms, not legal advice, and for a commercial deployment your own counsel should look at it. The upgrade picture is the other half of the cost. There are no GitHub releases, so there is nothing to download and nothing to diff against. Every install is a clone, a submodule checkout, a CMake configure, a compiler run and a database import. The maintenance signal from the repository is a last push on 2026-10-05, which is recent in absolute terms and inside the six month window that would let you describe the project as actively maintained. The qualifier is what the branch is for. The project page still says the work is in development and describes it as a research project, so the code is moving without the guarantees that a release and a changelog would give you. Upgrading means pulling master and rebuilding, then checking what changed in a tree where the wiki, not the commit history, is the real documentation. ## The wiki is where the actual instructions live Almost nothing in this repository is a how-to. The project page is short by design: it states what the project is, names the client version, gives a dependency table, and then hands off. The guide names are a good index of what you will need. A wiki for getting started covers installation and build instructions for your OS, a resources page called Patch list carries the full list of patch names for the client versions, and other pages cover command lists, contribution details and development resources. The wiki lives at sapphire.xiv.dev, and there is a matching Discord community linked from the project page. One boundary is set explicitly and should be respected. The project states that it is not allowed to distribute the Final Fantasy XIV client or any related content, and asks that people not ask for links or binaries related to Final Fantasy XIV or Square Enix copyrighted content. In practice that means a build of Sapphire does not get you a playable game: the server side is what this repository provides, and the client has to come from somewhere you already have the rights to. So the honest first step for any new contributor is to read the Getting Started page, then look at the sql directory and the sql_import.sh script, and only then start a compiler run. The wiki carries the details the project page deliberately omits. ## Conclusion Sapphire suits people who want to read and modify a Final Fantasy XIV server implementation, and researchers who need a schema and packet layer they can experiment with locally. It is not a tool for a game service, a community server, or anyone with a real account, because the project states plainly that it is insecure and unfinished, and because it targets a 2016 client version rather than a current one. Before spending time on it, check three things: the wiki/Getting Started page for the build steps your OS actually needs, the sql directory and sql_import.sh for the database path you will have to get right, and the client version your own copy can talk to, since this branch targets 3.3 while the repository description advertises 4.0 and later. ## FAQ ### What does it take to build Sapphire? The project requires CMake 3.0.2 or newer with a C++17 capable compiler, which means Visual Studio 2022 on Windows or gcc 7 and g++ 7 or newer on Linux, plus MySQL Server 5.7, where Windows users are pointed at MariaDB 10.7 x64 and Linux users at their distribution's MySQL package. Detailed build steps live in the wiki's Getting Started page. ### Which Final Fantasy XIV version does this branch of Sapphire support? The documentation states that this branch currently targets FFXIV 3.3, with game build 2016.07.05.0000.0001 and EX1 2016.05.21.0000.0001. The repository's one line description advertises Final Fantasy XIV 4.0 and later, so check the wiki patch list before building. ### Is Sapphire safe to run with a real game account? No. The project states that it is currently insecure and tells you to use throwaway passwords for accounts, and it warns to expect many things unimplemented or broken. It is described as a research project and not production code. ### Can Sapphire provide the Final Fantasy XIV client? No. The project states it is not allowed to distribute the FFXIV client or any related content and asks not to be sent links or binaries for that content. Sapphire supplies the server side only. ### What database does Sapphire use and how is it set up? MySQL Server 5.7 is the documented dependency, with MariaDB 10.7 for x64 offered on Windows. The repository contains a sql directory and an sql_import.sh script at the root, and the project page does not describe how to run that import, so the Getting Started page in the wiki is the place to check. ## Sources - [Issues](https://github.com/SapphireServer/Sapphire/issues) - [License: AGPL-3.0](https://github.com/SapphireServer/Sapphire/blob/master/LICENSE) - [README](https://github.com/SapphireServer/Sapphire/blob/master/README.md) - [SapphireServer/Sapphire on GitHub](https://github.com/SapphireServer/Sapphire) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sapphireserver-sapphire