Getting started

Tip

For a single node, installing from a package is the shortest route: .deb/.rpm set up the service account, the systemd unit and the configuration including the operator password.

Startup

DNSE_ENCRYPTION_KEY=<hex-key> \
DNSE_ADMIN_PASSWORD=<bootstrap> \
DNSE_OPERATOR_PASSWORD=<operator-password> \
./dnseditor-cloud

This exposes two separate worlds:

• Application — http://127.0.0.1:8422, sign-in by email
• Operator panel — http://127.0.0.1:8422/operator, its own account, its own token

Configuration

All variables from CE and EE apply. In addition:

Variable	Default	Meaning
DNSE_OPERATOR_USER	operator	Username of the bootstrap operator
DNSE_OPERATOR_PASSWORD	—	Password on the very first start
DNSE_OPERATOR_TOKEN	—	Static token for machine access (X-Operator-Token)
DNSE_REGIONS	built-in catalogue	Regions as code:Label,code:Label,…
DNSE_REGION	first region	Home region of this instance
DNSE_BACKUP_DIR	—	Directory for nightly tenant exports
DNSE_DEMO	off	on creates the large demo dataset

DNSE_OPERATOR_PASSWORD behaves like the admin password in CE: it only takes effect on the first start; a password changed later remains in place.

The operator token is meant for machines (checkout frontend, CI). It bypasses sign-in and counts as an administrator — treat it accordingly, or omit it if only humans should reach the panel.

Regions

The region catalogue controls which home regions can be chosen for organisations and what the System page in the operator panel evaluates.

DNSE_REGIONS="eu-central:Central Europe,eu-southwest:Southwestern Europe,na:Americas"
DNSE_REGION=eu-central

Without DNSE_REGIONS the built-in catalogue applies: Central Europe, Southwestern Europe, Americas, South America, Asia.

Note

Regions are currently a logical assignment: every organisation has a home region, and the panel evaluates the distribution. Physical geo-partitioning of the data is a later stage — at present all data lives in the same cluster.

Platform settings

Core settings (SMTP — global or per region) and portal messages live at the platform level in the Cloud: the operator maintains them once in the operator panel, and all tenants read them. These pages are therefore hidden in the tenants’ admin panels.

Development

make help              # overview of all targets
make run               # port 8422
make demo              # port 8479, ten demo organisations
make test              # Go tests (race) + gofmt + vet
make test-cluster-up   # four-node test cluster, see Cluster operation

Self-healing in continuous operation

Every cloud node ships the core’s crash safety: panics in handlers and jobs stay local, GET /healthz (liveness) and GET /readyz (readiness, a real DB ping) serve load balancers and orchestration, and the watchdog terminates a persistently unhealthy node cleanly (exit code 2) — the supervisor restarts it while the remaining nodes carry the load. The four-node test cluster uses exactly that: restart: unless-stopped per node and /readyz as the healthcheck. Configuration (DNSE_WATCHDOG*) lives in the CE docs under Getting started → Operations & Self-Healing.