spillebulle/trove repository overview

⁠Trove

Claims the games that are temporarily free on stores you already have accounts with: Epic, Steam, GOG, itch.io and Prime Gaming. Self-hosted, one browser profile per account, a ledger of every attempt, and Discord or webhook notifications.

Source and full documentation: https://github.com/Spillebulle/Trove⁠

⁠Run it

services:
  trove:
    image: spillebulle/trove:latest
    container_name: trove
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./data:/data
    environment:
      - ADMIN_PASSWORD=pick-something
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Oslo
    shm_size: 1gb

Then open http://localhost:8080 and sign in as admin.

shm_size: 1gb is not optional. The image runs a real Chrome, and below about 512 MB of /dev/shm it crashes part-way through a store page, which looks like a claim failing for no reason on some games and not others.

linux/amd64 only. The image installs real Google Chrome, and Google ships no Chrome for Linux on arm64. Read on for why that matters.

⁠What it does

Trove signs in to your own store accounts on your own machine, on a schedule, and claims what is being given away. It keeps a browser profile per account rather than a password, so a healthy account signs in once by hand and never again. There is no password field anywhere in the app.

Finding out what is free costs one request to a public endpoint and touches no account, so the browser only wakes up when there is something to claim. When a store asks a question Trove cannot answer, it stops, screenshots what it saw, marks the account, and tells you. It does not retry.

⁠The one thing to know before you start

Every account needs one sign-in by hand. The container has a virtual screen of its own, and "Sign in here" opens that account's Chrome on it with nothing attached to it - no remote control, no automation flags - and shows you the screen in the page. You sign in, answer whatever the store asks, and press "Done, close the window". Trove reuses that session from then on.

If a store keeps looping you through a verification there, the address is the usual reason: a datacenter address is challenged far more readily than a home one, and BROWSER_PROXY (socks5://host:port) points the browser's traffic somewhere else without moving Trove. Failing that, sign in on a desktop running Trove and copy that account's folder:

data/profiles/<id>-<slug>/

into the container's volume at the same path, and choose Check the session on the account. Trove asks the store whether the session is good rather than assuming, so a profile that did not survive the trip says so.

Everything after that - the schedule, claiming, the ledger, notifications - runs in the container normally.

⁠Configuration

Back up ./data. It holds the database, the encryption keys and your signed-in browser sessions; lose it and every account signs in by hand again.

⁠Status

Early, and specific about which parts. The whole loop has run once against a real Epic account in a container: a giveaway found, the checkout driven, the captcha finished by a person, the game read back out of the library and written to the ledger. The other four stores have adapters whose discovery is measured against the live service and whose claiming has not yet met a live giveaway. The repository's CLAUDE.md keeps an honest list under "What is verified and what is not".

⁠Licence

GPL-3.0. Trove automates logins to stores you already have accounts with, for your own accounts, on your own machine. That can breach a store's terms of service, and it is your call to make.