Getting started

EVE Together is a local-first desktop companion for EVE Online. It runs fully on your own machine — managing fits, fleets, doctrine compositions and live combat metrics — with an optional self-hosted server when you want to fly as a group.

There are two ways to run it:

• Solo / local-only — just the desktop client. Every character authenticates locally, tokens stay on your disk, nothing is shared.
• Together — one person in your group hosts a server (Docker). Characters you mark as synced couple to it; everything else stays local.

Installation

Desktop client

Download the build for your platform from the Releases page, unpack it, and run it. The builds are self-contained — no separate .NET install needed. On first launch the app builds a local SDE store from CCP's published data and creates an empty local database.

1. Download and unpack the build for your OS
2. Run EveTogether
3. Add a character -> sign in with EVE SSO
4. Grant the ESI scopes the features you want require

Self-hosted server (optional)

The server ships as a Docker image — ghcr.io/evetogether/eve-together-server, tagged :latest and per release version. It comes with no EVE credentials baked in: every deployment registers its own EVE application at developers.eveonline.com and supplies the Client ID and Secret, or the server refuses to start outside Development.

docker run -d --name eve-together-server \
  -p 7443:7443 -v eve-together-data:/data \
  -e Esi__ClientId="your-client-id" \
  -e Esi__ClientSecret="your-secret-key" \
  -e Esi__CallbackUri="https://your-server.example.com/auth/eve/callback" \
  -e Server__AdminSeedPassword="choose-a-strong-password" \
  ghcr.io/evetogether/eve-together-server:latest

Then, in the client, couple a character to it: open that character's settings (the gear on its card) → couple a server → enter the server address (and an optional label) → sign in as the character you want synced. The client pins the server's TLS fingerprint on that first connection (trust-on-first-use); the server prints it at startup.

Everything persists in the /data volume — the database, the TLS certificate, the app log, the ESI cache and the auth store. Back it up. The full guide (database providers, the pairing allowed-list, reverse proxies, upgrades) lives in docs/server-installation.md.

Core concepts

Architecture

EVE Together is three pieces over one shared foundation:

• EveUtils.Client — Avalonia desktop app (C#/MVVM, .NET 10), local SQLite, its own ESI connector with a file cache, a read-only SDE store and a gRPC client. Runs autonomously.
• EveUtils.Server — optional, self-hosted via Docker. Minimal API + Blazor admin panel + gRPC + SignalR on a single Kestrel TLS endpoint (HTTP/1.1 and HTTP/2 side by side via ALPN), against SQLite, MySQL, SQL Server or PostgreSQL.
• EveUtils.Shared — entities, the EF contexts, CQRS infrastructure, identity/messaging/logging, the gRPC protos, and all vertical-slice modules.

The technical foundation: CQRS with its own dispatcher (no MediatR), modules over DDD, gRPC (call + bidirectional streaming), a two-level event bus (in-process plus a gRPC stream), IDbContextFactory with a short-lived context per operation, and a code-derived permission gate. Crucially, the identity and permission seams shipped from day one — so adding "together" is additive, not a rewrite.

Each feature is a self-contained folder under EveUtils.Shared/Modules/ with its own entities, DTOs, repositories, queries, commands and permission codes. Entities never leave their module; the DTOs are the contract. The modules today:

Auth & security

Authentication is per character, with two flows you toggle individually:

• Local — the client runs the EVE SSO PKCE flow itself over a loopback redirect; the token lives on your machine.
• Synced — the character is paired to your server (pairing id + secret + state); the server holds the token. The token lives where the character belongs.

• Refresh tokens are encrypted at rest.
• Scope-gating: a feature only works if you've granted the matching ESI scope — otherwise it's disabled with a clear message, never failing silently.
• The client is untrusted. The server derives identity only from the EVE-signed JWT it fetches itself, and the permission gate is enforced server-side on the event bus — a modified open-source client cannot talk its way past it. The client-side check is deliberately cosmetic.
• TLS: the server generates a self-signed certificate on first start and the client pins its fingerprint at pairing (trust-on-first-use). The EVE SSO callback is browser-based, so a public deployment runs behind a reverse proxy (Caddy, nginx, Traefik…) that terminates TLS with a real certificate.
• Who may pair is an allowed-list, enforced by default — seed the characters up front or add them in the control panel, or switch the server to public mode if anyone who completes the EVE auth flow may join.

ESI & data

EVE Together aims to be a polite ESI citizen:

• Honour Expires caching headers; sensible fallbacks; cache immutable data effectively forever, with jitter.
• Conservative retries, rate-limits respected (per-character and per-IP).
• A pinned X-Compatibility-Date and a descriptive User-Agent with contact info.

Data minimisation is a hard rule — the app persists as little as possible and prefers an ephemeral cache over a data warehouse.

The SDE store

EVE's Static Data Export (the game's reference data) is built locally into a dedicated, read-only, memory-mapped SQLite store from the official JSONL. It's separate from your live database, rebuilt with an atomic swap when CCP publishes updates.

latest.jsonl  →  build  →  sde.sqlite (read-only)  →  atomic swap

The local API

The client can expose an opt-in HTTP server on loopback, so an overlay, a stream widget or your own dashboard can read what the app knows — without any of it leaving the machine. Turn it on (and pick the port) in Settings; it is off until you do.

The app also serves its own reference at /docs and a ready-made overlay page at /widget, so you can point OBS at a browser source and be done.

FAQ

Do you store my data on a server?

No. There is no EVE Together cloud. The client is fully local; any server is one you (or your group) host.

Is it affiliated with CCP?

No. It's a third-party tool that uses CCP's official ESI API, and is not endorsed by or affiliated with CCP hf.

Does it copy EVE Workbench or zKillboard?

No code is copied. EVE Workbench is used only as a visual/behavioural reference; the implementation is entirely our own.

What does it cost?

Nothing. It's free and open source under the GNU AGPL v3.0. The network clause means anyone who offers a modified server over a network has to share their modified source.

Is it finished?

No — it's pre-1.0. v0.2.0-beta is usable day to day, but expect the odd rough edge and breaking changes between releases. The roadmap shows what has shipped and what hasn't.

Contributing

EVE Together is open source as a trust requirement — so anyone can verify exactly what is stored and what is sent over the wire. The source lives at github.com/EveTogether/EveTogether.

• Questions or ideas? Join the Discord.
• Bug or feature request? Open an issue — the templates show what's needed to act on it. A good bug report needs no code and is genuinely useful.
• Pull request? Read CONTRIBUTING.md and AGENTS.md first — PRs are judged against the conventions in AGENTS.md, and out-of-scope ones are closed without a line-by-line review. It's a small team with a high bar.
• Security issue? Don't open a public issue — follow SECURITY.md to report it privately.

Material related to EVE-Online is used with limited permission of CCP Games hf by using official Toolkit. No official affiliation or endorsement by CCP Games hf is stated or implied. © 2026 RaymondKrah & Jithran — licensed under the GNU AGPLv3.