Configuration and Troubleshooting
This page concentrates the configuration you won't touch every day but that directly affects deployment security and runtime stability. After a configuration change, distinguish the three ways changes take effect: "restart the service", "redeploy the container", and "apply gateway configuration". Gateway domain binding, CDN fronting, and external endpoint exposure live in their own chapter, see Gateway Management.
Memory Tiers
The panel offers three preset tiers that batch-adjust service memory limits and the JVM type:
| Tier | Recommended host memory | Total footprint | JVM default | Fits |
|---|---|---|---|---|
| compact | ≥ 4 GB | ~3.1 GB | OpenJ9 | Low-spec servers or testing |
| standard (recommended) | ≥ 8 GB | ~6.3 GB | HotSpot | Regular production |
| enhanced | ≥ 16 GB | ~12.9 GB | HotSpot | High-concurrency production |
The panel recommends a tier from the host memory automatically, keeping about 512 MB of headroom. Applying a tier only writes configuration — the affected services must be redeployed before the container limits change. A service edited by hand is marked "custom"; reapplying a preset tier restores the unified configuration.
Runtime Configuration
Business runtime parameters — deployment mode, sandbox, log level, and so on — are maintained in the panel: open Operations → Business Environment, then the "App Config" drawer on the main-application card.
| Setting | Description |
|---|---|
| Deployment mode | DEV for integration; PROD for production |
| Sandbox | Sandbox switch, effective in DEV only; cannot be turned on under PROD |
| Super admin | Super admin switch, effective in DEV only; cannot be turned on under PROD |
| Trade sync | Scheduled sync for orders / refund reconciliation; recommended on in production |
| Log level | INFO / WARN / DEBUG; DEBUG is verbose — use it only for temporary troubleshooting |
Changes take effect after restarting the business containers — no redeploy or image rebuild required. The deployment mode also applies to the channel sub-applications: restart them and they follow the main application automatically. Before going live you must switch the deployment mode to PROD; the sandbox and the super admin are then forced off.
Do not hand-edit the runtime configuration on the server
These parameters are managed by the panel and injected into the containers; hand-editing the generated configuration file will be overwritten the next time the panel saves its configuration. PostgreSQL / Redis / Artemis passwords are not maintained there either: use "Change Password" on the corresponding service card under Operations → Base Environment — the panel updates the middleware itself in sync. Editing the file by hand only leads to authentication failures and restart loops in the business containers.
Port Exposure
Except for the gateway, base-environment and business containers publish no ports to the host by default; all services talk over the Docker network and are proxied by the gateway.
| Mode | Behavior | Fits |
|---|---|---|
| off (default) | No host ports published | Production |
| local | Bind to 127.0.0.1 | Local debugging or SSH tunnels |
| public | Bind to 0.0.0.0 | Special cases only; must be paired with a firewall |
Switching port mappings requires redeploying the affected containers. Unless clearly needed, do not use public — avoid exposing the database, cache, or backend debug ports straight to the internet.
How Changes Take Effect
| Change type | How it takes effect |
|---|---|
| Business runtime parameters in the "App Config" drawer | Restart the affected business containers |
| Memory tier, run mode, image version | Redeploy the affected containers |
| Port exposure, resource limits, exposure mode of a single service | The drift banner shows a "Redeploy <service>" button that rebuilds only that container |
| Gateway domains, access mode, endpoint toggles | Apply gateway configuration; redeploy the gateway if necessary |
| Docker engine configuration | Restart Docker as prompted |
| Panel account, secure entrance | Effective immediately after saving; entrance changes invalidate the old URL |
Troubleshooting
Installation Stage
Online download fails or SHA256 verification fails
Confirm the server can reach the download source, then fetch the install.sh and archive matching your version again. You can also point to a mirror source, or switch to offline installation. Do not skip SHA256 verification.
xz missing
# RHEL family
dnf install -y xz
# Debian family
apt-get install -y xz-utilsAfter the installation completes, rerun the install script.
Offline installation doesn't find the package
Confirm that install.sh and the .xz file are in the same directory, and run bash install.sh or an authorized ./install.sh. The script does not scan $PWD for files.
Login Stage
Opening the panel returns 404
With the secure entrance enabled, accessing the IP and port without the entrance path returns 404. Run:
daxpay entrance showForgot the initial password
daxpay info
cat /opt/daxpay/installer-initial-password.txtLocked out by failed logins
Consecutive wrong passwords trigger the lockout. Run:
daxpay unlockPanel unreachable after enabling domain restriction or the IP allowlist
Access from a new network / new IP gets refused or a fake 404. Run the following to check the current restrictions, and disable them if necessary:
daxpay domain show
daxpay ipallow showTwo-step verification authenticator unavailable
If the authenticator is lost and the recovery codes are exhausted, run daxpay twofactor disable on the server, then re-bind. For the recovery channels of all lockout scenarios see Panel Security - Lockout Recovery Channels Summary.
Runtime Stage
Port conflicts
Check whether 8060 or 80 is held by another process. The panel can move to another port with --port; the gateway port requires stopping the occupying service or adjusting the gateway plan. The overview page lists gateway and business service port conflicts (the panel's own port is not covered).
Business backend unhealthy or crash-looping
Check the business container logs and the task terminal first: if the logs report database / Redis / Artemis authentication failures, run "Change Password" on the corresponding service card under Operations → Base Environment to realign, then restart the business containers; then check disk, memory, and the runtime configuration.
Mini programs / apps cannot sign in
Open "Gateway Management → External Endpoints" and read the status line at the bottom of the "Mini program / APP API" card to identify the current access route. If it shows the broken route, turn the toggle back on (compatible route), or bind a Mobile API domain and enter it as the API base URL when building the mini program (dedicated route); click "Apply Gateway Configuration" afterwards. Already published mini programs update asynchronously — existing clients only pick up toggle or domain changes after a version update rolls out.
A drift banner appears on the page
The banner routes precisely by service:
- "Redeploy
<service>": that service's port exposure, resource limits, or exposure mode changed but has not reached the container — clicking rebuilds only this one container, other services are unaffected; - "Redeploy" (whole stack, with an impact note): stack-level changes such as version, JVM type, or memory tier affect all services — every enabled container is rebuilt and all services are briefly interrupted;
- "Apply gateway configuration": gateway configuration was saved but nginx has not reloaded — click to apply.
Panel shows not-deployed but containers are actually running
The panel judges state from runtime container probing and deployment snapshots. Manually started containers may have no snapshot — refresh the panel first; if it is still unrecognized, run a deploy once on the corresponding page so the panel adopts the current environment.
Collecting Diagnostic Information
When the panel is unreachable, run the following to collect status and logs:
daxpay status
daxpay logs --installer
daxpay logs -fAlso record the OS and architecture, the panel version, the daxpay status output, the full logs of failed tasks, the state of the related containers, and the most recent configuration change. Redact passwords, private keys, and tokens before sharing logs with anyone.