-
Notifications
You must be signed in to change notification settings - Fork 0
Playgroup Shared Instance Setup
OpenMTG supports multiple user accounts on a single server, making it practical to share one instance with friends or a playgroup. This page covers how to think about that setup, how to get everyone onboarded, and what hardware to expect.
OpenMTG uses an admin-managed account model:
- One admin account is created on first launch. This person manages the server.
- All other accounts are created by the admin. Users cannot self-register.
- Each user's data is fully isolated. Collections, decks, and wishlists belong to the individual account and are not visible to other users.
There is no concept of shared collections or visibility between users in the current release. Every account is its own silo.
Coming in v1.8 - Showroom: Users will be able to opt in to making their collections and decks visible to others on the same instance.
Coming in v1.9 - Trading: Formal trade proposals and approvals between accounts on the same instance.
Follow the standard Installation guide. The admin should be the person who owns or manages the server as they'll need access to the .env file and the Docker host.
On first launch, OpenMTG prompts for an admin username and password. Complete this before sharing the URL with anyone else.
- Log in as admin
- Go to Admin > User Management
- Click Create User and fill in the username and a temporary password
- Share the URL and credentials with each user, they can change their password from Settings after logging in
Admins can assign a preferred currency per user from the User Management table. This takes effect immediately.
Each user account is completely separate:
| Data | Shared? |
|---|---|
| Card cache (names, images, Scryfall data) | Yes: shared server-wide to reduce API calls |
| Prices (Scryfall-sourced) | Yes: shared and refreshed once per cycle |
| Collection entries | No: per-user |
| Decks | No: per-user |
| Wishlist | No: per-user |
| Settings (currency, etc.) | No: per-user |
The shared card cache is a performance optimization. Individual card data (quantity, condition, foil, etc.) is always per-user.
OpenMTG is lightweight. For a small playgroup, even modest hardware is sufficient.
| Users | Recommended RAM | Notes |
|---|---|---|
| 1–3 | 1 GB | Comfortable on a Raspberry Pi 4 or low-end VPS |
| 4–8 | 2 GB | PostgreSQL and background price refresh have room to breathe |
| 9–15 | 4 GB | Recommended for larger groups, especially if price refresh and active browsing overlap |
Storage: Minimal. The PostgreSQL database grows slowly. A collection of 10,000 cards across all users should remain well under 100 MB. Docker images and OS overhead are the main consumers; plan for 4-8 GB total on the host.
CPU: One or two cores is fine for typical workloads. The price refresh scheduler is the most CPU-intensive background task, but it rate-limits itself to Scryfall's API cap.
Network: OpenMTG only needs outbound internet access to reach api.scryfall.com and api.frankfurter.app (for exchange rates). Inbound access is whatever you expose (LAN-only, Tailscale, or public with a reverse proxy).
For a private playgroup, running on a local network or VPN is simpler and safer than exposing the instance to the public internet.
Tailscale is a popular option, install it on the host and each user's device, and the instance is reachable by IP without opening firewall ports.
If you do expose it publicly, put it behind a reverse proxy (nginx, Caddy, Traefik) with HTTPS. OpenMTG does not handle TLS itself.