log-lottery: a three.js and Vue 3 sphere draw for company events

What log-lottery is for, and who operates it

log-lottery is a configurable raffle application whose main visual is a 3D sphere of participant cards rendered with three.js. The README describes it as suitable for annual company parties and similar prize draws, and the repository topics list 3d, daisyui, lottery, lucky, lucky-draw, prizes, raffle, threejs, vue3 and vue3-typescript. The intended operator is one person at a PC: the README states that the latest desktop version of Chrome or Edge is required, and it does not describe a mobile layout or a multi-operator mode.

The configuration surface is broader than the draw itself. According to the README, you can manage prizes and their draw counts, import the participant roster from an Excel template, set whether a prize is open to everyone, change the title, the number of columns, card colours and the home page artwork, and attach background music. There is also a temporary draw feature for adding people on the spot. One line in the README is worth reading before anything else: the project states that it does not support rigged draws. That is a design position rather than a missing feature, and it tells you the author expects the result to be whatever the random pick produces.

How the 3D draw and local storage actually fit together

The application is a Vue 3 single-page app built with Vite. The package manifest lists three.js 0.166.0 and three-css3d for the sphere, pinia with pinia-plugin-persist for state, dexie and localforage over IndexedDB, xlsx for spreadsheet import and export, vue-i18n for the multilingual interface, and daisyui with tailwind-merge for styling. The repository root also contains a src-tauri directory and a ws_server directory, which indicates a Tauri desktop packaging path and a WebSocket component, though the README does not document what the WebSocket server is used for.

The data flow is deliberately local. The README states that uploaded images and music are stored in IndexedDB in the browser, and the same applies to the participant and prize configuration. Nothing in the README describes a backend database or an account system. The practical consequence is that the roster and the results live in the browser profile of the machine that ran the draw. Export to Excel is the documented way to get results out. If the browser profile is cleared, or the operator opens the site on a different machine, that data is not there. The README itself warns that if images fail to display or errors appear on entry, you should open the global configuration, go to the interface configuration menu, and press the reset all data button before updating.

Installing log-lottery with Docker and running a first draw

The fastest documented path is the published Docker image. The README gives a pull command and a run command that maps container port 80 to host port 9279. Run them in order and the container starts in the background under the name log-lottery.

docker pull log1997/log-lottery:latest
docker run -d --name log-lottery -p 9279:80 log1997/log-lottery:latest

Once the container is running, the README says the app is reachable at http://localhost:9279/log-lottery/. Note the trailing path: the Dockerfile redirects the root path to /log-lottery/ and serves the built files from /usr/share/nginx/html/log-lottery, so opening http://localhost:9279/ without the path will bounce you to the right place rather than showing a blank page.

If you would rather build from source, the Dockerfile uses node:22-alpine as the builder, installs pnpm globally, runs pnpm install and pnpm build, then copies the dist directory into an nginx:1.26 image. The README documents the equivalent manual commands, and the package manifest shows the dev server binds to all interfaces.

pnpm i
pnpm dev

The README also lists npm install and npm run dev as alternatives. For a local build without Docker, pnpm build runs vue-tsc --noEmit before vite build, so a type error stops the build rather than being skipped.

After the app loads, the first real task is the roster. The README says you download an Excel template from the people configuration management screen, fill it in to the required format, and import it. Then you add prizes in the prize configuration screen, where you set the name, the number of winners to draw, whether the prize is open to all participants, and the image shown. The interface configuration screen covers the title, column count, card colours and home page artwork. Only after those three steps does the draw screen make sense, because the sphere is populated from the imported roster.

The single-browser constraint is the real limitation

The architecture that makes log-lottery easy to deploy is also its main weakness. Because participant data, prize configuration, images and music are held in the browser's IndexedDB, the draw is tied to one browser profile on one machine. The README does not document any server-side persistence, any account system, or any way to share a roster between two machines. It also does not document rollback of a completed draw, so if the operator accidentally draws the wrong prize, the documented recovery path is not stated.

That matters for the situations where a raffle is most sensitive. A large company draw where the audience expects an independent record, or a draw where the result is disputed afterwards, has no server-side log to point at in this design. The Excel export is the artifact you keep. If your organisation needs an audit trail, a second observer running the same draw, or participants joining from their own devices, this is the wrong tool. The README's browser requirement reinforces the point: it asks for the latest desktop Chrome or Edge, and says nothing about Safari, Firefox or phones.

The desktop packaging is also narrower than the web app. The README states that a software installer is available from the Releases page and that only Windows is currently supported, with cross-platform installers not yet available and users expected to compile their own following the contributing document. So the Tauri path, which is visible in the repository layout, is not presented as a general cross-platform distribution route.

How it differs from a plain spreadsheet or a general web framework

The obvious alternative is a spreadsheet with a random function, and the difference is presentational rather than statistical. A spreadsheet gives you a result in a cell; log-lottery gives you a rotating 3D sphere of cards that resolves into winners, with confetti, background music and a configurable stage. For an annual party projected onto a screen, that presentation is the product. The README's own framing supports this: the first completed TODO item is the 3D sphere described as ready to use out of the box.

A second comparison point is the project the README credits: the idea is said to come from https://github.com/moshang-xc/lottery. That project is the ancestor of this one, and log-lottery's own additions are the configuration screens, the Excel import and export, the multilingual interface, the Docker image and the Tauri packaging. If you only need a simple browser draw and no configuration UI, the older project is the smaller dependency. If you need to hand the tool to a non-technical colleague who will set up prizes and a roster the day before the event, the configuration layer here is the part that saves time.

The third alternative is writing the draw yourself. Nothing in log-lottery is statistically exotic; the value is the assembled interface, the three.js scene and the IndexedDB persistence. A team with Vue and three.js experience could reproduce the draw logic quickly, but would then own the Excel handling, the i18n layer and the packaging, which is where most of the repository's code sits.

Maintenance, packaging and the MIT licence

The repository is not archived, and the last push was on 2026-06-04. The most recent releases listed are v0.6.0-5, v0.6.0-3 and v0.6.0-2, all beta tags from early 2026, and the package version matches v0.6.0-5. So the project is shipping versioned prereleases rather than a stable 1.0, and the release names carry the beta label. That is worth knowing before you promise a fixed version for an event: pin the image tag or the release you validated rather than pulling latest on the day.

The upgrade cost is mostly a browser-cache problem. The README's own troubleshooting note tells users to reset all data through the global configuration screen when images break or errors appear after an update, which implies that stored IndexedDB data can outlive the code that wrote it. If you keep the roster in the app, an upgrade may mean re-importing it. Export your participant list and results before you change versions.

Licensing is straightforward on paper: the repository is MIT licensed, and the manifest declares "license": "MIT". MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That covers the code in this repository. It does not automatically cover everything the app loads or displays: if you import a company logo, play licensed music through the music configuration, or use artwork you did not create, those are separate rights, and the README's support section shows a sponsorship image rather than a licence review. This is a description of what the licence text says, not legal advice for your event.

Editorial conclusion

Adopt log-lottery if you are running a single-machine prize draw on a PC with Chrome or Edge and you want the 3D sphere presentation without writing any code. Do not adopt it if you need remote participants, server-side audit trails, or a draw that a second party can verify. Before the event, verify the version you are deploying, run the Docker container and open http://localhost:9279/log-lottery/ to confirm the asset paths resolve, and test your Excel import with the template downloaded from the people configuration screen.

Frequently asked questions

Official sources

1. License: MIT
2. LOG1997/log-lottery on GitHub
3. Project website
4. README
5. Releases