Deployment
The standard shape: jar + MySQL + reverse proxy. This site ships no container images or orchestration files.
Note: this page covers standard (non-containerized) deployment only: JDK + jar + MySQL + reverse proxy. Container images and orchestration files are out of scope; package it to your own operations standards if you need them.
Build the artifact
build runs every test and guard rule; the result is a single executable jar.
Prerequisites
| Item | Requirement |
|---|---|
| JDK | 21 (same version as the build) |
| Database | MySQL 8.0+, schema and account created in advance |
| Environment variables | exactly matching .env.example; one missing variable fails startup |
| Directories | log and upload directories must be writable, paths come from config, not hardcoded |
Start it
In production, hand it to a process manager (systemd / supervisor / Windows service, your choice). The core requirements are restart on exit and logs written to disk; neither is framework specific.
Reverse proxy and health checks
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
- Use the application's own health endpoint; do not build a
/pingcontroller (it bypasses deny-by-default authorization). - Configure the upload size limit at both the gateway and the application; the server-side allowlist is the last line.
Upgrade and rollback
- Back up the database first — migrations are append-only, but the backup is still the only rollback insurance.
- Stop the service and keep the old package (rollback means putting the old package back).
- Swap in the new package, start it, and watch whether every migration ran.
- If startup fails, put the old package back and restore the backup. Never edit scripts while running.
Tip: a cross-version upgrade does not touch your business code. Customization lives in your business repository; upgrading the core affects the core only.