Self-Hosting Garrison

Garrison is built to be run by the people who actually run the community. One installer brings up chat, voice, the web app, and the database, with automatic HTTPS, on your own hardware or a cheap VPS. No cloud lock-in, no monthly bill, no data mining.

What you'll need

A Linux box (Ubuntu or Debian), a small VPS or a spare machine. 2 vCPU / 2 GB RAM is plenty for a typical guild; voice scales with your member count.
Docker: the installer will install it for you if it's missing.
For a public server: a domain name pointed at the box, and ports 80/443 (web/signaling) plus 7881/TCP and 7882/UDP (LiveKit media) reachable.
For a private server: nothing but the LAN, Garrison can run LAN-only with a self-signed cert.

Recommended hardware

Garrison is light. The Go API and gateway sip resources, in load testing they handled 100 concurrent real-time connections and 15,000 fan-out events at a ~39 ms p99 while using only ~15 MB of RAM. So for a text-first community, almost any box will do. What actually drives sizing is voice, video, and screen-share (the LiveKit SFU) and, to a lesser degree, PostgreSQL. Use these tiers as a starting point and scale the part that's under pressure.

Tier	Good for	vCPU	RAM	Disk (SSD)	Bandwidth
Small	A guild, up to ~50 members, light voice (a handful talking at once)	2	4 GB	40 GB	~1 TB/mo
Medium	An active community, ~250 members, regular raids, 1-2 busy voice rooms	4	8 GB	80 GB	2-4 TB/mo
Large	~1,000+ members, many concurrent voice channels, some video / screen-share	8	16 GB	160 GB NVMe	high / unmetered
Enterprise	Thousands of concurrent users, heavy video & screen-share, HA	16+	32-64 GB	320 GB+ NVMe	1 Gbps+ / unmetered

📊

What scales with what: text chat, presence, and history are cheap and scale to thousands on modest hardware. Voice is CPU- and bandwidth-bound, budget for concurrent talkers, not total members. Video and screen-share are the most expensive streams by far, so size up the moment they're in regular use. PostgreSQL wants an SSD (NVMe at the larger tiers) and benefits most from RAM.

🧱

Scaling past one box: for Large and Enterprise, the cleanest first split is moving the LiveKit media server onto its own machine (give it the CPU and bandwidth headroom), and optionally running PostgreSQL on a dedicated/managed instance. The API and gateway stay small. Make sure the LiveKit media ports (TCP 7881, UDP 7882) are reachable on whichever host runs it.

Which tier am I?

Size to your busiest moment, not your member count. The best proxy is: how many people are in voice at once during your peak event?

Mostly text, voice now and then → Small, even with a big roster. Text scales for free.
One raid night, a couple of full voice channels → Medium.
Several simultaneous raids, or regular video / screen-share → Large.
Thousands online at once, heavy video, can't tolerate downtime → Enterprise (and split LiveKit off, as above).

When you're between two tiers, start at the lower one, Garrison is light, and resizing a VPS up takes minutes. Watch CPU and upstream bandwidth during your first big event and bump up only if they're pegged.

VPS or your own hardware?

Both work, the installer is identical. It comes down to who you want handling the network and uptime.

	Cloud VPS	Your own box (home/office)
Best for	Public servers anyone can reach.	LAN-only servers, or privacy maximalists who want the metal in the room.
Networking	Public IP, good bandwidth, and clean ports come included, automatic HTTPS just works.	You handle port-forwarding (80/443 + 7881/7882), a static IP or dynamic DNS, and your router/firewall.
Bandwidth	Generous, symmetric, predictable, ideal for voice/video.	Residential upload is often the bottleneck; voice/video for many users can saturate it.
Cost	A monthly bill that scales with the tier (roughly a few dollars up to enterprise pricing).	No monthly bill, just power and the hardware you already own.
Upkeep	Provider handles power, cooling, and hardware failure.	You own uptime, power cuts, ISP outages, and dead drives are on you.

💡

Rule of thumb: if the wider internet needs in, a VPS is the low-friction choice. If it's purely for your LAN or you specifically want to own the hardware, run it at home in LAN mode. A common hybrid is a small VPS for the public edge with heavier tiers added as the community grows.

Install, public server (automatic HTTPS)

Clone the repo onto the server, then run the installer with your domain and an email for Let's Encrypt expiry notices. It generates all secrets, writes the config, brings up the stack, and obtains a certificate.

bash

# from the repo root, on a fresh Ubuntu/Debian box
sudo ./install.sh --domain chat.yourguild.gg --email you@guild.gg

When it finishes you'll see your stack come up and a confirmation that Garrison is live at https://chat.yourguild.gg. Open it, register the first account, and you're the owner.

🌐

Point an A/AAAA record for your domain at the server's public IP before you run the installer, Let's Encrypt verifies the domain over HTTP, so it must resolve to this box. Make sure your domain has only that record (no leftover parking/forwarding records), or certificate issuance can fail.

Install, LAN-only (private network)

No domain, no public exposure? Run it on your home or office network. Garrison still serves HTTPS (with a self-signed certificate from a built-in CA) because the encrypted-channel crypto and the installable PWA both require a secure context.

bash

# auto-detect this box's LAN IP
sudo ./install.sh --lan

# …or pin a specific address / hostname
sudo ./install.sh --lan --host 192.168.1.50

🔒

On LAN mode, browsers will warn the first time because the cert is self-signed, that's expected on a private network. Trust it once and you're set.

What the installer sets up

Everything runs as a few containers via Docker Compose, behind an automatic-HTTPS reverse proxy:

Component	Role
Caddy (edge)	TLS termination and routing, automatic Let's Encrypt certs, or an internal CA in LAN mode.
API (Go)	Accounts & 2FA, servers, channels, messages, roles & permissions, uploads, translation, and the E2EE key-delivery relay.
Gateway (Go)	The WebSocket real-time layer, message fan-out, presence, and voice signaling.
LiveKit	The self-hosted SFU for voice, video, and screen-share.
PostgreSQL	All persistent data. A scoped `garrison_app` role does the day-to-day work (no schema rights).

All secrets are generated for you and live in ops/.env and ops/livekit.yaml: both git-ignored. Never commit real credentials.

Upgrades

Upgrading is just re-running the installer. It keeps your existing ops/.env, pulls the new code, applies any new database migrations idempotently, and restarts the stack in place.

bash

git pull
sudo ./install.sh --domain chat.yourguild.gg --email you@guild.gg # same args as before

Backups

Your whole world is in two places, back both up:

PostgreSQL: your users, servers, channels, and messages. A nightly pg_dump of the garrison database is all you need.
Uploads volume: avatars and file attachments.

⚠️

Encrypted channels can't be recovered from a server backup: by design, the server only stores ciphertext. Each member's encrypted message history is protected by keys held on their devices. Encourage members to use Settings → Encryption → Back up (a password-wrapped key backup) so they can restore on a new device. See Security & Encryption.

Connecting clients

The web app is served by your instance directly, just open your domain. For the desktop and Android apps, point them at your server's URL. Because the API and gateway already accept the desktop/mobile origins, no extra server configuration is needed.

🧭

Curious how the pieces fit together? The Overview has the full architecture diagram.