One-Click Deployment
The DaxPay operations panel is a single-file program with a built-in web UI — just open it in a browser. One command installs it on a Linux server, then a browser wizard walks you through the whole flow: environment check → global configuration → image build → base middleware → business services → gateway access. No need to assemble docker-compose files by hand.
This page is a quick start that follows the wizard. For in-depth explanations of each step, command-line management, daily operations, and troubleshooting, see the Operations Panel.
Recommended path
If this is your first deployment, you are not familiar with Docker orchestration, or you simply prefer a visual panel for daily operations, this page is all you need.
Use Cases and Prerequisites
The operations panel packages the whole job of "getting a DaxPay server ready to serve traffic" into a wizard. It is a good fit when you want to:
- Take a clean Linux server from zero to a working deployment
- Avoid maintaining docker-compose files, environment variables, and secrets by hand
- Manage start/stop, configuration, logs, and version upgrades through a web panel afterwards
| Item | Requirement | Notes |
|---|---|---|
| OS | Ubuntu / Debian / CentOS / Rocky / AlmaLinux / Fedora | x86_64 distros; Ubuntu 22.04+ recommended |
| Architecture | x86_64 (amd64) | arm64 is not supported yet (the image chain is not verified end to end) |
| Memory | ≥ 4 GB | Minimum for the Compact tier; 8 GB+ recommended for the Standard tier |
| Disk | ≥ 500 MB on the partition holding the install directory | Actual usage depends on data volume |
| Privileges | root (or sudo) | Required to install Docker, operate docker.sock, and bind ports |
| Network | Internet access required (pulling Docker images, etc.) | If the download source is unreachable (overseas CDN blocked / restricted egress), use offline installation and upload the package manually |
Install the Operations Panel
Installation downloads a ~40 MB program to /opt/daxpay and starts a web panel listening on port 8060. Depending on whether the server can reach the download source, choose online or offline installation.
Online Installation (Recommended)
One command downloads, verifies, installs, and starts the panel:
curl -fsSL https://download.daxpay.top/open/install/install.sh | sudo bash
# or, with wget
wget -qO- https://download.daxpay.top/open/install/install.sh | sudo bashThe script automatically: probes the environment (architecture / distro / disk / xz) → downloads the archive and verifies its SHA256 → extracts and installs it to /opt/daxpay → creates the daxpay command symlink → (optionally) generates a systemd service for auto-start on boot → starts the panel, automatically enables the security entrance, and prints the access URL (including the entrance path) plus the initial admin password to the terminal.
On success, the terminal prints something like:
✓ The operations panel has started
URL: http://192.168.1.10:8060/k3x9m2qp4w7nbd5e
Username: admin
Password: <16-char random password>After installation, copy the full access URL printed to the terminal into your browser, e.g. http://192.168.1.10:8060/k3x9m2qp4w7nbd5e. The random security entrance is part of the full URL and must be kept; visiting only http://192.168.1.10:8060 returns 404 on the bare address. If you forget the entrance path, run daxpay entrance show on the server to see the full URL; if you forget the initial password, run daxpay info.
For upgrade and uninstall commands see Installation, Upgrade, and Uninstall.
Download source requirement
Online installation requires the server to reach the download.daxpay.top download source (an overseas CDN; some networks may time out or fail to reach it). If the source is unreachable, switch to the offline installation below: upload the package manually and the installation process will not contact any download source.
Offline Installation
Offline installation is for servers that cannot reach the download source (overseas CDN blocked, restricted egress, etc.): you transfer the two installation files to the server manually, and the installation process never contacts a download source.
Offline ≠ air-gapped deployment
"Offline" only means the package is not downloaded over the network and must be uploaded manually — it is not a deployment plan for disconnected environments. DaxPay still needs internet access at runtime (pulling Docker images, installing system dependencies, connecting to payment channels); a fully disconnected server cannot be deployed.
1. Prepare the two files (from the release artifacts, put them in the same directory):
| File | Purpose |
|---|---|
install.sh | Install and management script (SHA256 of the current version already filled in) |
dax-pay-installer-linux-amd64.xz | Program archive (~15 MB) |
2. Upload both to the same directory on the target server, e.g. /root/daxpay-offline/.
3. Run the installation. Pick either of the two ways:
# Option 1: invoke directly with bash — no chmod needed
sudo bash install.sh
# Option 2: grant execute permission first, then run (chmod required for the script)
chmod +x install.sh
sudo ./install.shThe script auto-detects the .xz archive in its own directory and switches to the offline flow; verification, extraction, installation, and startup afterwards are identical to the online installation.
About chmod permission
install.sh: chmod is not needed when invoked viabash install.sh; it is required before executing./install.sh(chmod +x install.shfirst).- The
dax-pay-installer-linux-amd64.xzarchive: chmod is never needed — the script decompresses it withxz, it is not executed directly.
Offline installation never touches the download source
During offline installation the script does not contact any download source (the package comes from manually uploaded local files); verification uses the SHA256 baked into install.sh. Both files are mandatory and must sit in the same directory (the script only scans its own directory).
Log In to the Panel
After installation, open the panel URL in a browser.
- Visit the full URL printed when installation finished (of the form
http://<server IP>:8060/<security entrance>; the random entrance must be kept; rundaxpay entrance showif you forget it) - Enter the initial credentials:
- Username:
admin - Password: the strong 16-character random password generated during installation
- Username:
Recover the initial password
Three ways to retrieve the initial password:
- It is already printed in the installation terminal output
- Read the file:
cat /opt/daxpay/installer-initial-password.txt - Run:
daxpay info
Change the password as soon as possible
The initial password is for first login only. After signing in, reset it via the user menu in the top-right corner → "Change Password". The panel listens over plain HTTP by default; when exposed to the public internet, always terminate TLS through the later gateway HTTPS or a front reverse proxy.
Deploy with the Wizard
After login, the panel opens the deployment wizard mode by default, with a step navigation bar on top. Completing the six steps in order deploys a full DaxPay. For the configuration details behind each step, see Operations Panel - Configuration Details.
Step 1: Environment Check
- Confirm Docker and Git are installed: if missing, click the corresponding button and the panel installs them in one click from China-hosted mirrors (with live log streaming)
- Click "Download Code" to pull the source of all DaxPay repositories (Gitee by default)
- Review host memory and port conflicts
Two prerequisite tools
Docker and Git are prerequisites for the later build and deployment. Skip this if the server already has Docker; Git is used to pull the source and switch versions.
Step 2: Global Configuration
- Memory tier: choose Compact (≥4 GB) / Standard (≥8 GB, recommended) / Enhanced (≥16 GB) based on server memory; click "Apply Tier" to take effect
- Runtime flavor: choose HotSpot or OpenJ9 for the JVM
- Deployment version: pick the
4.0branch or a release tag (after switching versions, return to step 1 to "Update Source") - Build mirrors: configure China-hosted Maven / npm mirrors to speed up the later image builds
- Build concurrency: the Smart tier adapts to host memory automatically; low-spec machines can pin it to a single concurrent job
Step 3: Image Build
- First prepare the IP data files (ip2region): the v4 file can be downloaded in one click; v6 must be downloaded or uploaded manually. This is a prerequisite for building the backend images
- Click "One-Click Build All" and the panel builds all images in a parallel pipeline (the backend Maven groups, both web consoles, and the H5 proceed simultaneously); if extension-channel source credentials are configured, extension channel images join automatically; each service can also be built / rebuilt individually for troubleshooting
- Follow progress and output live in the Task Center at the bottom-right corner; if some services fail, the task ends in the "Partially succeeded" state and you can rebuild just the failed ones
Why the IP files come first
The backend image build bakes these two files into the image and verifies them — a missing file fails the build. The files live in the data/ip/ directory.
Build time
Image building is the most time-consuming stage of the whole flow and varies a lot with the concurrency tier, network, and machine performance. Configuring the mirrors and reserving enough memory cuts the time significantly.
Step 4: Base Environment
- Click "Deploy Base Environment" to bring up the three middleware containers — PostgreSQL + Redis + Artemis — in one click
- Middleware passwords are generated automatically and visible under "Credentials & Connections"; to change one, use the one-click password rotation (it syncs the configuration and restarts the business containers)
- Middleware ports are not mapped to the host by default (they are reachable only inside the container network, for business containers to connect); to connect from the host for debugging, enable the mapping manually on the service card under "Operations Management → Base Environment"
Step 5: Service Deployment
- 5.1 Initialize the database: run
table.sql+data.sqlto create the table schema and seed data (force rebuild is optional) - 5.2 One-Click Deploy: the deploy button unlocks once the trio — "images built + database initialized + IP files ready" — is in place; clicking it deploys the main backend, the channel sub-apps, and three frontend containers; business keys (RSA / AES / channel transport keys) are generated automatically on first deployment
- Business container ports are likewise not mapped to the host by default: all external traffic is proxied uniformly by the step 6 gateway (80), leaving zero business ports occupied on the host besides the panel and gateway; if you truly need a direct connection (e.g. debugging the backend API locally), enable the mapping manually on the service under "Operations Management → Business Environment" (the three levels are explained in Operations Panel - Port Exposure)
Business keys are generated exactly once
The RSA private/public keys, the AES encryption key, and the channel transport keys are generated automatically and pinned on first deployment. Regenerating them makes already-encrypted data undecryptable — be careful in production.
Step 6: Gateway Access
- Click "Deploy Gateway" to bring up a standalone nginx gateway container (prerequisite: the base environment is deployed). The gateway's port 80 is the system's only port exposed by default; all external traffic converges through it
- Bind domains: one each for the admin console, merchant console, H5, backend API, and the Artemis console (enter bare domains; leave blank to skip binding); plus an optional Mobile API domain — a dedicated entry for mini programs / apps, which published clients use by entering it as the API base URL at build time
- Configure CDN / outer-layer access: the gateway origin serves zero certificates and always speaks HTTP — TLS is terminated at the outer CDN / gateway layer. Two modes: "Direct to origin" and "Origin pull via CDN / outer gateway (with an origin-pull auth token)"; for the access checklist see Operations Panel - Gateway Management
- Review the public API toggles: merchant open API
/unipay, channel callbacks/unipay/callback, and mini program / APP API/app-*are on by default; the EPay-compatible/epayis off by default — adjust as needed - Click "Apply Gateway Config" to render the nginx configuration and reload it into effect
Domain verification files
The nginx built into the H5 image already reverse-proxies verification file requests to the main application (the root path and the QR terminal / cashier / aggregate directories /m/, /cm/, /am/, answered uniformly by the main app with a database lookup; the HTML served by the SPA fallback cannot pass verification). Merchant-level domain verification files (MP_verify_*.txt, for WeChat authorization callbacks) are uploaded on the "Domain Verification Files" page of the merchant console or the admin console; platform-level random verification files for plain-link QR codes (.txt / .html) are uploaded in the admin console under "Payment Config → Domain Verification Files". Neither requires any nginx configuration change. On existing deployments this takes effect only after upgrading the panel and rebuilding the H5 container (the config is baked into the image).
Verify Access
After deployment, access each entry through its bound domain:
| Entry | URL | Notes |
|---|---|---|
| Admin console | https://<admin domain> | Used by platform operators |
| Merchant console | https://<merchant domain> | Self-service for merchants |
| H5 | https://<H5 domain> | Mobile payment pages |
| Backend API | https://<backend domain> | Called by frontends and open APIs |
Production wrap-up
The default deployment mode is DEV (integration debugging, with sandbox and super admin enabled). Before going live, go to "Operations Management → Business Environment → Main App → App Config", switch the deployment mode to PROD (which forcibly disables the sandbox and the super admin), save, and restart the container for it to take effect.
Related Sections
- Operations Panel: installation internals, command reference, operations management, configuration details, and troubleshooting
- Configuration: per-app profiles, ports, database, keys, and production environment variables