Set Up Doudizhu and Access It with Localtonet

What this Doudizhu deployment contains

Doudizhu, also called Dou Dizhu, is a multiplayer card game. The repository snapshot reviewed for this tutorial describes an HTML5 implementation with a Python backend based on Tornado and MySQL. It identifies Phaser as the frontend engine and contains separate client and server directories, a root-level requirements.txt, and a root-level schema.sql.

The deployment has three application layers. MySQL stores the data expected by the supplied schema. Python and Tornado run the backend. A browser loads the frontend through the application's HTTP listener. Localtonet is an optional fourth layer that provides public reachability after the application works locally. It does not replace Python, MySQL, or the application's own security controls.

Keeping installation, local verification, and remote publication separate is essential. If the local page fails, a tunnel cannot install missing packages, repair a database connection, change the application's listener, or correct frontend errors. Establish a functioning local service first, then introduce the public network path.

Resolve the repository and licensing questions first

The reviewed repository location is svzdev/doudizhu. However, the Quick Start text displayed in that repository tells readers to clone mailgyc/doudizhu. These URLs name different repository owners. A README containing one clone URL while being displayed in another repository does not, by itself, establish which fork is canonical, whether one is newer, or whether the two source trees are identical.

The current evidence supplied for this revision reports that the svzdev/doudizhu repository uses a master branch and displays 277 commits, but it does not include the hash of the exact commit represented by the extracted page. We therefore do not invent a commit identifier or claim that every current branch tip has been tested. Before following repository-specific instructions, check out the source you intend to use and record its actual commit hash.

git status
git remote -v
git rev-parse HEAD
git log -1 --oneline

Save the remote URL and the complete output of git rev-parse HEAD in your deployment notes. Review the README.md, requirements.txt, schema.sql, and server directory at that same revision. If any of those files differ from the reviewed structure, stop and adapt the procedure to the source actually in front of you rather than assuming this article still matches it.

If you intentionally follow the README literally, the clone portion shown in its Quick Start is:

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

Reproducing that command explains the mismatch. It is not an endorsement of one repository over the other. If you choose the svzdev location instead, use the clone URL presented by that repository, then record the checked-out commit with the commands above. In either case, review the code and dependency declarations before executing them.

Source identity and licensing are separate questions. Confirming a commit tells you which files you reviewed, but it does not grant legal rights. Likewise, finding a license does not prove that a fork is current, secure, or compatible with modern dependencies. Complete both reviews before exposing the application to other users.

Prepare supported software and an isolated environment

The repository README lists Python 3.8 or newer and MySQL 5.7 or newer. These are historical project minimums, not sensible recommendations for a new internet-facing installation in 2026. Python 3.8 reached end of life in October 2024, and MySQL 5.7 reached end of life in October 2023. End-of-life software no longer receives the ordinary upstream security maintenance expected for a current deployment.

Use currently maintained Python and MySQL releases only after testing the old project and its pinned or declared dependencies against them. The supplied evidence does not identify a modern version pair that the project maintainers have tested, so this article cannot responsibly promise compatibility with a particular current release. A maintained runtime is the security goal, but compatibility must be demonstrated in a disposable test environment before deployment.

Check the available tools

From the machine where you plan to test the project, inspect the installed tools without changing the system:

python3 --version
python3 -m pip --version
mysql --version
git --version

Do not interpret “newer” as “automatically compatible.” Older Python packages may depend on APIs removed from modern Python, may not publish a wheel for the selected runtime, or may require system build tools. SQL written for MySQL 5.7 can also encounter changed defaults or compatibility differences on a maintained server. Test installation, schema import, startup, and the application behavior you actually need.

Use a project-specific Python virtual environment

A global pip3 install -r requirements.txt can modify the system Python environment and conflict with other applications. Some current operating systems also mark their Python installation as externally managed and reject global package installation. A virtual environment isolates this project's packages and lets python -m pip target the same interpreter that will start the server.

Create the environment from the repository root:

python3 -m venv .venv
source .venv/bin/activate
python -m pip --version

The activation command above is for a Unix-style shell, which is also the environment implied by the README's use of export. The supplied project evidence does not document Windows setup or confirm Windows support, so platform-specific commands are not invented here.

Prepare the database account

The README demonstrates its URI with the MySQL root account and a simple literal password. That is an example of URI structure, not a secure operational recommendation. Use a dedicated database identity, grant only the permissions required by the application, and keep the runtime account separate from any more privileged account needed to review or import the schema.

Exact account-creation SQL is not included because MySQL authentication plugins, administrative policies, and privilege requirements vary. Have a MySQL administrator review schema.sql, create the database identity, and determine the privileges required by the running application.

Install and configure Doudizhu from the reviewed source

Begin from the exact repository revision you selected and recorded. The sequence below preserves the project's substantive requirements while replacing the unsafe global package installation with a virtual environment and replacing the literal secret-bearing export command with a hidden prompt.

cd doudizhu
git remote -v
git rev-parse HEAD
test -f schema.sql
test -f requirements.txt
test -d server

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

python3 -m venv .venv
source .venv/bin/activate

python -m pip install -r requirements.txt

cd server

read -r -s -p "DATABASE_URI: " DATABASE_URI
printf '\n'
export DATABASE_URI

python app.py

The connection URI structure shown by the README is:

mysql+aiomysql://USERNAME:PASSWORD@127.0.0.1:3306/ddz

Do not paste that placeholder literally, and do not reuse the README's example root credential. The mysql+aiomysql prefix identifies the MySQL dialect and aiomysql driver expected by the project's database layer. The username and password authenticate the application. 127.0.0.1 identifies MySQL on the same machine, 3306 is the port shown in the README, and ddz is the documented database name.

Passwords containing URI-reserved characters may need encoding according to the database library's connection-string rules. The available project evidence does not provide an escaping procedure. Do not simplify a password or guess at encoding merely to make the URI work. Check the behavior of the exact database library version installed from the recorded revision.

Verify the local page before creating a tunnel

With the Python process running, open the local address documented by the repository from a browser on the same machine:

http://127.0.0.1:8080

Confirm that the browser receives the expected page rather than a connection error, generic server error, or empty response. Check that the visible interface and required static assets load, and keep the server terminal visible so you can correlate browser requests with backend exceptions.

This is a page-load verification, not proof of complete multiplayer operation. The supplied evidence does not provide a formal test suite, health endpoint, default test users, expected database contents, or a documented procedure for validating every real-time or multiplayer transport. A successful page load establishes that the browser can reach the local HTTP service and receive the frontend. It does not establish that every game action, concurrent-player path, session feature, or underlying transport works.

Local verification checklist

• The virtual environment is active and the application uses its Python interpreter.
• The Python process starts without immediately exiting.
• No unresolved import or missing-package error appears.
• The application can authenticate to the intended MySQL database.
• The browser reaches http://127.0.0.1:8080 on the host.
• The expected page appears and required frontend assets load.
• The terminal does not report a request-time exception while the page loads.

The loopback address 127.0.0.1 always refers to the device making the connection. A browser on another computer cannot use that address to reach the Doudizhu host because it would point back to the other computer. For the same reason, placing the Localtonet client on the Doudizhu host is the simplest topology for the documented listener.

Configure remote browser access with Localtonet

After the local page works, use a Localtonet HTTP tunnel to publish the HTTP service. Our client on the selected device establishes an outbound connection to a Localtonet relay server. This provides a public URL without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

Use the current Localtonet HTTP tunnel documentation as the installation and configuration entry point. It is the appropriate place to obtain the current client for your operating system and confirm the live interface. If you do not yet have an account, use the Localtonet registration page. Client packages, available relay servers, and dashboard presentation can change, so this article does not invent an operating-system command or hardcode a server code that was not included in the verified evidence.

The target for this setup is 127.0.0.1 on port 8080 when the Localtonet client runs on the same host as Doudizhu. If the client runs on another device, that device's 127.0.0.1 refers to itself. You would need an address reachable from that client and an application listener configured for that topology. The Doudizhu README does not document a non-loopback binding option, so no unverified flag is provided here.

Choose the HTTP addressing model

HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain as their Process Type. Each serves the target content at a public HTTPS address. Availability can vary by account or current product configuration. Custom-domain DNS details should be taken from the current dashboard and documentation rather than copied from an unrelated deployment.

The following sequence follows the maintained Localtonet workflow: install and run the client, identify the device with its token, select an available relay server, create the HTTP configuration, start and use it, then stop or delete it when access is no longer required.

Interpret the remote result carefully

Opening the assigned URL and receiving the same page proves that an external browser can reach the application's HTTP page through the tunnel. It does not, by itself, prove that complete multiplayer gameplay has been tested. If the game uses additional connection behavior beyond the initial page and assets, validate that behavior separately with multiple controlled clients while monitoring browser diagnostics and server output.

The tunnel changes how browser traffic reaches Doudizhu. It does not change how Doudizhu reaches MySQL. Keep the database behind the application. Remote browsers need the game's HTTP endpoint, not direct public access to port 3306.

Review security before sharing the public URL

A service that was previously reachable only through loopback gains a broader audience when you start a public tunnel. That change is useful for controlled remote access, but it also exposes application behavior, dependencies, and any missing access controls to internet-originated requests.

Keep the database URI and Localtonet device token out of source control, screenshots, issue reports, browser-delivered files, and shared terminal logs. If either secret is disclosed, revoke or replace it through the appropriate database or account workflow. Merely deleting a screenshot does not invalidate a credential that has already been copied.

Avoid running the game process or database as an unnecessarily privileged operating-system account. The project README does not prescribe a service account, sandbox, or container policy, so those decisions require a separate deployment review. Whatever method you choose, grant only the filesystem, database, and network access actually needed.

Operate and maintain the deployment

Four components must remain healthy for remote users to load the application: MySQL, the Python process, the Localtonet client, and the HTTP tunnel. Treat them as separate operational layers so that stopping one does not get confused with stopping another.

Start a new test session

1. Start MySQL using the procedure approved for your system.
2. Open a shell and enter the repository root.
3. Activate .venv.
4. Enter the server directory.
5. Read and export DATABASE_URI without placing the secret in shell history.
6. Run python app.py.
7. Verify http://127.0.0.1:8080 locally.
8. Run the selected Localtonet client and start the existing tunnel.
9. Test the assigned public URL from a separate device.

Understand what happens when a component stops

Handle source and dependency changes deliberately

Before pulling or checking out different code, record the currently deployed commit and back up the database using your MySQL administration process. Review changes to requirements.txt, schema.sql, configuration loading, listener behavior, and frontend networking assumptions.

Do not treat rerunning schema.sql as an upgrade process unless you have inspected the exact script and verified that it is safe against the existing database. The project evidence does not document migrations or backward compatibility. Test changes against a disposable copy and confirm restoration before modifying a deployment you care about.

If you test a newer Python or MySQL release successfully, record the exact versions, package installation output, commit hash, schema result, local verification, and multiplayer checks you performed. That deployment record is more useful than the README's broad “or newer” statement because it describes an actual tested combination.

Troubleshoot by testing one layer at a time

The schema import fails

Confirm that MySQL is running and that the client can reach it. Read the first specific error. Authentication failures point to the selected account or authentication configuration. Permission failures indicate that the importing account cannot perform an operation in schema.sql. Syntax or compatibility errors require comparison between the recorded schema file and the maintained MySQL version being tested.

Run the import from the repository root. A shell message saying schema.sql cannot be found is a path problem, not a MySQL compatibility problem.

Virtual environment creation fails

Confirm that the selected Python installation includes virtual-environment support. Some operating-system packages separate that support from the core interpreter. Use the package instructions for your operating system rather than falling back to a global pip installation merely to bypass the error.

Dependency installation fails

Verify that the virtual environment is active and that python -m pip --version points inside .venv. Read the first meaningful package error. An unavailable wheel, failed native build, incompatible version constraint, or removed Python API must be investigated against the exact requirements.txt and interpreter version.

Do not update package versions blindly. Changing a dependency may make installation succeed while introducing an application incompatibility. If you modify the dependency set, document the change and test the local page and required game behavior again.

The application cannot connect to MySQL

Confirm that DATABASE_URI was exported in the same shell that starts python app.py. Check the username, password, host, port, and database name. The documented structure uses 127.0.0.1:3306/ddz, but it must match your real MySQL configuration.

Verify that the runtime account can access the expected database and that the schema import completed. If the password contains URI-reserved characters, investigate the exact driver's encoding rules rather than weakening the credential.

Python reports a missing module or file

A missing module commonly means that package installation failed, the virtual environment is not active, or the application is running with a different interpreter. Check python -m pip --version and the dependency installation output. A missing project file can indicate the wrong working directory or a different source revision.

Start the application from the repository's server directory as documented. Do not invent a module path or startup flag without inspecting the checked-out source.

The browser cannot open the local page

Inspect the Python terminal first. If the process exited, correct its reported error. If it is still running, confirm the exact URL and port. Another process may already occupy port 8080, but the repository evidence does not document a supported alternate-port option. Review the source before changing listener behavior.

The local page works but the public URL does not

1. Reload http://127.0.0.1:8080 on the host.
2. Confirm the Localtonet client is still connected.
3. Confirm the selected AuthToken belongs to that client device.
4. Confirm the selected relay server remains available.
5. Confirm the tunnel target is 127.0.0.1 and port 8080 for a same-host client.
6. Confirm the tunnel was started rather than only created.
7. Use the assigned public HTTPS URL exactly as displayed.

If the client runs on another machine, a target of 127.0.0.1 points to that other machine. Run the client on the Doudizhu host for the documented loopback setup, or perform a separate application-binding and network-security review before using a different topology.

The public page loads but multiplayer behavior fails

First reproduce the same action through the local URL. If it fails locally, investigate the application, database, frontend, and source revision. If it fails only through the public URL, inspect browser developer messages and backend output for hostname, scheme, connection, or asset assumptions.

Do not report a successful page load as proof that all multiplayer behavior or every underlying transport has been validated. The available repository documentation does not describe those transports or provide a complete remote test procedure. Any code-level remedy must be based on the exact recorded revision and observed diagnostics.

Frequently asked questions