OwnCord

A self-hosted chat app I build for me and my friends — text channels, voice and video, and a server you actually own.

Beta, and a hobby project. This is something I build for fun and run for a small group of friends. It isn't a product, it comes with no support commitment, and it isn't production-ready. Expect rough edges, rapid changes, and the occasional breaking change.

Don't use it for anything sensitive.

It's a Go server plus a Tauri desktop client: real-time messaging, voice/video via LiveKit, file sharing, and a web admin panel. Run the server on a spare box or a VPS, hand your friends an invite code, and that's the whole thing.

How it's built

Most of the implementation is generated with AI tooling, with quality held up by automated checks — CI, tests, linting — and by me and my friends actually using it. That keeps iteration fast, and it also means behaviour can change quickly between releases.

What works right now

Area	Status
Core chat flow	Working in beta
Voice/video	Working in beta
Admin panel	Working in beta
Security hardening	Ongoing review passes; findings and their statuses are tracked in the dated audits in docs/ (see the Docs Index below)

Platform Support (Current Releases)

Component	Windows x64	Windows ARM64	Linux x64	Linux ARM64
Server binary	Yes	Yes	Yes	Yes
Desktop client	Yes (NSIS installer)	Yes (NSIS installer)	Yes (AppImage, .deb)	Yes (AppImage, .deb)
Docker server	N/A	N/A	Yes (multi-arch image)	Yes (multi-arch image)

Every server asset and the Docker image ship for both amd64 and arm64 (ghcr.io/j3vb/owncord-server is one multi-architecture tag).

Start Here

• New user quick path: docs/quick-start.md
• Linux Docker deployment: docs/deployment.md
• Remote access without router config: docs/tailscale.md
• Manual router/network setup: docs/port-forwarding.md

Quick Start

Option A: Prebuilt binaries

1. Download assets from Releases (binaries, checksums, signatures, SBOMs, a signed provenance attestation and a full source snapshot per release).
2. Run the server binary:
   • Windows: chatserver.exe (x64) or chatserver-windows-arm64.exe (ARM64)
   • Linux: ./chatserver, from the amd64 or arm64 archive
3. Open https://localhost:8443/admin and complete the setup wizard, entering the setup token from the server's start-up output — it creates your Owner account and configures the server for you (settings are saved to config.yaml automatically).
4. Create invite codes in the admin panel's Invites page (or the OwnCord desktop client's "Invite people" action) and share them with friends.

Option B: Docker (Linux server)

The compose file and the .example files it needs are not release assets — take them from the source snapshot attached to a release (or the repository's Server/ directory).

cd Server
cp .env.example .env
cp livekit.yaml.example livekit.yaml
cp config.yaml.example config.yaml
# Edit .env and livekit.yaml before starting (matching LiveKit key/secret). The compose file wires voice.livekit_url to the LiveKit service
# and turns auto-download off, so config.yaml needs no voice edit.
docker compose up -d

See the full setup guide in docs/deployment.md.

The client uses TOFU (Trust On First Use) for self-signed certificates: it prompts once, then pins the certificate for future connections.

What OwnCord Already Has

• Real-time channels and direct messages over WebSocket, with durable history and per-channel retention
• Voice/video channels via LiveKit — the LiveKit server binary is downloaded and managed for you, with end-to-end-encrypted media and key verification
• Registration modes (closed / invite / approval / open), invite codes, and role-based permissions
• Moderation: reports, appeals, warnings and timeouts, the Moderation Center, Message Requests and NSFW handling
• Web admin panel with logs, backups, retention controls, an audit log and update tooling
• File uploads, inline media rendering and an external-content consent gate
• TOTP 2FA with emergency recovery codes, a rotating local recovery kit for account recovery, and API rate limiting
• Multi-device sessions; every credential is stored in the OS keyring
• Desktop client auto-update with signature verification
• WASM plugin system (slash commands; sandboxed, default-disabled — enable via plugins.enabled and build with -tags wazero)
• GIF picker — off by default; each server supplies its own Klipy key via gif.api_key (setup)

See deeper feature and architecture docs in docs/architecture/ and docs/protocol.md.

Architecture

Two main components:

• Go server (REST API, WebSocket hub, SQLite, admin panel)
• Tauri v2 desktop client (Rust backend + TypeScript frontend)

+---------------------+         +---------------------+
|   OwnCord Client    |         |   OwnCord Server    |
|   (Tauri v2)        |         |       (Go)          |
|                     |         |                     |
|  +---------------+  |  WSS    |  +---------------+  |
|  |  Chat UI      |--+------->|  |  WebSocket Hub|  |
|  +---------------+  |         |  +---------------+  |
|  +---------------+  |  HTTPS  |  +---------------+  |
|  |  REST Client  |--+------->|  |  REST API     |  |
|  +---------------+  |         |  +---------------+  |
|  +---------------+  | LiveKit |  +---------------+  |
|  |  Voice/Video  |--+------->|  |  LiveKit SFU  |  |
|  +---------------+  |         |  +---------------+  |
+---------------------+         |  +---------------+  |
                                |  |  SQLite DB    |  |
                                |  +---------------+  |
                                +---------------------+

Build and Test

Prerequisites

• Go 1.27+
• Node.js 26.x and npm 11.x (see Client/.nvmrc — a different major fails npm ci)
• Rust stable (client builds)
• Linux client builds additionally need clang >= 21, the prebuilt libwebrtc, and the GStreamer -dev headers; see docs/contributing.md (Linux native voice and camera build prerequisites).

Build from source

# Server (Windows)
cd Server
go build -o chatserver.exe -ldflags "-s -w -X main.version=dev" .

# Server (Linux)
cd Server
CGO_ENABLED=0 go build -o chatserver -ldflags "-s -w -X main.version=dev" .

# Client
cd Client
npm install
npm run tauri build

Core verification commands

The local mirror of CI's static, unit and drift gates, from the repository root — it does not run the Playwright jobs, govulncheck, npm audit, the coverage-floor scripts, typecheck:e2e or the tag-gated Go tests; see AGENTS.md for the exact split:

npm run check                  # server + client + Rust
npm run check:server           # or one stack at a time
node scripts/run.mjs --list    # exactly what each task runs, and where

Or run the stacks directly — the facade is a convenience, not the only path, and server work needs no Node at all:

# Server
cd Server
go test ./...

# Client
cd Client
npm run typecheck
npm run lint
npm test

For the full command set, use docs/contributing.md.

Configuration

On first run, the server generates config.yaml and a local data/ directory:

data/
├── chatserver.db
├── cert.pem        # self-signed TLS certificate (key.pem beside it)
├── uploads/
└── backups/

Key options include TLS mode, upload limits, LiveKit settings, and admin CIDR restrictions. See docs/server-configuration.md.

Security and Vulnerability Reporting

• For vulnerabilities, use GitHub Security Advisories (private disclosure flow).
• Do not open public issues for security bugs.
• Read full policy and hardening notes in docs/security.md.

Update Signing Notes (Maintainers)

Client and server update signing keys are intentionally separate.

Required Actions secrets for release signing:

• TAURI_SIGNING_PRIVATE_KEY
• TAURI_SIGNING_PRIVATE_KEY_PASSWORD
• SERVER_UPDATE_SIGNING_PRIVATE_KEY
• SERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD

When rotating the server updater key, update Server/updater/server_update_public_key.txt and use staged rollover for live fleets.

Docs Index

docs/README.md is the complete index — every document in docs/, grouped by whether it is guidance, a reference contract, a dated audit, or a plan. The most-used entries:

• docs/quick-start.md — get a server running
• docs/deployment.md — production deployment
• docs/contributing.md — setup, branch model, how to run the checks CI runs
• docs/security.md — reporting a vulnerability
• docs/architecture/ — system blueprints (diagrams + flows)
• docs/architecture/ux/ — client UX specification (target-state flows, per-view states, event→reaction maps)
• docs/api.md, docs/protocol.md, docs/schema.md, docs/server-configuration.md — reference contracts
• docs/plans/README.md — plan index; records each plan's state and is the authority over a plan's own header

Condensed context files for AI coding agents and new contributors, at the repository root (each lists its sources; on conflict the code wins, then those sources): AGENTS.md, PRD.md, ARCHITECTURE.md, DESIGN_SYSTEM.md, CODE_STYLE.md, DATABASE.md, API.md, SECURITY.md.

Audits are dated snapshots and are not maintained after the fact — read them as history. docs/README.md lists all nine, newest first.

Contributing

1. Create a branch from dev (the active development branch).
2. Keep changes focused and tested.
3. Open a PR targeting dev — dev is merged to main for releases.

See docs/contributing.md for the full process.

Getting Help and Reporting Problems

Nothing here is a support promise — see the note at the top — but there is a right place for each kind of message:

Kind	Where
A reproducible bug	Issues
A question about setup or usage	Discussions → Q&A
An idea or feature suggestion	Discussions → Ideas
A security vulnerability	Private advisory — never an issue

License

AGPL-3.0