H5 Mini-Game Demo Platform Deployment: Node Admin, Nginx, MySQL Setup Notes

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

I recently helped a client deploy an H5 mini-game demo platform. The scope was deliberately narrow: probability demos and points-ledger teaching only, with no live billing and no offline redemption. Think of it as a compact game-collection console: H5 front end, an admin panel for room data, demo parameter tuning, and log export. It took me three evenings, and the pain clustered in three places: environment setup, callbacks, and permissions. This post follows the deployment order so anyone planning secondary development can save some time.

Reminder: this project is for technical education and learning exchange only. Please follow applicable laws and rules, and do not use it for any unlawful purpose. Keep billing, points, or redemption-style capabilities in a sandbox, or disable them entirely.

Feature test: which modules I actually enabled

The front end is a single-page H5 shell with eight lightweight modes: animal racing, card point comparison, joker spinner, hundred-player point comparison, twelve-thirty, fruit matching, PK quiz, and memory flip. The names sound fancy, but underneath they are random numbers plus weight tables. The admin side can create rooms, set demo multipliers, limit experience points, and inspect per-round ledgers. The detail beginners miss most is that “demo parameters” and “probability configuration” are not the same thing: the first controls presentation pace, the second controls the random-number distribution. If you change the wrong one, you may see long streaks of the same suit; when troubleshooting, split the logs by concern.

Admin panel and points ledger

The admin menu is not complicated: dashboard, game management, room list, points ledger, announcements, permissions, and logs. The useful parts of the dashboard are the online curve and anomaly alerts, such as many accounts on one device in a short window, or an unusually large points swing in a single round. Keep the raw request payload in the points ledger; it makes disputed rounds much easier to review later.

Random numbers and demo risk controls

The core API is written in Node. Do not use Math.random as the production random source. For online use I switched to seedrandom plus a server-side time slice, while the test environment keeps a fixed seed. Risk controls are demo-only: rate limiting, single-IP concurrency caps, blacklist labels, and a second confirmation for sensitive actions. Avoid exaggerated wording in articles or code comments; call them “demo limits” and keep it plain.

Deployment notes: from a blank server to an admin panel that opens

I used a small 2-core, 4 GB machine on Ubuntu 22.04. Nginx reverse-proxies to the Node service, MySQL stores accounts and ledgers, Redis holds sessions and room state, and PM2 keeps the process alive. For production, enable HTTPS. Once mixed content creeps into an H5 page, Android and iOS can behave very differently.

Do not chase the newest versions

I stayed on Node 18.x. Node 20 triggered an OpenSSL-related error in one older dependency. If you do not want to fight it, NODE_OPTIONS=–openssl-legacy-provider can unblock you, but do not leave that on in production. With MySQL 8, watch sort buffer and index length; when importing old tables, change utf8 to utf8mb4, or nicknames with emoji will fail immediately.

Nginx and cross-origin setup

Serve static assets through Nginx and route APIs under /api. Do not set cross-origin to * just because it is easy; tighten it to the real domains. Put gzip, caching, and connection timeouts in the conf. WebSocket heartbeat deserves special care: if the proxy timeout is too short, a room can look online while the connection has already dropped.

Sandbox callbacks, multi-language, and secondary-development boundaries

A common selling point for this kind of source package is a billing connector, but my build keeps only sandbox callbacks: verify the signature first, write the ledger second, then notify the business side asynchronously. I left live billing off, which reduces compliance pressure a lot. Multi-language is handled with JSON packs: the front end uses i18n keys, and the admin side keeps translation rows in tables. Do not hard-code Chinese; adding English or Vietnamese later becomes miserable.

Suggestions for secondary development

If you want to add a mode, copy the existing room abstraction first: entry, pre-check before point simulation, settlement, broadcast, and persistence. In the pre-check step, avoid real-money wording entirely and use one consistent label such as “experience-point deduction.” Keep theme changes isolated with CSS variables, and make promo popups configuration-driven. If you really need a third party, connect only to open-platform demo capabilities, keep secrets in server-side environment variables, and never bundle them into the front end.

Who this fits, and who it does not

It fits people practicing H5 real-time communication, admin permissions, random-number controls, and log auditing, and it fits training organizations running classroom demos. It does not fit anyone hoping for an out-of-the-box passive-income machine, and it definitely does not fit unlawful scenarios. The source code is only a shell; stability comes from monitoring, backups, and gradual rollout.

FAQ

Q: The front end opens after deployment, but every API returns 502. What now?
A: Nine times out of ten, Node is not running or the port is blocked by the firewall. Check the PM2 logs first, then the Nginx error_log. The reverse-proxy target must match the listening port; do not write localhost as an intranet IP and then forget to open the security group.

Q: I changed a demo parameter in the admin panel, but it does not take effect.
A: It is probably cached. Clear the room config in Redis and, if needed, restart the business process. When editing probability tables, confirm you wrote to the current environment; mixing test and production databases is the most common mistake.

Q: Can live billing or redemption be added?
A: I would not recommend it. Keep the demo environment on sandbox callbacks and keep points as a closed loop. If the project direction changes, evaluate qualification, regional rules, and settlement responsibility first; otherwise cut the feature.

Q: The mobile page stutters and animations drop frames.
A: Compress large background images to WebP, animate transform instead of top/left, and use virtual scrolling for long lists. For low-end phones, add a “power-saving mode” that disables particle effects; it stabilizes things quickly.

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

#H5 source deployment #Node admin #probability simulation #secondary development notes #deployment log