---
title: "Hosting member-console"
audience: [admin]
summary: "Build the container image and generate the secrets needed to run a member-console instance."
---

# Hosting member-console

Operational steps for running your own member-console instance. For how the
console fits alongside a public site and identity provider, see
[deployment-architecture.md](deployment-architecture.md); for identity-provider
configuration, see [identity-provider-setup.md](identity-provider-setup.md).

## Building the image

The container image is built with Docker Buildx for both ARM64 and AMD64. Tag it
for your own registry:

```bash
docker buildx build \
  --platform linux/arm64,linux/amd64 \
  -t your-registry.example/your-org/member-console:latest \
  -t your-registry.example/your-org/member-console:$(date +%Y-%m-%d) \
  --push \
  .
```

> The canonical image is published to `git.coopcloud.tech/wiki-cafe/member-console`.
> Substitute your own registry when self-hosting.

## Generating secrets

Generate the CSRF secret before deploying, and store it securely:

```bash
openssl rand -hex 16      # csrf-secret (32-character hex string)
```

> Sessions are stored server-side in Valkey/Redis and need no signing secret;
> point `valkey-addr` at your instance (default `localhost:6379`).

## Rotating the CSRF secret

`csrf-secret` is the HMAC key that signs the anti-CSRF tokens embedded in
every page and form. Rotating it does **not** log anyone out — sessions live
server-side in Valkey and are unaffected — but it invalidates the CSRF token
in every page that is already open in a browser tab. Any form submitted from
such a tab fails its CSRF check until the page is reloaded.

To rotate:

1. Generate a new value (`openssl rand -hex 16`).
2. Update the deployment's configuration and restart the service. Prefer a
   low-traffic window: the restart plus token invalidation means in-flight
   form fills are lost and open tabs need a reload.
3. There is no step 3; old tokens are invalid the moment the new key loads.

Rotate after any suspected leak of the configured value and whenever someone
with access to production configuration departs. Routine time-based rotation
is optional; the secret authenticates only same-session form posts.

> Zero-downtime rotation (accepting tokens signed by both the old and new
> key during a grace window) is not yet supported; it is tracked as an open
> issue in `status/issues.md` ("Session/CSRF secret generation and rotation
> strategy").