N
Nanami Docs
Browse docs
Community security checklist
Run Community

Community security checklist

The supported hardening checklist for the current Community self-hosted path.

Section
Run Community
Path
/deployment/community-security-checklist

Good for

Community operators who need one secure-first checklist for bootstrap, exposure, backup, and upgrade posture.

What you get

You know how to keep the supported Community path secure and how to distinguish secure-first posture from degraded compatibility fallbacks.

Before you start

A Community checkout or published release bundle · The supported Community env file · Control over your reverse proxy, public DNS, and host firewall

Use this checklist as the supported hardening reference for the current Community self-hosted path.

This page is intentionally product-safe:

  • it explains what the operator should do,
  • it marks degraded compatibility postures clearly,
  • it does not teach internal-only or unsafe defaults as normal practice.

1) Bootstrap securely

  • Keep INTERNAL_AUTH_MODE=mtls.
  • Keep COMMUNITY_IMAGE_SOURCE=build unless you intentionally supply your own public registry images.
  • Keep UNSUPPORTED_COMMUNITY_ALLOW_SERVER_KEY_ISSUANCE=false.
  • Keep CREATE_TEST_USER=false.
  • Keep BOOTSTRAP_OPTIONAL=false.
  • Replace every example secret before first boot.

2) Publish only the supported public surfaces

  • Keep browser and API access behind your reverse proxy.
  • Keep management and database ports loopback-bound or private.
  • Treat gateway transport as the explicit direct-exposure exception.
  • If you are still using the no-domain fallback, treat it as degraded bring-up posture and move to a domain-backed setup.

3) Keep operator trust boundaries explicit

  • Use real TLS for public browser and API traffic.
  • Restrict management ingress with network controls.
  • Avoid teaching raw internal runtime addresses to end users.
  • Do not treat manual compatibility paths as the normal product story.

4) Protect secrets and enrollment state

  • Rotate enrollment credentials when they are no longer needed.
  • Keep the environment file out of shared screenshots and public notes.
  • Keep backup artifacts encrypted or stored in a protected location.
  • Do not reuse demo/example values in a real deployment.

5) Verify after every meaningful change

Run:

bash
scripts/community_single_host.sh validate-env
scripts/community_single_host.sh preflight
scripts/community_single_host_smoke.sh

Use:

  • scripts/community_single_host_backup.sh before risky changes,
  • scripts/community_single_host_restore.sh for recovery drills,
  • scripts/community_single_host_upgrade.sh for supported upgrade flow,
  • scripts/community_single_host_verify.sh --restart-service gateway-daemon when you need targeted runtime verification.

6) Operate with recovery in mind

  • Back up Postgres regularly.
  • Rehearse restore before you need it.
  • Keep upgrade and smoke evidence together.
  • Roll out one network or gateway path at a time when possible.

7) Know what this checklist does not mean

This checklist does not mean:

  • that anonymous public Community distribution is already open,
  • that the Community edition is defined only by one host,
  • that degraded compatibility fallbacks are the recommended posture.

For the current supported deployment contract, use Community self-hosted deployment.

Next steps

Pick the most useful next step instead of the next random article.

Community self-hosted deploymentQuickstartCommon issues