Independent community infrastructure

A community platform run like a small internal cloud.

The Cantina Network is not one bot or one website. It is a set of deliberately separated services for identity, membership evidence, community workflows, cross-platform chat, delivery and game hosting.

01 / System map

Separated services. Explicit contracts.

A public request enters through the edge, identity is established centrally and every application keeps its own authorisation and data boundary. The diagram is intentionally architectural rather than operational.

Edge

Public DNS & edgeCloudflare

TLS & routingNGINX Proxy Manager

Identity

Federation · MFA · OIDCAuthentik

canonical subjectscoped machine token

Applications

Provider connectionAccounts

Season planningWoW Roster

Automation & bridgeTCN Bot

Independent chatCantina Chat

State & delivery

Per-service boundariesPostgreSQL

Build evidenceGitHub Actions

Controlled promotionTCN Delivery

Runtime

Isolated guestsProxmox

Game orchestrationAMP

Node monitoringSentinel

Security-sensitive topology, addresses, ports, identifiers and exact deployment counts are deliberately not represented.

Selected surfaces

Member-facing tools, without production data.

TCN Accounts dashboard design concept showing member access, Discord and Battle.net connection states. — TCN AccountsDashboard design concept—not a live operational screenshot.

WoW Season Roster project card with The Cantina Network emblem and the line Plan your role. Shape the season. — WoW Season RosterProject identity for the planning and membership-evidence tool.

02 / Communication

Follow the data, not the product names.

A member connects an external account

Discord federation

Authentik

TCN Accounts

Battle.net OAuth

Versioned evidence

Authentik establishes the member identity. Accounts owns the provider connection and encrypted credential, then exposes bounded character evidence—not the provider token—to authorised TCN services.

The roster evaluates membership

Member grant

Accounts evidence

WoW Roster

Independent lookup

Explicit result

The roster combines scoped member consent with Accounts evidence and its own game-data lookup. The result remains MEMBER, NON_MEMBER or UNKNOWN; uncertainty does not become an accidental rejection.

A message crosses chat platforms

Discord / Fluxer gateway

Durable inbox

Consent & policy

Sync worker

Target adapter

Gateway events enter a durable PostgreSQL workflow before relay. Consent, channel policy and versioned handling are evaluated before an outbox worker talks to the target platform.

A release reaches an isolated service

Private source

GitHub Actions

Tests & SBOM

Immutable digest

Plan → rehearsal → promotion

Delivery separates build evidence from promotion. An exact manifest is planned read-only, migrations are rehearsed against an isolated copy and an authorised promotion is verified after apply.

03 / Catalogue

What I engineered—and what I operate.

Authorship and platform operation are kept separate. Existing products can require serious engineering without becoming my original software.

Built / engineered07

Identity-linked member evidence

TCN Accounts

TypeScript · Fastify · React · PostgreSQL · OAuthRestricted live service; wider rollout gated

Planning and evidence-based membership evaluation

WoW Season Roster

React · Fastify · PostgreSQL · Accounts API · Battle.netLive pilot; acceptance work remains

Community automation, reconciliation and cross-chat bridge

TCN Bot

Node.js · TypeScript · Discord.js · PostgreSQL · LiveKitDevelopment and test running; privacy canaries remain

Evidence-driven build and promotion path

TCN Delivery

GitHub Actions · containers · manifests · SBOMDevelopment and CI accepted; production promotion inactive

Versioned identity policy and service registration

Authentik configuration

Blueprints · validation · environment gatesIntegrated; production changes remain separately gated

Human-maintained game templates compiled for AMP

AMP template pipeline

Validation · generated deployment branch · AMP ADSPublished and consumed

Server-controlled interface for bounded AI operations

Codex Wrapper

TypeScript · Fastify · JWT · planned mTLSSource and host preparation; not deployed

Integrated / operated10

Proxmox

Isolated service guests and infrastructure ownership

Live

Authentik

Identity, MFA, OIDC and machine-token authority

Live

NGINX Proxy Manager

TLS termination and reverse-proxy ingress

Live

Cantina Chat / Fluxer

Independent community chat platform

Public and branded; SSO staged

Sentinel

Node-local service monitoring and recovery evidence

Live

AMP

Game-server orchestration outside the Proxmox guest catalogue

Live

Public site

WordPress community presence

Live; cleanup ongoing

Anniversary experience

Event site with payment integration

Live; inventory incomplete

Strapi

Supporting content service

Known service; current use under review

TeamSpeak

Supporting voice service

Operational status not recently audited

04 / Decisions

The architecture is a set of refusals too.

Evidence, never credentials

Accounts keeps provider credentials inside its own boundary. Other tools receive scoped, versioned evidence that answers a business question without inheriting access to the original account.

Central identity, local authorisation

Authentik establishes who someone is; each application still owns its sessions, database rules and feature permissions. Single sign-on does not become shared application state.

Durability before relay

Cross-platform events enter an inbox/outbox workflow before delivery. Restarts and partial API failures become reconcilable state instead of invisible message loss.

Consent before communication

The bridge checks member consent and channel policy before content crosses platforms. Voice is mixed in memory and is not recorded, persisted, transcribed or analysed.

Immutable delivery evidence

A release is an exact manifest and digest, not whatever happens to be on a server. Read-only planning and isolated migration rehearsal precede authorised promotion.

Reject almost-correct migrations

One Accounts candidate was rejected when its migration differed from production by a single newline. Semantic similarity did not override the recorded checksum contract.

Human source, generated artifact

Game templates stay maintainable in a human-friendly hierarchy, then compile into the flat structure AMP can index. Generated deployment state never becomes the authoring source.

Retire the wrong abstraction

An earlier identity-sync service was removed when Accounts became the clearer boundary. Keeping a familiar service was less important than reducing duplicated identity state.

05 / State & direction

Useful today. Intentionally unfinished.

Operating now

Core infrastructure, identity, edge routing and monitoring
Public community surfaces and game hosting
Restricted Accounts service and live roster pilot
Published human-to-AMP template pipeline

Controlled next steps

Complete privacy and delivery canaries for the bridge and bot
Broaden Accounts and roster access after acceptance evidence
Promote the immutable delivery path only after production rehearsal
Complete SSO and remaining service inventory without merging data boundaries

Deliberate boundaries

No provider-token sharing between applications
No recording, persistence, transcription or analysis of bridged voice
No production apply merely because a build succeeded
No claim of authorship over inherited community products