tortoise-deploy

A Docker setup for Tortoise-WoW

Tip

Also check out my similar Docker setups:

• vmangos-deploy for VMaNGOS, a progressive Vanilla server emulator that aims to eventually support all versions from 1.2.4.4222 to 1.12.1.5875.
• cmangos-deploy for CMaNGOS, a server emulator that supports Vanilla (which CMaNGOS calls Classic), TBC and WotLK.

tortoise-deploy is a Docker-based solution for running Tortoise-WoW that focuses on providing a streamlined and user-friendly experience. It offers a range of features that simplify managing a Tortoise-WoW setup:

• Prebuilt Docker images for both amd64 and arm64, leveraging GitHub Actions: simply pull the provided images that have been optimized for size, performance and stability instead of having to re-compile Tortoise-WoW yourself every time you want to update.
• Multiple variants to choose from: the base images contain Tortoise-WoW alone, while the modules images add a curated set of modules on top. modules-bots adds TortoiseBots, a Playerbot module, to that set.
• Seamless, automated database migrations: when pulling the latest Docker images and re-creating the containers, migrations are applied automatically to keep your databases up to date at all times.
• A transparent and easy-to-follow user experience: the number of different commands that need to be run to install and manage Tortoise-WoW is kept to a minimum. You can use the Docker CLI or any other tool that is able to manage Docker containers.
• A clean and organized structure: the Tortoise-WoW configuration can be found in config/, everything else that is shared between the Docker containers and your host system lives inside storage/.

Note

The Docker images are built on a daily schedule, unless there have been no new commits since the last build, either to Tortoise-WoW or to the modules an image bundles. Every Monday, the latest images are rebuilt to ensure software and dependencies are up to date, even if there have been no updates to Tortoise-WoW itself.

Table of contents

• Install
  • Dependencies
  • Using a coding agent
  • Instructions
    • Cloning the repository and adjusting the Tortoise-WoW configuration
    • Adjusting the Docker Compose configuration
    • Using the modules images (optional)
    • Using the modules-bots images (optional)
    • Extracting the client data
    • Verifying existing extracted data
    • A note on Warden
    • Modifying the world database with custom changes (optional)
• Usage
  • Starting Tortoise-WoW
  • Observing the Tortoise-WoW output
  • Creating the first account
  • Stopping Tortoise-WoW
  • Updating
    • What happens during an update
    • When tortoise-deploy asks you to apply changes manually
    • Breaking changes
  • Creating database backups
    • Restoring a backup
  • Accessing the database
  • Database security
• Maintainer
• Contribute
• Licenses
• Disclaimer

Install

Dependencies

• Docker (including Compose V2)

Using a coding agent

If you have a coding agent like Claude Code or Codex installed, you can try a prompt similar to the following one to have it assist you with the installation process:

Help me install and set up https://github.com/mserajnik/tortoise-deploy.
First, clone the repository and read the README carefully.
Then guide me through the installation process step by step, following the
README closely.
Do as much of the setup yourself as you safely can so that I only have to step
in when a manual action or personal preference is required.
Ask me about my preferences whenever a choice has to be made, explain the
relevant options clearly, and tailor your instructions to the OS I am using.
Assume that I am not familiar with Tortoise-WoW or Docker and that I have not
read the README myself.
For steps that I need to perform manually, give me clear instructions and exact
commands where appropriate.
Do not assume user-facing choices such as the image variant, optional services,
or networking-related preferences. Ask me whenever the README presents a
meaningful choice.
For settings that the README, the Docker Compose configuration, or the
Tortoise-WoW example configuration files indicate should generally be left
alone, keep the documented defaults unless I explicitly ask for something else.
Do not change settings that the README, the Docker Compose configuration, or
the Tortoise-WoW example configuration files indicate should not be changed.

The exact prompt that works best may vary depending on the coding agent and model you use.

Caution

You use coding agents at your own risk. You are responsible for the permissions and access you give them. The maintainer of this project is not liable for any damage or data loss resulting from their use. Take appropriate precautions such as sandboxed access and limited permissions, and do not run them with --yolo or similar options that bypass safety checks.

Instructions

Cloning the repository and adjusting the Tortoise-WoW configuration

First, clone the repository and create copies of the provided Tortoise-WoW example configuration files:

git clone https://github.com/mserajnik/tortoise-deploy.git
cd tortoise-deploy
cp ./config/mangosd.conf.example ./config/mangosd.conf
cp ./config/realmd.conf.example ./config/realmd.conf

If you intend to use the modules variant (see Using the modules images (optional)), also copy a configuration file for every bundled module:

cp ./config/modules/tw-mod-autoscale.conf.example ./config/modules/tw-mod-autoscale.conf
cp ./config/modules/tw-mod-leech.conf.example ./config/modules/tw-mod-leech.conf

For the modules-bots variant (see Using the modules-bots images (optional)), copy those two as well, plus this variant's own two files:

cp ./config/modules-bots/aiplayerbot.conf.example ./config/modules-bots/aiplayerbot.conf
cp ./config/modules-bots/tortoise_bots.conf.example ./config/modules-bots/tortoise_bots.conf

Next, adjust the configuration files you have just created for your desired setup. The default configuration should work well as a starting point, but you may still want to adjust certain things such as the GameType or the RealmZone. Descriptions are provided for most options in the configuration files, so you should be able to find your way around easily.

Warning

Options relating to certain things that tortoise-deploy relies on to work correctly (like the database connections or configured directories such as the DataDir or the LogsDir) should not be adjusted unless you absolutely need to change them and are aware of the implications (e.g., which other configuration options may need to be adjusted as well to avoid discrepancies resulting in unexpected behavior). No support will be provided for non-default setups.

Adjusting the Docker Compose configuration

Once you are done adjusting the Tortoise-WoW configuration, the first thing to decide on is which image variant you want to use:

Variant	tortoise-server tag	tortoise-database tag
base	ghcr.io/mserajnik/tortoise-server:base	ghcr.io/mserajnik/tortoise-database:base
modules	ghcr.io/mserajnik/tortoise-server:modules	ghcr.io/mserajnik/tortoise-database:modules
modules-bots	ghcr.io/mserajnik/tortoise-server:modules-bots	ghcr.io/mserajnik/tortoise-database:modules-bots

All three variants come from the same Tortoise-WoW commit, the tip of the main branch, and each adds to the one before it. The modules variant is the base variant plus a curated set of bundled modules; Using the modules images (optional) describes what is in the set and what that variant additionally needs from you. The modules-bots variant is always the modules variant plus TortoiseBots, so everything the modules variant gives you is in it too; Using the modules-bots images (optional) describes what that adds.

Then copy the Docker Compose example file for your chosen variant to compose.yaml. For the base variant:

cp ./compose.yaml.example ./compose.yaml

For the modules variant, use compose-modules.yaml.example instead, and for the modules-bots variant, compose-modules-bots.yaml.example. The files share the same structure.

Warning

Switching between different variants is untested, unsupported, and highly discouraged. It may stop working at any point in the future without further notice. If you still want to attempt it, the following options should work:

base and modules share the same database image, so switching between them should be safe in both directions.

Switching from base or modules to modules-bots should also work. modules-bots contains additional migrations on top, which puts your database in a state that does not match what base or modules expect. Switching back is not possible cleanly without manual database edits, and it might not work at all.

Alternatively, you can select specific images via the Tortoise-WoW commit hash they have been built from. To allow for this, the tortoise-server image (used by the realmd and mangosd services) and the tortoise-database image (used by the database service) have tags that combine the variant they belong to with the respective commit hash. All three variants come from the same commit, so the variant name is part of the tag. For example, for commit 5fafe43b576116c3aecde435c41c87a47864f943:

realmd / mangosd service image	database service image
ghcr.io/mserajnik/tortoise-server:base-5fafe43b576116c3aecde435c41c87a47864f943	ghcr.io/mserajnik/tortoise-database:base-5fafe43b576116c3aecde435c41c87a47864f943
ghcr.io/mserajnik/tortoise-server:modules-5fafe43b576116c3aecde435c41c87a47864f943	ghcr.io/mserajnik/tortoise-database:modules-5fafe43b576116c3aecde435c41c87a47864f943
ghcr.io/mserajnik/tortoise-server:modules-bots-5fafe43b576116c3aecde435c41c87a47864f943	ghcr.io/mserajnik/tortoise-database:modules-bots-5fafe43b576116c3aecde435c41c87a47864f943

Important

When you decide to select images via Tortoise-WoW commit hash you should always make sure to use the same one for the tortoise-server and the tortoise-database images so there are no potential discrepancies between code and data. It is not possible (or intended) to switch to images based on an older commit than the previous ones you used to perform a clean downgrade due to the database migrations.

Since the Docker images are generally built only once a day, it is unlikely that there will be a build for every single Tortoise-WoW commit. Older images are automatically deleted after 14 days; in practice, you should not rely on specific images staying available beyond the point in time when you originally pulled them. If you absolutely need images based on a specific Tortoise-WoW commit, you can always build them yourself instead.

Tip

You can find all the currently available tortoise-server and tortoise-database images here and here respectively.

Aside from which Docker images you want to use you mainly have to pay attention to the environment sections of each service configuration. In particular, you will want to adjust the TZ (time zone) environment variable for each service. The TORTOISE_REALMLIST_* environment variables of the database service should also be of interest; changing the TORTOISE_REALMLIST_ADDRESS to a LAN IP, a WAN IP or a domain name is required if you want to allow non-local connections.

Warning

Anything in your compose.yaml that is not commented or explicitly mentioned in this README, regardless of the section, is likely something you do not have to (or, in some cases, must not) change. Doing so may lead to unexpected behavior and is not supported.

Using the modules images (optional)

In August 2026, Tortoise-WoW moved its auto-scaling and leech features out of the core and into its module system. The base images carry no bundled modules, so they do not contain either feature.

Instead, tortoise-deploy offers the modules image variant. It is built from the same Tortoise-WoW commit as the base variant, with a curated set of modules compiled in. Currently, the set consists of those two features that were previously part of the core:

Module	Enabled by default
tw-mod-autoscale	No
tw-mod-leech	No

Each module is turned on in its own configuration file. Those files are read after config/mangosd.conf, so a setting there also overrides a leftover copy of the same setting in your config/mangosd.conf.

Important

A missing module configuration file stops mangosd during startup, naming the file it wanted, and Docker restarts it into the same failure. Adding a module to the set is therefore a breaking change, and one you have to act on before mangosd will start again. Such changes are listed in the Breaking changes section.

Using the modules-bots images (optional)

TortoiseBots is a native Playerbot module for Tortoise-WoW. It allows you to spawn bots from characters on your own account, populate the world with AI-controlled players that level, quest, group up and run dungeons, and simulate a living economy in the auction house.

The modules-bots variant is the modules variant with TortoiseBots compiled in on top, so it contains tw-mod-autoscale and tw-mod-leech as well. It is built from the same Tortoise-WoW commit as the other two.

Module	Enabled by default
TortoiseBots	No

TortoiseBots reads two configuration files, both under config/modules-bots/. tortoise_bots.conf contains the module's own settings and aiplayerbot.conf contains the bot behavior settings.

The former should not require any changes from the defaults. Depending on what you want to achieve, you have to configure the latter to varying degrees. Read TortoiseBots' own documentation to learn what you can do with the module and how to set it up for that.

Note

tortoise-deploy does not include optional TortoiseBots tools such as the observability dashboard.

Extracting the client data

Tortoise-WoW uses data that is generated from extracted client data to handle things like mob movement and line of sight. If you have already acquired this data previously, you can place it directly into storage/mangosd/extracted-data/ and skip the extraction below. Then check it as described in the Verifying existing extracted data section.

Warning

Tortoise-WoW targets an unmodified copy of the final Turtle WoW client 1.18.1.7272 with the 2026-04-12 hotfixes. Data extracted from a different version causes gameplay problems that look like Tortoise-WoW bugs. tortoise-deploy aborts the extraction when it detects an unsupported client version. It also refuses to start the server with pre-existing data from such a client in place.

To extract the data, first copy the contents of your client directory into storage/mangosd/client-data/. Next, simply run the following command:

docker run \
  -i \
  -v ./storage/mangosd/client-data:/opt/tortoise/storage/client-data \
  -v ./storage/mangosd/extracted-data:/opt/tortoise/storage/extracted-data \
  --rm \
  --user 1000:1000 \
  ghcr.io/mserajnik/tortoise-server:base \
  extract-client-data

There are two things to look out for here:

• If you are using a Linux host and your user's UID and GID are not 1000, change the --user argument to reflect your user's UID and GID. This will cause the user in the container to use the same UID and GID and prevent permission issues on the bind mounts. If you are on Windows or macOS, you can ignore this (or even remove the --user argument altogether, if you want to).
• Use the image for the variant you intend to run the server with. modules extracts exactly like base today, so either produces the same data. If that ever changes, using the matching image keeps your extraction correct. See the table further above in the Adjusting the Docker Compose configuration section.

Important

Extracting the data can take many hours (depending on your hardware). Some notices/errors during the process are normal and usually nothing to worry about (as long as the execution continues afterwards).

The extraction compares the DBC files it produces against hashes Tortoise-WoW publishes. That happens early, before the steps that take the bulk of the time. With an unsupported client version the run stops within minutes and leaves storage/mangosd/extracted-data/ as it was.

Once the extraction is finished you can find the data in storage/mangosd/extracted-data/. Note that you may want to re-run the process in the future if Tortoise-WoW makes changes (to benefit from potentially improved mob movement etc.). In case it becomes necessary to do so (e.g., if the extraction process changes), the Breaking changes section further below will be updated accordingly.

If you re-run the extraction, it will automatically detect previously extracted data and ask you if you want to continue (which will overwrite the old data). You can also skip this confirmation prompt (and force the re-extraction) by adding the --force flag to the extract-client-data command, like this:

docker run \
  -i \
  -v ./storage/mangosd/client-data:/opt/tortoise/storage/client-data \
  -v ./storage/mangosd/extracted-data:/opt/tortoise/storage/extracted-data \
  --rm \
  --user 1000:1000 \
  ghcr.io/mserajnik/tortoise-server:base \
  extract-client-data --force

Verifying existing extracted data

The extraction checks the data it produces, so this command is unnecessary after a run that completed without errors. Use it for data you extracted earlier or obtained from another source, to confirm it came from the supported client version before you start the server.

To check the data in storage/mangosd/extracted-data/, run:

docker run \
  -v ./storage/mangosd/extracted-data:/opt/tortoise/storage/extracted-data \
  --rm \
  --user 1000:1000 \
  ghcr.io/mserajnik/tortoise-server:base \
  verify-client-data

A note on Warden

The provided images are currently built without anticheat support. Warden in particular is not available: it relies on module files that are not distributed with Tortoise-WoW and are not maintained for its client, so it cannot be enabled in a way that would work reliably. The other, movement-based anticheat checks may be enabled in a future image once an upstream issue that currently affects them has been resolved; this note will be updated if and when that happens.

Modifying the world database with custom changes (optional)

If you want to make custom changes to the world database, it is recommended to do so using SQL files and placing them in storage/database/custom-sql/ (a bind mount for this directory is configured out-of-the-box). The files in this directory are processed on every startup, including after tortoise-deploy re-creates the world database to apply an upstream migration edit (see the What happens during an update section), so your changes survive that flow without manual intervention.

By default, all SQL files (files with a .sql extension) in that directory will be processed during each startup in alphabetical order. Thus, the SQL statements in your files have to be idempotent (i.e., they can be processed multiple times without causing issues).

You can find further details about this feature here.

Usage

Starting Tortoise-WoW

Once you are happy with the configuration and have extracted the client data, you can start Tortoise-WoW for the first time. To do so, run:

docker compose up -d

This pulls the Docker images first and afterwards automatically creates and starts the containers. During the first startup it might take a little longer until the server becomes available due to the initial database creation.

Warning

Make sure to not (accidentally) stop Tortoise-WoW before the database creation process has finished; otherwise, you will likely end up with a broken database and will have to delete and re-create it.

Observing the Tortoise-WoW output

Especially during the first startup you might want to follow the server output to know when Tortoise-WoW is up and running:

docker compose logs -f mangosd

Once you see the output World server is up and running! you know that the initialization process has finished and Tortoise-WoW is ready.

Creating the first account

To create the first account, attach to the mangosd container (make sure that the server is ready before attaching):

docker compose attach mangosd

After attaching, create the account and assign an account level:

account create <account-name> <account-password>
account set gmlevel <account-name> <account-level>

The available account levels are:

Level	Type
0	Player
1	Observer
2	Moderator
3	Developer
4	Administrator
5	"SigmaChad" (Tortoise-WoW naming for a super administrator)

E.g., to create an administrator account, set the account level to 4.

Note

Setting an account level above 0 grants elevated permissions, and some Game Master-specific behavior begins to apply to characters on that account; you can modify some of it via the GM.* options in your mangosd.conf. These options are inherited from upstream Tortoise-WoW and are tuned for actual Game Master usage rather than regular play (such characters start at level 60, spawn on GM Island, etc.).
Characters on an account above level 0 are also invulnerable and cannot be killed by damage. This is hardcoded and cannot be disabled via configuration; the in-game .god off command turns it off for the current session, but it is re-enabled on every login. Such accounts are thus not very suitable for regular gameplay, and it is recommended to use level 0 accounts instead.

When you are done, detach from the Docker container by pressing Ctrl+P and Ctrl+Q. You should now be able to log in to the game client with your newly created account.

Stopping Tortoise-WoW

To stop Tortoise-WoW, simply run:

docker compose down

Updating

To update, pull the latest images:

docker compose pull

Afterwards, re-create the containers:

docker compose up -d

Note

Selecting specific images via Tortoise-WoW commit hash (as described further above) will obviously prevent you from updating until you edit each respective service in your compose.yaml to pull newer images. Attempting to update without changing the configured images is not harmful, it will just not have any effect.

What happens during an update

When you re-create the containers with newer images, mangosd automatically applies any pending migrations at startup, so your databases are kept up to date without manual steps.

tortoise-deploy also detects upstream commits that edit already released migration files. Such changes would otherwise leave the affected database in an inconsistent state and require manual intervention to rectify.

By default, tortoise-deploy will automatically re-create your world database when a relevant change is detected. Your accounts, characters and saved game state (such as world event progress) live in separate databases that are not touched, so they are unaffected. Any changes you made directly to the world database (your custom NPCs and gameobjects, npc_vendor edits, etc.) are lost, so restore those from a backup if you need them back (or use custom SQL to cleanly preserve the additions/changes).

Databases that hold user state cannot be re-created that way without destroying your players' data, so for those tortoise-deploy halts startup instead and asks you to apply the change by hand; see the next section.

When tortoise-deploy asks you to apply changes manually

When a migration edit is detected that affects a database containing user state (or a world database edit with automatic corrections disabled), tortoise-deploy halts startup and prints a message naming the affected database(s) and the GitHub link(s) to the upstream commit(s).

Because the server services wait for the database to become healthy, docker compose up -d keeps waiting while startup is halted. Open a second terminal and run docker compose logs database to read the message, then run the commands below from there.

The container stays running while paused; nothing restarts on its own. To resolve:

1. Open each linked commit on GitHub and read the SQL changes it makes.
2. Apply the equivalent SQL to each affected database. From the host:

   docker compose exec database mariadb -u root -p <database>

   where <database> is the name in parentheses in the halt message. mariadb will prompt for the password; it matches your MARIADB_ROOT_PASSWORD setting in compose.yaml.
3. When you have applied the changes to all of them, confirm by running on the host:

   docker compose exec database tortoise-confirm-changes

tortoise-deploy will then record the acknowledgement and continue startup. If you instead want to abort, run docker compose down.

Warning

When you run tortoise-confirm-changes, tortoise-deploy treats the listed commits as applied and continues. It does not check your database to verify that the changes you made match what the commits describe. If your manual fix is incorrect or incomplete, the database will be in an inconsistent state and Tortoise-WoW may fail to start. The responsibility for matching what the commits do is yours; tortoise-deploy provides no further support for resolving these issues.

Breaking changes

It is recommended to regularly check this repository (either manually or by updating your local repository via git pull). Usually, the commits here will just consist of maintenance and potentially new Tortoise-WoW configuration options (that you may want to incorporate into your configuration).

Sometimes, there may be new features or changes that require manual intervention. Such breaking changes will be listed here (and removed again once they become irrelevant), sorted by newest first:

• [2026-09-19] - Extracted client data is now verified: tortoise-deploy now checks the extracted DBC files against hashes published by Tortoise-WoW, both when you extract and on every server start. A mismatch stops the extraction and keeps the server from starting. There is exactly one supported client version, the final Turtle WoW client 1.18.1.7272 with the 2026-04-12 hotfixes. Data from any other version produces gameplay problems that look like Tortoise-WoW bugs. Run verify-client-data as shown in the Verifying existing extracted data section to check your data. If it fails, obtain that version and re-run the extraction.
• [2026-09-14] - The image variants have been consolidated and renamed: the unstable and unstable-modules variants are no longer available. Tortoise-WoW now merges its 1181dev branch, which those variants were built from, into main every few days, so those images added little benefit at a high maintenance cost. The remaining variants have new names: stable is now base and stable-modules is now modules. The images behind the old tags have been deleted, so pulling one fails outright. Point every service in your compose.yaml at the new tag: from stable or unstable move to base, and from stable-modules or unstable-modules move to modules. latest now points at the base variant, so a setup that pulls latest keeps working. Coming from an unstable variant is safe: main was at or ahead of 1181dev when the new images were published, so every migration your old images applied is in the new ones too. Entries below this one predate the rename and use the old names.
• [2026-08-25] - Tortoise-WoW moved auto-scaling and leech out of the core: upstream removed both features from the core and reintroduced them as modules. If you had both features disabled, which was the default, nothing changes for you and you can simply delete the respective options from your config/mangosd.conf. If you had either one enabled, doing nothing means it stops working on your next pull, silently: the stable and unstable images no longer contain the code. To keep the feature, move to the matching -modules image, which means pointing the database service at its -modules tag as well, copying each module's configuration example into place and adding a bind mount for it, and tuning the settings in that copy rather than in config/mangosd.conf; see the Using the modules images (optional) section. Moving from a build to its -modules variant works as of this entry; moving back the other way is unsupported and is not guaranteed to work.
• [2026-08-19] - Startup now halts for migration edits it cannot apply for you: tortoise-deploy now also detects migration edits affecting databases that contain user state (in addition to the world database) and halts startup until you apply the equivalent SQL by hand; see the When tortoise-deploy asks you to apply changes manually section. To opt out of halting (tortoise-deploy will instead log a warning on every start until you set this back to 1 and resolve the edit), set TORTOISE_HALT_ON_MIGRATION_EDITS=0 in your compose.yaml. Halting also becomes the fallback for the world database when you have set TORTOISE_ENABLE_AUTOMATIC_WORLD_DB_CORRECTIONS=0, which previously only logged a warning. A halt lasts for as long as you need, so you may also want to raise the database service's healthcheck start_period to 24h, which keeps the container from being marked unhealthy while you work. See the updated example Compose configuration for the exact configuration.
• [2026-08-11] - Commit hash image tags now include the build name: tags that select an image by Tortoise-WoW commit hash have changed from <commit-hash> to <build>-<commit-hash> (e.g., ghcr.io/mserajnik/tortoise-server:stable-fee5caf96dbca685a1661a055e541a25fd8a4a60). Both branches can point at the same commit while their images differ, so the bare hash could not identify one of them. This only affects you if you select images by commit hash instead of by a moving tag. No new bare hash tags are published; the existing ones keep working until they are eventually deleted.
• [2026-07-28] - The suggested database backup solution has changed: the example Compose configuration now uses databack/mysql-backup instead of tiredofit/db-backup, whose repository has moved to a new organization that announced a release for April 2026 which never happened, leaving it unclear whether the project is still maintained. If you have the database-backup service enabled, replace it with the updated service configuration; none of the environment variables carry over. Existing backups stay readable, but the new service neither prunes nor restores them, so move or delete the old .sql.gz files once you no longer need them. New backups are written as a single .tgz archive per run that contains one .sql file per database.

Creating database backups

It is recommended to perform regular database backups, particularly before updating.

To automatically create database backups periodically, uncomment the database-backup service configuration in your compose.yaml and follow the comments for further information.

Once the service is enabled, you can also create a backup on demand by running the following (clearing DB_DUMP_CRON is necessary because a schedule and a one-off run cannot be combined):

docker compose run --rm -e DB_DUMP_CRON= -e DB_DUMP_ONCE=true database-backup

Restoring a backup

To restore a backup, first stop the realmd and mangosd services:

docker compose stop realmd mangosd

The restore drops and re-creates the tables in the affected databases, which would cause read and write errors in the running services and could leave the data in an unknown state. Then run the following, replacing the file name with the backup you want to restore:

docker compose run --rm database-backup restore --target /backup db_backup_<timestamp>.tgz

Finally, start the services again:

docker compose start realmd mangosd

Accessing the database

To make certain changes (e.g., managing accounts or changing the realm configuration) it can be necessary to access the database with a MySQL/MariaDB client.

A common web-based MySQL/MariaDB database administration tool called phpMyAdmin is included and can be enabled by uncommenting the phpmyadmin service configuration in your compose.yaml. See the comments there for further information.

Database security

It is not recommended to expose your database to the public (whether through direct port access, a WAN-accessible phpMyAdmin instance, or any other means). If you decide to do so, you will have to implement appropriate security measures. Please note that no further support or guidance regarding this will be provided here.

Caution

The default database users with full access to all Tortoise-WoW data (root and the user named via the MARIADB_USER environment variable) do not have any restrictions in place in regards to which IPs/hosts can connect.

Maintainer

Michael Serajnik

Contribute

You are welcome to help out!

Open an issue or make a pull request.

Licenses

• AGPL-3.0-or-later (Code)
• CC-BY-SA-4.0 (Documentation, graphic assets and issue templates)
• CC0-1.0 (Configuration files)

This project follows the REUSE specification.

Disclaimer

tortoise-deploy is an independent, community-made Docker setup for the open-source Tortoise-WoW project. It is not affiliated with, endorsed by, or sponsored by Blizzard Entertainment, Inc., and it is not an official Tortoise-WoW project.

This project includes no game client data or other copyrighted game assets. You must supply your own legitimate game client, from which the required data is extracted locally on your own machine. It is intended for private, non-commercial use only and comes with no warranty.