Deployment Wizard
The operations panel's deployment wizard fits first-time deployments or rebuilding a DaxPay environment from scratch. The six steps are laid out vertically on one page in dependency order, and each action button enables itself based on its own preconditions (for example, the deploy button stays disabled until the images are built). On servers that are already deployed, prefer Daily Operations for day-to-day start/stop and configuration changes.
Pre-deployment Checklist
Before starting, confirm:
- The server is amd64 Linux with at least 4 GB of memory; 8 GB+ is recommended for production.
- Docker, Docker Compose, and Git are available; the panel can help install them in step 1.
- The server can reach the source repositories, the image registry, and the Maven/npm/Go dependency sources.
- Ports 8060 and 80 are conflict-free (the origin does not listen on 443; HTTPS is terminated by the outer CDN / gateway).
- For production, domains, the CDN / HTTPS access approach, and database persistence space are already planned.
For the panel installation itself, see Installation, Upgrade, and Uninstall; for the shortest path from zero, see One-Click Deployment.
Step 1: Environment Check
This stage prepares the host machine and the project source:
- Checks Docker, Docker Compose, Git, disk, memory, and ports.
- Installs Docker per distro through the panel-provided install action when it is missing.
- Click "Download Code" to pull the DaxPay source, using the configured code source by default.
- Watch install and download output through the live task terminal; long tasks keep their logs recoverable after a page refresh.
If the Docker installation fails, first confirm in the terminal that the current user has sudo privileges, and check whether the distro package mirrors are reachable. Do not continue to image building while Docker is not yet working.
Step 2: Global Configuration
Global configuration affects subsequent builds and runtime:
| Setting | Effect |
|---|---|
| Memory tier | Batch-sets resource limits and the JVM type for the base environment and business services |
| Runtime flavor | Choose HotSpot / OpenJ9 |
| Deployment version | Pick a branch or a release tag |
| Build mirrors | Configure Maven and npm download mirrors |
| Build concurrency | Smart / single-concurrency for low memory / balanced / parallel — four tiers that decide how many containers build at once |
After switching the deployment version, click "Update Source" on the "Deployment Version" row of this step to pull the new version. After changing global configuration, if existing container configs drift, you must re-deploy the affected services as prompted for the changes to take effect.
Step 3: Image Build
Before building, prepare the ip2region data files under data/ip/. The v4 data can be downloaded through the panel; the v6 data usually has to be uploaded manually.
Clicking "One-Click Build All" builds all images in a parallel pipeline (the backend Maven groups, both web consoles, and the H5 proceed simultaneously):
- The main backend and channel sub-apps (extension channels included when their credentials are configured; their versions follow the business source).
- The admin console and merchant console.
- The H5 app.
Build time depends on the concurrency tier, CPU, memory, network, and dependency cache. If some services fail to build, the task ends in the "Partially succeeded" state; the failure list is in the Task Center log — rebuild the failed services individually instead of rebuilding all images over and over.
Step 4: Base Environment
Click "Deploy Base Environment" to start the three middleware services: PostgreSQL, Redis, and Artemis.
- Passwords are generated by the panel and written into the working directory configuration.
- Middleware ports are not mapped to the host by default; only business containers can reach them through the Docker network.
- For local debugging, temporarily enable the port mapping on the corresponding card under "Operations Management → Base Environment".
- After changing credentials, restart or re-deploy the dependent services as the panel prompts.
The base environment must be healthy before you initialize the database and deploy business services.
Step 5: Service Deployment
Initialize the Database
Run the database initialization task, which imports table.sql and data.sql. In production, do not casually check force rebuild — it may wipe existing tables and data.
Deploy Business Containers
Once images, the database, and the IP data files are all ready, click "One-Click Deploy" to start:
- The main backend;
- The channel sub-apps;
- The admin console, merchant console, and H5.
The first deployment generates the RSA, AES, and channel transport keys. Once generated, the keys are pinned into the runtime configuration; do not regenerate them in production, or previously encrypted data may become undecryptable.
Business containers do not map host ports by default; all external access is served through the step 6 gateway. For direct-connection debugging, see the port exposure strategy in Configuration and Troubleshooting.
Step 6: Gateway Access
Deploying the gateway starts a standalone nginx container that uses port 80 by default as the system's single public entry point.
Domains
You can bind a domain for each of the admin console, merchant console, H5, backend API, and the Artemis console, plus an optional Mobile API domain (dedicated entry for mini programs / apps). Enter bare domains — no http:// prefix and no path.
CDN / Outer-Layer Access
The gateway origin serves no certificates; HTTPS is terminated at the outer CDN / gateway layer. Two access modes:
- Direct to origin: the domain resolves straight to the server; fits deployments without a CDN or ad-hoc debugging.
- Origin pull via CDN / outer gateway: each bound domain entry only admits requests carrying the correct origin-pull token; recommended for production.
For the CDN checklist and the full origin-pull token documentation, see Gateway Management - Domain Binding and CDN Outer-Layer Access.
Public APIs
The gateway admits external requests by path prefix: merchant open API /unipay, channel callbacks /unipay/callback, and mini program / APP API /app-* are on by default; the EPay-compatible /epay is off by default. Review the toggles, and double-check source restrictions, firewall rules, and the gateway domain configuration.
Domains, access modes, and API toggles are gateway configuration — clicking "Apply Gateway Config" reloads them immediately. Global settings such as memory tiers require re-deploying the containers; do not confuse the two.
Deployment Verification
After deployment, verify item by item:
- The overview page shows the base environment and business services as healthy.
- The admin console, merchant console, and H5 open through their bound domains.
- The backend domain serves the health check or the allowed open APIs.
- Gateway logs, business logs, and the task terminal show no recurring errors.
- Before going to production, switch the deployment mode from DEV to PROD — this disables the sandbox and the super admin — then restart the business containers.
Common Failure Points
| Symptom | Check first |
|---|---|
| Docker installation fails | sudo privileges, distro package mirrors, network, and the Docker service status |
| Image build fails | IP data files, dependency download sources, memory, and the specific task logs |
| Base environment unhealthy | Container logs, disk space, port mappings, and the auto-generated credentials |
| Business containers keep restarting | Database password, runtime configuration, image versions, and backend logs |
| Gateway returns 404/502 | Domains, API toggles, container networking, and service health |
For a more complete stage-by-stage approach, see Configuration and Troubleshooting.