MaxKey 4.2.0 on AWS User Guide

Overview

This guide covers launching and using the MaxKey 4.2.0 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg identity, secrets and PKI listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

MaxKey (Dromara MaxKey) is an open source identity management and single sign-on server. It has two parts:

• the SSO portal (/maxkey/), where your users sign in once and open the applications they are allowed to use;
• the management console (/maxkey-mgt/), where administrators manage users, organisations, groups, applications, password policy and access rights.

Applications connect to MaxKey with SAML 2.0, CAS, OAuth 2.0 / OpenID Connect, JWT, token-based or form-based sign-on.

The cloudimg image is a hardened, ready-to-use MaxKey server:

• Built from the upstream release. cloudimg builds MaxKey 4.2.0 from the official source tag (4.2.0) and runs it on OpenJDK 21 from Ubuntu. Dependency versions are raised within their release lines to clear published advisories. Exactly one small source change is made, and it is described below and in Step 16.
• MySQL 8.0, created on your first boot. The database does not exist in the image. First boot creates it, with a password unique to your instance for the maxkey database account. MySQL listens on 127.0.0.1 only. Its root account works only for the operating-system root user (socket authentication), and the binary log is off.
• No default or demo login.
• Upstream's admin / maxkey does not exist, nor do any of upstream's demo users, demo applications, enabled social-login providers, synchronizers or mail credentials.
• First boot creates exactly one administrator, admin, with a random password unique to your instance (and a random internal user id).
• Per-instance keys and secrets. Upstream ships the same keys in every copy of MaxKey:
• a JWT session secret;
• the OAuth/OpenID Connect default signing key and the JWT-login key (one hard-coded RSA private key, GHSA-98j5-7h45-7gj9);
• the SAML keystores (password maxkey). First boot generates your own instance's version of every one of them, and the image never reads upstream's copies.
• HTTPS from the first boot.
• nginx serves MaxKey on 443 with a certificate generated on your instance (an end-entity certificate, not a certificate authority), and port 80 redirects to HTTPS.
• MaxKey's address is set from the instance's EC2 public DNS name at first boot, and every URL it issues uses that name, never the address a request claims. You can change it to your own domain (Step 12).
• Back ends on the loopback address only.
• The portal (127.0.0.1:9527), the console API (127.0.0.1:9526) and MySQL (127.0.0.1:3306) are never reachable from the network.
• A firewall rule (the nftables owner guard) lets only nginx, root and MaxKey's own account connect to them.
• The real client address. nginx sets X-Forwarded-For to the TCP peer and clears the other client-address headers MaxKey reads, so MaxKey's login history and nginx's sign-in rate limits see the real address.
• Advisories open in MaxKey 4.2.0 are closed by configuration (Step 13): the console's MFA switch, passkeys, JWT login, session termination, CAS proxy tickets and the API documentation.
• Metadata service blocked. MaxKey, MySQL, nginx and the first-boot service cannot reach the EC2 instance metadata service, so an LDAP or metadata URL pointing at it fails. The AMI requires IMDSv2.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: MaxKey 4.2.0 (Apache-2.0), OpenJDK 21, MySQL 8.0, nginx, nftables, cloud-init and the AWS Systems Manager agent, all from Ubuntu 24.04 except MaxKey itself.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large (2 vCPUs, 8 GiB)

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
• A security group that allows:
• TCP 22 (SSH) from your own networks only;
• TCP 443 from wherever your users and applications are;
• TCP 80 (it only redirects to HTTPS). Never open 9526, 9527 or 3306: nothing listens on them off the instance.
• For production, a DNS name you control (for example sso.example.com) and, ideally, a certificate from a certificate authority. Until then, the instance uses its EC2 public DNS name with its own self-signed certificate.

Step 1: Launch the instance

1. In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration.
2. Pick MaxKey 4.2.0 on Ubuntu 24.04 as the software version, choose your Region, then Launch through EC2.
3. Choose m5.large, your key pair and a security group as above.

First boot takes about a minute and a half: it creates the database, the keys and the administrator, then starts MaxKey.

Step 2: Connect to your instance

Operating system	SSH user
Ubuntu 24.04	ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

systemctl is-active maxkey maxkey-mgt mysql nginx maxkey-guard
sudo ss -tln | awk 'NR>1 {print $4}' | sort -u

active
active
active
active
active
0.0.0.0:22
0.0.0.0:443
0.0.0.0:80
127.0.0.1:3306
127.0.0.53%lo:53
127.0.0.54:53
[::]:22
[::]:443
[::]:80
[::ffff:127.0.0.1]:9526
[::ffff:127.0.0.1]:9527

Only SSH, HTTP and HTTPS listen on the network. The MaxKey portal (9527), the console API (9526) and MySQL (3306) are on 127.0.0.1 only. [::ffff:127.0.0.1] is how Java's sockets show 127.0.0.1, and 53 is Ubuntu's local DNS resolver.

Step 4: Get your address and the administrator password

First boot writes everything that is unique to your instance to a file only root can read:

sudo cat /root/maxkey-credentials.txt

# MaxKey 4.2.0 - written on first boot by maxkey-firstboot.service. Unique to this instance. Keep it secret.
MAXKEY_PORTAL_URL=https://ec2-203-0-113-10.compute-1.amazonaws.com/maxkey/
MAXKEY_CONSOLE_URL=https://ec2-203-0-113-10.compute-1.amazonaws.com/maxkey-mgt/
MAXKEY_OIDC_ISSUER=https://ec2-203-0-113-10.compute-1.amazonaws.com/sign
MAXKEY_TLS_SHA256=8A:3C:...
MAXKEY_ADMIN_USER=admin
MAXKEY_ADMIN_PASSWORD=<20 random characters>
...

• MAXKEY_PORTAL_URL and MAXKEY_CONSOLE_URL are where your users and your administrators sign in.
• MAXKEY_OIDC_ISSUER is the issuer that OpenID Connect clients on this instance put in their tokens (Step 8).
• MAXKEY_TLS_SHA256 is the fingerprint of the instance's own certificate.
• Your browser will warn that the certificate is not trusted: compare the fingerprint it shows with this one before you continue.
• Do not add the certificate to a trust store. Replace it with a certificate from a certificate authority for your own name instead (Step 12).

Step 5: Run the self-test

The image includes an end-to-end test. It signs in as the administrator, creates a throwaway user, group, OpenID Connect client and CAS client, and then exercises:

• the OpenID Connect sign-in;
• the CAS sign-in;
• enrolment of an authenticator app for two-factor sign-in;
• every refusal listed below.

It then deletes everything it created:

sudo maxkey-selftest

ok   console: the administrator signs in
ok   portal: the administrator signs in
ok   portal refuses upstream's default admin/maxkey
ok   portal refuses upstream demo user sunsx
ok   portal refuses a wrong password
ok   portal refuses the mobile-login bypass (any SMS code, GHSA-gfj2/923q)
ok   console refuses upstream's default admin/maxkey
ok   console refuses upstream demo user sunsx
ok   console refuses a wrong password
ok   console refuses the mobile-login bypass (any SMS code, GHSA-gfj2/923q)
ok   the administrator's failed-sign-in counter is back to its value before the self-test
ok   console API refuses an anonymous call
ok   console: throwaway user created
ok   console: group created
ok   console: user added to the group
ok   console: MaxKey generated an RS256 signing key for the client
ok   console: OIDC client created
ok   console: CAS client created
ok   console: group granted both clients
ok   portal: the throwaway user signs in
ok   OIDC: authorization code issued to the registered redirect URI
ok   OIDC: code exchanged for an access token + id_token (MaxKey 4.2.0 shape: value / additionalInformation.id_token)
ok   OIDC: the client's JWKS publishes the public key only
ok   OIDC: the id_token's RS256 signature verifies against the instance JWKS
ok   OIDC: id_token iss == this instance's issuer (https://ec2-203-0-113-10.compute-1.amazonaws.com/sign)
ok   OIDC: aud / sub / nonce are the client, the user and the request's nonce
ok   OIDC: a tampered id_token (sub=admin) fails verification
ok   OIDC: discovery names this instance's issuer and https://ec2-203-0-113-10.compute-1.amazonaws.com/ endpoints
ok   MFA: the portal generated a TOTP secret for the user (6 digits, 30 s)
ok   MFA: the user enrolled the authenticator (the server accepted a code computed from the secret)
ok   MFA: a current code verifies, a wrong code is refused
ok   CAS: a service ticket is issued for the registered service
ok   CAS: p3/serviceValidate succeeds for the user and its own service
ok   CAS: the same ticket is refused on replay
ok   CAS: a ticket is refused for another service (GHSA-rc95)
ok   CAS: a proxy-callback (pgtUrl) validation is refused by nginx
ok   cleanup: the throwaway clients are deleted
ok   cleanup: the throwaway user is deleted
MAXKEY_SELFTEST_OK

Step 6: Sign in to the SSO portal

1. Open MAXKEY_PORTAL_URL from Step 4 in your browser and check the certificate fingerprint.
2. Sign in as admin with the password from Step 4.

A wrong password, and upstream's default admin / maxkey, are refused.

Step 7: Sign in to the management console and change the administrator password

Open MAXKEY_CONSOLE_URL and sign in as admin. The console's sign-in form also has a field for the code in the picture beside it, and it will not submit while that field is empty: type the code you see. The captcha check is off on this image, so the server does not check the code. MaxKey 4.2.0's console form simply always asks for one. If the sign-in page reloads by itself once as it opens, that is MaxKey replacing a random sign-in token that its own request filter turned down. The page then loads normally.

First, change the administrator's password: choose the user menu (top right), then Change Password. MaxKey's default password policy applies: 6 to 20 characters, with upper and lower case letters, digits and a special character.

Then create your own users and organisations under Identity (users, organisations, groups):

Signing in to the console. The console signs administrators in with a username and password. Its server-side MFA switch (maxkey.login.mfa) is on in this image and must stay on (Step 13). It does not ask an administrator for a second factor at password sign-in. It makes the console check the SMS code on mobile-number sign-in. No SMS provider is configured, so mobile sign-in is refused.

Step 8: Connect an application with OpenID Connect or OAuth 2.0

In the console, open Applications, then Add, then OpenID Connect 1.0 (or OAuth 2.0). Then:

1. Enter the application's sign-in URL and its redirect URI.
2. Choose the scopes (openid, profile, email) and the grant type authorization_code.
3. Under signing, choose RS256 and press Generate to create the client's own signing key.
4. Save, then grant a group (Access, then Groups) access to the application.

The issuer of every client on this instance defaults to MAXKEY_OIDC_ISSUER (https://<your name>/sign). Leave it empty and the instance fills it in, so the id_token carries iss. Your application's endpoints are:

Purpose	URL
Discovery	https://<your name>/sign/authz/oauth/v20/.well-known/openid-configuration?client_id=<client id>
Authorization	https://<your name>/sign/authz/oauth/v20/authorize
Token	https://<your name>/sign/authz/oauth/v20/token
Keys (JWKS)	https://<your name>/sign/authz/oauth/v20/jwks?client_id=<client id>
User info	https://<your name>/sign/api/connect/userinfo

Important: MaxKey 4.2.0's token response layout. MaxKey 4.2.0 answers the token endpoint in its own JSON layout, not with the field names of RFC 6749 / OpenID Connect. This is upstream behaviour in 4.2.0: its move to Spring Boot 4 / Jackson 3 left the token serializer unused, and the unmodified upstream build answers the same way. Many off-the-shelf OAuth 2.0 / OpenID Connect client libraries therefore cannot read the response directly. If you write the client yourself, map the fields like this:

MaxKey 4.2.0 field	Standard name
value	access_token
tokenType	token_type
expiresIn	expires_in
refreshToken.value	refresh_token
scope (a list)	scope (space-separated)
additionalInformation.id_token	id_token

The id_token itself is a standard RS256 JWT. It verifies against the client's JWKS, which publishes only the public key, and it carries iss, aud, sub and your nonce. The self-test (Step 5) runs this whole flow and verifies the signature.

For applications that expect a standard protocol, use CAS or SAML 2.0 (Step 9). They work with off-the-shelf clients on this version.

Step 9: Connect an application with CAS or SAML 2.0

CAS. Add a CAS application:

• set the application's service URL (where users are sent back);
• choose the CasDefaultAdapter adapter;
• grant a group access.

Your application uses https://<your name>/sign/authz/cas as its CAS server; for example, the CAS 3.0 validation URL is https://<your name>/sign/authz/cas/p3/serviceValidate. A ticket validates only for the service it was issued to, and only once. CAS proxy tickets and proxy callbacks (pgtUrl) are refused on this image (Step 13).

SAML 2.0. Add a SAML v2.0 application with your service provider's entity ID and assertion consumer URL, then download MaxKey's IdP metadata from the application's page. MaxKey signs with this instance's own IdP key: first boot creates it, and the IdP keystore is /etc/maxkey/saml/saml-idp.jks.

Step 10: Two-factor sign-in for users

Users can enrol an authenticator app (TOTP: Google Authenticator, Microsoft Authenticator, FreeOTP and similar) in the portal under their profile's one-time password settings. MaxKey generates the secret and shows a QR code, and the user confirms with a current code. The self-test enrols an authenticator this way and checks that a current code verifies and a wrong one is refused.

Know the limit in 4.2.0. MaxKey 4.2.0 does not enforce a user's enrolled second factor when that user signs in with a password (GHSA-g4rp-w5gg-cwjw). Upstream fixed this on its main branch after 4.2.0. Until a MaxKey release with the fix is available, treat per-user two-factor sign-in as not providing protection, and rely on strong passwords and the console access list (Step 11).

Step 11: Restrict the management console to your networks

The console (/maxkey-mgt/) and its API (/maxkey-mgt-api/) can be limited to your own networks in one file:

sudo cat /etc/nginx/cloudimg/maxkey-console-access.conf

1. Replace allow all; with your addresses and a final deny all;, for example allow 203.0.113.0/24; then deny all;.
2. Run sudo nginx -t && sudo systemctl reload nginx.

The portal stays reachable for your users. Every spelling of the console paths is covered: upper case, %-encoded, //, dot segments and ; parameters.

Step 12: Use your own domain and certificate

Point a DNS name at the instance (for example sso.example.com), then run:

sudo maxkey-set-hostname sso.example.com

This command:

• renders nginx and MaxKey for the new name;
• mints a new self-signed end-entity certificate;
• updates the institution's domains;
• moves every OpenID Connect client that still uses the old default issuer to https://sso.example.com/sign.

Applications that trust tokens from this server must be updated to the new issuer.

To use a certificate from a certificate authority, replace /etc/ssl/maxkey/maxkey.crt and /etc/ssl/maxkey/maxkey.key (key mode 0600), then run sudo systemctl reload nginx.

Step 13: Check the security posture

H=$(cat /etc/cloudimg/maxkey-host); IP=$(hostname -I | awk '{print $1}')
for p in /sign/passkey/registration/begin /SIGN/PASSKEY/registration/begin /sign/passkey%2Fregistration/begin \
         /maxkey-mgt-api/passkey/registration/begin /sign/login/jwt /sign/access/session/terminate \
         /sign/authz/cas/p3/proxyValidate /sign/v3/api-docs /sign/actuator/health; do
  printf '%-45s %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code}' --cacert /etc/ssl/maxkey/maxkey.crt --resolve "$H:443:$IP" -X POST "https://$H$p")"
done
for u in ubuntu nobody; do printf '%s -> 127.0.0.1:9527: %s\n' "$u" "$(sudo -u $u curl -s -m 3 -o /dev/null -w '%{http_code}' http://127.0.0.1:9527/sign/login/get)"; done
sudo grep -h -E '^maxkey\.(login\.mfa|passkey\.enabled|login\.jwt)=' /etc/maxkey/mgt/application-maxkey-mgt.properties /etc/maxkey/portal/application-maxkey.properties | sort | uniq -c

/sign/passkey/registration/begin              403
/SIGN/PASSKEY/registration/begin              403
/sign/passkey%2Fregistration/begin            400
/maxkey-mgt-api/passkey/registration/begin    403
/sign/login/jwt                               403
/sign/access/session/terminate                403
/sign/authz/cas/p3/proxyValidate              403
/sign/v3/api-docs                             404
/sign/actuator/health                         404
ubuntu -> 127.0.0.1:9527: 000
nobody -> 127.0.0.1:9527: 000
      2 maxkey.login.jwt=false
      2 maxkey.login.mfa=true
      2 maxkey.passkey.enabled=false

What this shows, and why these settings must stay as shipped:

• Console MFA switch on (maxkey.login.mfa=true in /etc/maxkey/mgt/application-maxkey-mgt.properties): GHSA-gfj2-7r3v-jfjg. With the switch off (upstream's console default), MaxKey 4.2.0's console signs anyone in by mobile number or username without checking the SMS code, including as the administrator. Keep it on until a MaxKey release fixes it.
• Passkeys off and denied (maxkey.passkey.enabled=false; nginx answers 403, or 400 for encoded and ; forms, on every /sign/passkey/ and /maxkey-mgt-api/passkey/ path): GHSA-q2xr-792r-2r22. MaxKey 4.2.0 lets a signed-in user bind a passkey to someone else's account. With passkeys off, the cloudimg build does not register MaxKey's passkey endpoints at all (Step 16). Keep passkeys off until a MaxKey release fixes it.
• JWT login off and /sign/login/jwt denied (GHSA-98j5-7h45-7gj9; the JWT-login key is also unique to your instance).
• Session termination by a user denied (/sign/access/session/terminate, GHSA-6vx4-gvc8-5hfw: no ownership check in 4.2.0). Administrators can still end sessions in the console.
• CAS proxy tickets and proxy callbacks refused, and the API documentation and actuator paths are not exposed.
• The nftables owner guard is part of the security model. It is what stops other local accounts (here ubuntu and nobody, refused with 000) from talking to MaxKey without nginx in front. Do not disable it, flush it or stop nftables. MaxKey stops if it is removed.

Step 14: Passwords and secrets

• The administrator password is in /root/maxkey-credentials.txt. Change it in the console (Step 7) and then delete it from that file.
• The database password, the JWT session secrets, the SAML keystore password and the Kerberos crypto key are in /etc/maxkey/secrets/ (root only). The rendered configuration in /etc/maxkey/portal/ and /etc/maxkey/mgt/ is readable by root and MaxKey only.
• The JWK key sets (/etc/maxkey/classpath/config/) and SAML keystores (/etc/maxkey/saml/) were generated on your instance. Each OpenID Connect client's signing key is generated in the console when you create the client.
• No secret is on any command line, in a systemd unit or in a log. MaxKey logs to the journal at INFO level only.

Step 15: Your data and backups

Everything MaxKey stores (users, organisations, applications and their keys, access rights, history) is in the MySQL database maxkey. Back it up to a file only root can read:

sudo sh -c 'umask 077; mysqldump --single-transaction --routines --triggers maxkey > /var/backups/maxkey-$(date +%F).sql'
sudo ls -l /var/backups/ | grep maxkey

-rw------- 1 root root  74907 Oct 31 21:41 maxkey-2026-10-31.sql

The dump holds password hashes and application signing keys, so store it encrypted and off the instance. Keep a copy of /etc/maxkey/ (root only) with it: the JWK sets, SAML keystores and secrets there go with the database. EBS snapshots are a simple way to keep point-in-time copies of the whole server.

Step 16: Licences, source and the cloudimg change

ls /usr/share/doc/cloudimg-maxkey/
sed -n '1,3p;/^patch (d-725)/,/^removed:/p' /usr/share/doc/cloudimg-maxkey/BUILD-INFO

3rdpartylicenses-mgt.txt
3rdpartylicenses-portal.txt
BUILD-INFO
LICENSE-maxkey-Apache-2.0.txt
NOTICE-maxkey.txt
SOURCE.txt
passkey-endpoints-conditional.patch
MaxKey 4.2.0 - cloudimg build of the pinned upstream tag (one coordinator-ruled minimal patch, d-725; nothing else changed)
source:       https://github.com/dromara/MaxKey.git tag 4.2.0 commit e147ade6a3c5f2e11a202b3e66c4522605bc4c6d (Apache-2.0, LICENSE sha256 9bab590ff9e938c73b25eb45a3edb01e81ae573982ab9cdf08448f6ddfff4896)
toolchain:    openjdk version "21.0.12.1" 2026-08-18; Gradle 9.1.0 (sha256 a17ddd85a26b6a7f5ddb71ff8b05fc5104c0202c6e64782429790c933686c806); node v24.22.2; pnpm 12.6.0
patch (d-725): passkey-endpoints-conditional.patch sha256 c6cfd28eb82ec3fafbee7f67a69847f4cb858984022691cc748d357c6d344831 (cloudimg-authored, Apache-2.0, 10 added lines in
              maxkey-starter/maxkey-starter-passkey/src/main/java/org/dromara/maxkey/passkey/endpoint/Passkey{Registration,Authentication}Endpoint.java: @ConditionalOnProperty(prefix="maxkey.passkey",
              name="enabled", havingValue="true", matchIfMissing=true), so with passkeys off the endpoints are not registered;
              GHSA-q2xr-792r-2r22. The diff ships in /usr/share/doc/cloudimg-maxkey/.)
removed:      taobao-sdk-java-auto_1479188381469-20210326.jar (sha256 b57882f9fc4e0845a29e3eee285b1866b54b72f7f89c349438d19d77bae99121; DingTalk SDK, no licence) from both boot jars, and

MaxKey is licensed under the Apache License 2.0. The front-end libraries and their licences are listed in 3rdpartylicenses-portal.txt and 3rdpartylicenses-mgt.txt.

The one source change. cloudimg adds one annotation to each of MaxKey's two passkey endpoint classes (passkey-endpoints-conditional.patch, 10 added lines, Apache-2.0, shipped in this directory). The endpoints are then registered only when passkeys are enabled (maxkey.passkey.enabled), the same condition MaxKey's own passkey configuration uses. Upstream 4.2.0 registers them even with passkeys switched off (GHSA-q2xr-792r-2r22). Nothing else in MaxKey is modified.

What is not shipped, for licence reasons:

• the DingTalk open-platform SDK, which is distributed without a licence. DingTalk directory synchronisation is not available; LDAP, Active Directory, WeCom, Feishu and JDBC synchronizers are.
• the MaxMind GeoLite2 database (GeoLite2 EULA). Sign-in location lookup uses the bundled ip2region database only; the GeoIP2 provider option is not available.

Step 17: Security notes

• Advisories. MaxKey 4.2.0 is the current release.
• The advisories that are still open in it are closed on this image by configuration and the change above (Step 13). The exception is GHSA-g4rp (Step 10).
• The bundled Java libraries were raised to versions without known issues where a fix exists in their release line. Six findings remain, and none is reachable in this configuration:
  • the captcha library kaptcha 2.3.2: predictable captcha text (CVE-2018-18531). The captcha check is off on this image. The console's sign-in form still shows a picture, but its code is not checked.
  • velocity 1.7 (CVE-2020-13936): exploitable only by editing templates. MaxKey uses its own built-in SAML POST template.
  • commons-httpclient 3.1 and not-yet-commons-ssl 0.3.9 (CVE-2012-5783, CVE-2014-3604): no host-name check on TLS. They are used only by the legacy SAML library to fetch remote metadata over HTTPS. Upload SP metadata rather than pointing MaxKey at a URL.
  • commons-lang 2.6 (CVE-2025-48924): a stack overflow on very long class names. No user input reaches it.
  • the OGNL copy inside MyBatis 3.5.19 (CVE-2026-113730): it evaluates only MaxKey's own SQL mapping expressions.
• In the console's front end, the rich-text editor Quill 2.0.3 has a low-severity issue with no fix (CVE-2025-15056). It is reachable only by signed-in administrators.
• Outbound requests. MaxKey connects to URLs that administrators configure: LDAP directories, synchronizers, SAML and OpenID Connect metadata. Those connections cannot reach the EC2 metadata service.
• Captcha, self-registration, social sign-in and "remember me" are off. Configure an SMTP server and SMS provider in the console if you need password-reset mail or SMS codes.
• One server. Sessions are kept in memory, so restarting MaxKey signs everyone out. Use a single instance, or put Redis behind it for a cluster (maxkey.server.persistence=2).

Support

cloudimg provides support for this image by e-mail at support@cloudimg.co.uk. MaxKey itself is documented at https://www.maxkey.top/.