Self-host Aperture

Run Aperture on your own hardware, with your corp's data under your corp's control. The deployment is one app container and one Postgres database, brought up by a single Docker Compose command.

What you need

• A server that runs Docker with Compose.
• An EVE SSO application (EVE's single sign-on, registered through the developer portal). Aperture needs eight specific scopes, listed in the README.
• The environment variables the README documents, including the SSO application's credentials.

Bringing it up

docker compose up -d

That one command builds the image, runs database migrations as a one-shot service, and starts the app on port 3003 against Postgres 18. Migrations run on every up and are idempotent. Postgres is never published to the host in the production posture.

First run continues at /setup, the operator console. It is gated by a password rather than EVE SSO, so it stays reachable even if an auth deploy breaks. From there you run the first ingest of the SDE (EVE's static data export) and can see what state the instance is in.

It keeps itself current with the game

A daily job checks Fenris Creations' published SDE build and ingests a newer one on its own. The ingest runs in an isolated child process behind acceptance gates that reject a bad build whole rather than half-writing it, and a stale or failing refresh raises a banner naming the consequence. New ships, systems and gates appear after a patch with nothing for an operator to run.

Who can log in

Login is restricted by default: a character signs in only if it, or its corp or alliance, is on an allowlist. Beyond that there is no permission hierarchy to maintain by hand, because authority derives from EVE itself. Any corp Director resolves to management rights over their own corp's maps, and a director can delegate individual director-gated map features to a specific corporation title.

Membership changes are enforced automatically. A pilot who leaves the owning corp loses access and is signed out, typically within the hour; a joiner is picked up on the same cycle and auto-tracked on already-open maps. Every mutation lands in a browsable audit log, and webhooks can push map activity to Slack or Discord.

Running it

• One Node process runs the web app, the WebSocket server and the background worker.
• No Redis. Realtime fanout is Postgres LISTEN/NOTIFY, the job queue is Postgres-backed, and caches are in-process. One database, one app container.
• Prometheus-style metrics across ESI (EVE's API), routing, HTTP, background jobs and realtime fanout, with an admin metrics page, an in-process alerting loop and browser-side error capture.
• A token-authenticated, read-only, corp-scoped integrations API for map activity and presence, off by default behind a flag.

This page covers the shape of the process. The README is the authority on deployment and stays current with the code; follow it when you deploy. And if you would rather build than deploy, Aperture takes contributions and credits them by character name in every release. Start with the repo and the Discord.