Set Up Doudizhu and Access It with Localtonet

What this Doudizhu deployment contains

Doudizhu, also known as Dou Dizhu, is a multiplayer card game. The repository covered by this guide describes an HTML5 implementation with a Python backend based on Tornado and MySQL. Its frontend uses the Phaser game engine. The checked repository contains separate client and server directories, a root-level requirements.txt file, and a root-level schema.sql file.

The installation has three distinct layers. MySQL stores the application data, Python runs the backend, and the browser loads the web client through the backend's HTTP listener. The documented startup command is executed from the server directory, while dependency installation and schema import are performed from the repository root. Preserving those working directories matters because relative paths used by the project may depend on them.

Keeping local installation separate from remote publication is an important diagnostic technique. If the game does not work at its documented loopback address, adding a tunnel will not repair the application, database, dependencies, or startup process. First establish a healthy local service. Only then introduce the additional networking layer.

Resolve the repository provenance mismatch before installing

There is a notable inconsistency in the available project material. The repository reviewed for this guide is svzdev/doudizhu, but the Quick Start text inside that repository tells readers to clone mailgyc/doudizhu. Those are different repository owners. A setup guide should not silently replace one URL with the other or imply that the two repositories are guaranteed to contain identical code.

This matters because the source you download determines which dependency declarations, SQL schema, server code, and frontend files you execute. Repository forks can diverge even when they share a common history. A clone instruction embedded in a README can also become stale while the surrounding repository continues to exist.

The most defensible workflow is to obtain the exact source tree that you have reviewed, record its repository and revision for your own deployment notes, and then continue from that source tree's root directory. If you intentionally follow the README literally, its documented clone command is:

git clone https://github.com/mailgyc/doudizhu
cd doudizhu

That command is reproduced to explain the project's documented Quick Start, not to resolve the ownership discrepancy. If your reviewed source is instead the svzdev/doudizhu repository, use the download or clone information shown by that repository and verify the resulting revision yourself. This guide does not claim that one location is canonical, newer, safer, or interchangeable with the other because the available evidence does not establish that.

The repository page does not list a release, and the supplied evidence does not establish a current maintenance or support policy. Treat this as source code that needs review rather than as a maintained packaged service with a documented upgrade contract. Before exposing it beyond a trusted environment, inspect its dependencies, application behavior, and access controls according to your own risk requirements.

Prerequisites and decisions to make first

The project documentation lists Python 3.8 or newer and MySQL 5.7 or newer as dependencies. It also uses git in the Quick Start, pip3 to install Python packages, and a Unix-style export command to define the database connection string.

Check the installed versions

Before modifying the database or installing dependencies, confirm that the commands used by the project are available. The following version checks do not alter the system:

python3 --version
pip3 --version
mysql --version
git --version

Python must satisfy the stated 3.8-or-newer requirement, and MySQL must satisfy the stated 5.7-or-newer requirement. A version number alone cannot prove that every dependency will work with the newest runtime available. If package installation reports compatibility errors, use the error output and the versions constrained in requirements.txt to investigate rather than assuming any arbitrary Python release is supported.

Prepare a dedicated database identity

The README's example connection string contains the MySQL root account and a literal example password. Copying that value into a remotely reachable deployment would be poor credential hygiene. Create and use credentials appropriate to your own MySQL environment, limit their privileges to what this application needs, and do not commit the resulting connection string to the source repository.

Exact SQL statements for creating a least-privilege account are not provided because account-management syntax, authentication plugins, and administrative practices can vary across supported MySQL installations. Use your MySQL administrator's approved procedure. The account used to import the schema may also require broader privileges than the account used by the running application.

Understand the documented shell environment

The Quick Start uses export DATABASE_URI=..., which is Unix-style shell syntax and sets the variable for the current shell session and child processes. The available project instructions do not provide PowerShell, Windows Command Prompt, container, service-manager, or system-wide environment configuration. We therefore keep the commands in their documented shell form and do not claim unverified platform support.

Install and configure Doudizhu from source

Perform these steps from the source tree you selected after resolving the repository discrepancy. The sequence follows the project's Quick Start: enter the repository, import the schema, install requirements, enter the server directory, define DATABASE_URI, and start the application.

mysql --user=root -p < schema.sql

pip3 install -r requirements.txt

cd server

export DATABASE_URI='mysql+aiomysql://DB_USER:DB_PASSWORD@127.0.0.1:3306/ddz'

python3 app.py

The project documentation uses this example URI:

export DATABASE_URI=mysql+aiomysql://root:123456@127.0.0.1:3306/ddz

Treat it as an illustration of the required URI structure, not as a recommended credential. In particular, do not change a MySQL root password to 123456 merely to match the example. Your configured URI and your actual database account must agree.

What each connection-string component means

The mysql+aiomysql prefix identifies the MySQL dialect and aiomysql driver expected by the application's database layer. The username and password authenticate the application. 127.0.0.1 directs it to MySQL on the same machine, 3306 is the port shown by the documentation, and ddz is the documented database name.

If your MySQL deployment differs, the URI must reflect your real configuration. However, the project evidence does not document remote database hosts, alternate ports, TLS parameters, special-character escaping, or socket-based connections. Consult your own MySQL and database-driver configuration when departing from the supplied local example.

Verify the game locally before creating a tunnel

With python3 app.py still running, open the documented address from a browser on the same machine:

http://127.0.0.1:8080

A useful local verification is more than observing that a process remains open. Confirm that the browser can load the page, that expected static assets appear, and that the application reaches a usable game interface rather than displaying an HTTP error or an empty response. Keep the server terminal visible while loading the page because backend exceptions may provide the most direct explanation for a failure.

The address 127.0.0.1 is the IPv4 loopback address. It refers to the machine making the connection. A browser on another computer cannot use 127.0.0.1:8080 to reach this server because, on that other computer, the address refers back to itself. This is exactly why local verification should happen on the host and why a tunnel is useful for remote browser access.

Use a clear local success checklist

• The Python process starts without immediately exiting.
• The terminal does not show an unresolved import or missing-package error.
• The database connection does not fail with an authentication, connection, or missing-database error.
• The browser reaches http://127.0.0.1:8080.
• The response is the expected game page rather than a generic browser connection error.
• Required frontend assets load sufficiently for the interface to operate.

The supplied project evidence does not define an automated health endpoint, test command, default user account, expected database row count, or formal gameplay test. We therefore cannot claim that a particular API request or test suite proves full application health. Browser verification at the documented endpoint, combined with inspection of server output, is the supported baseline available here.

Provide remote browser access with a Localtonet HTTP tunnel

Once Doudizhu works locally, a Localtonet HTTP tunnel can publish the HTTP service. Our client application runs on the device that can reach the game and establishes an outbound connection to a Localtonet relay server. This avoids inbound router port forwarding, firewall changes, VPN setup, and the need for a public IP address.

For this deployment, the local HTTP target is the documented game endpoint: IP address 127.0.0.1 and port 8080, provided the Localtonet client runs on the same machine as Doudizhu. If the client runs on another device, 127.0.0.1 would refer to that other device instead, so it would not reach the game. In that arrangement, use an address that is genuinely reachable from the client device and ensure the game is configured to listen appropriately. The project documentation does not describe non-loopback binding, so this guide does not prescribe an unverified application option for that topology.

HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain as their Process Type. All three serve the target content at a public HTTPS address. Availability can vary, and exact custom-domain DNS requirements should be checked against the current dashboard and documentation rather than guessed.

Follow the current Localtonet HTTP tunnel documentation alongside the dashboard because server choices, availability, and interface details can change. Do not hardcode a relay server code from an unrelated example. Select an available value shown for your account and current deployment.

Test from outside the host

Open the assigned public HTTPS URL from another browser or device. Check that it displays the same application you verified locally. If local access works but the public address does not, inspect the Localtonet client connection, tunnel status, selected device, local target, and whether the Python process is still listening.

The tunnel changes how traffic reaches the application, not how Doudizhu communicates with MySQL. The database should remain behind the application. Do not create a separate public database tunnel merely because the browser game is public. The browser needs the game's HTTP endpoint, not direct access to MySQL.

Operate and maintain the deployment safely

This setup has several independent components that must remain healthy: MySQL, the Python application, the Localtonet client, and the tunnel itself. A failure in any required component changes what users observe. Thinking in layers makes routine operation and incident diagnosis more predictable.

Starting a new session

Start MySQL using the procedure appropriate to your system. Open a shell, enter the project's server directory, set DATABASE_URI, and launch python3 app.py. Verify http://127.0.0.1:8080 locally. Then make sure the Localtonet client is connected and start the existing HTTP tunnel.

The project evidence does not provide a service definition or background-process command. If you later add a process supervisor, startup service, container, or secrets manager, treat that as a separate deployment design and test it carefully. Do not assume that a configuration intended for one operating system applies to another.

Stopping remote access versus stopping the game

These actions have different effects. Stopping the Localtonet tunnel removes the active public path while the local game may continue running. Stopping the Localtonet client also prevents the selected device's tunnel from remaining connected. Stopping python3 app.py removes the local HTTP service, so a running tunnel no longer has a healthy target. Stopping MySQL may leave the Python process present but can break database-dependent behavior.

Upgrades and dependency changes

Record the repository and revision currently deployed before pulling changes. Review changes to requirements.txt, schema.sql, configuration handling, and server behavior before applying them. The available documentation does not describe database migrations or backward compatibility, so rerunning schema.sql against an existing database should not be treated as an upgrade procedure unless you have inspected the script and confirmed that behavior yourself.

Back up data according to your MySQL administration practices before making schema or application changes. The repository evidence does not specify an application-aware backup and restore process, so verify restoration in a safe environment rather than assuming that a copied file or untested dump is sufficient.

Access review

Periodically review whether the public tunnel is still required, which device token owns it, and whether the selected source revision is still acceptable for internet exposure. Stop or delete obsolete tunnels. Rotate database credentials if they are disclosed, and replace a device token through the appropriate account workflow if it is exposed. Do not place credentials in issue reports while requesting support.

Troubleshooting Doudizhu and the HTTP tunnel

The schema import fails

Confirm that the MySQL server is running and that the mysql command can reach it. Check the exact error returned by the client. Authentication failures point to the selected MySQL account or its authentication configuration. Permission failures indicate that the importing account cannot perform an operation required by schema.sql. SQL syntax or compatibility errors should be compared with the documented MySQL 5.7-or-newer requirement and the actual script content.

Also verify that the command is being run from the repository root, where schema.sql exists. A shell error saying that the file cannot be found is a local path problem, not a database problem.

pip3 install reports an error

First confirm that the selected Python version is at least 3.8 and that pip3 belongs to the Python installation you intend to use. Read the first meaningful package error rather than only the final failure summary. A missing compiler, unavailable package build, incompatible dependency, or permission failure requires a different remedy.

The project documentation supplies only pip3 install -r requirements.txt. It does not document operating-system packages, a lockfile workflow, or a supported matrix of newer Python versions. Avoid changing dependency versions blindly because doing so can create a configuration that no longer matches the source.

The application reports a database connection failure

Check that DATABASE_URI was set in the same shell used to start python3 app.py. Verify the username, password, host, port, and database name. The documented local structure uses 127.0.0.1:3306/ddz. Confirm that MySQL is actually reachable there and that the selected application account has access to the expected database.

If you copied the placeholder command, replace DB_USER and DB_PASSWORD with real values. If a password contains characters with special meaning in a URI, consult the database driver's connection-string rules. The project evidence does not provide an escaping recipe, so guessing could produce an incorrect or insecure value.

python3 app.py cannot find a module or file

A missing Python module usually means dependency installation did not complete for the Python environment running the application. A missing project file can indicate that the command is being executed from the wrong directory or from a different source revision. Confirm that you ran the startup command from doudizhu/server and that the dependency installation completed against the intended Python installation.

The browser cannot open 127.0.0.1:8080

Look at the server terminal first. If the process exited, correct its reported error and restart it. If it remains running, confirm that the address and port are exactly those documented. Another process may already be using port 8080, but the project evidence does not describe a supported alternate-port configuration. Do not invent a command-line flag. Inspect the application configuration or source before changing the listener.

The page opens locally but not through Localtonet

Verify each boundary in order:

1. The Doudizhu process is still running.
2. The local page still loads at http://127.0.0.1:8080 on the host.
3. The Localtonet client is running on that same host, or can otherwise reach the configured target.
4. The selected device token corresponds to the connected client.
5. The HTTP tunnel target is the correct IP address and port.
6. The tunnel has been started rather than merely created.
7. The remote browser is using the assigned public URL.

If the client is on another device and the tunnel target is 127.0.0.1, the client is attempting to reach itself, not the Doudizhu host. Moving the Localtonet client to the game host is the straightforward topology for the documented loopback listener.

The public page loads but gameplay does not work correctly

Compare the behavior with the local page. If the same problem occurs locally, troubleshoot the application, database, frontend assets, and selected source revision. If it occurs only through the public URL, inspect browser developer messages and server output for assumptions about URLs or connection behavior. The supplied project documentation does not state whether every multiplayer transport and frontend URL is designed for operation behind a public HTTPS tunnel, so specific code-level changes cannot be prescribed without reviewing the deployed revision.

Frequently asked questions