Example app: beanguard-demo

beanguard-demo is a small, runnable Spring Boot app in the same repository as beanguard-client — the fastest way to see a full integration (fetching a licence, reading its status, refreshing, extending, transferring) working before you wire one into your own app.

Running it

You need a running beanguard-server (see Quick start). Start the app — no configuration required beforehand:

cd beanguard-demo
mvn spring-boot:run

Then open http://localhost:8090. With no server connection configured yet, the Server connection panel (collapsed, at the top of the page) is the easiest way to set one up: paste in the server URL and the public key/AES secret from Cryptographic keys in the admin panel, then click Save & reconnect — no restart needed.

That panel stores a real cryptographic secret (the AES key) server-side without any extra protection. Fine for a local demo, not a pattern to copy into a production client app.

Alternatively, set BEANGUARD_SERVER_URL / BEANGUARD_SERVER_PUBLIC_KEY / BEANGUARD_SERVER_SECRET_KEY as environment variables (or edit beanguard-demo/src/main/resources/application.yml) before starting — this becomes the default until something's saved via the panel, which then takes precedence.

Persistence profiles

Profile	Behaviour
`memory` (default)	The server connection (if set via the panel), licence key/secret, and any pending transfer all live only in memory — restarting the app clears them and the demo licence form reappears.
`file`	Persisted to `./beanguard-demo-data/` (relative to the working directory) — survives restarts.

Switch profiles with --spring.profiles.active=file, or edit spring.profiles.active in application.yml.

The memory profile is a good way to see how your own app behaves when loadLicence() has nothing cached yet after a restart. It's also why the transfer flow below exists — it's the recovery path for a licence secret lost that way.

What you can test

Get a demo licence — with no licence loaded, the app shows a form asking for an email and VAT/NIP number. Submitting it calls the server's self-service endpoint, which issues a DEMO licence (see Demo licences) and immediately displays its claims, expiration, and key.
Refresh — re-fetches the current licence from the server on demand, instead of waiting for beanguard-client's hourly automatic refresh. Useful right after editing claims or extending the licence from the admin panel.
Extend — redirects into beanguard-shop carrying the licence's identity, the same path an end customer follows to buy an extension.
Transfer to a new machine — the empty-state screen also has a second form for entering an existing licence key, simulating a reinstall (or recovering a memory-profile licence lost on restart). The server emails a confirmation link — if you're running the server's own docker-compose.yml, check Mailpit for it — that has to be opened once; then click Check status on the demo page to pick up the new secret.

Where to look in the code

FileBeanGuardConfiguration / InMemoryBeanGuardConfiguration (dev.beanguard.demo.licence) — the two BeanGuardConfiguration implementations behind the file/memory profiles, including updateServerConfig() behind the Server connection panel. Compare them to the Implementing BeanGuardConfiguration example.
DemoController — the only class talking to LicenceRegistry and BeanGuardServer directly; a template for the Reading licence status pattern in your own app.

DemoLicenceKeyStore extends BeanGuardConfiguration with a few extra methods (storeLicenceKeys, pending-transfer bookkeeping) used only by the demo app's own screens — they aren't part of the beanguard-client contract, so your own implementation doesn't need them.