Skip to content

Deployment & Topology Settings

What this screen is for

Deployment & Topology is one of the eight purpose groups of Platform Settings, and it is the shape of your installation rather than a set of knobs: which components exist and how they are addressed, what this environment is called and which release it runs, how the console reaches the platform, and how the edge is addressed. Opening the group card lists four subgroups as cards — Topology & Ports, Deployment Identity, Admin Console and Networking & Edge, in that order. None of the four administers records of its own, so none has a screen of its own and all four are covered here.

Only the Admin Console values can be written from this screen. Everything else in the group is a read-only observation, apart from one secret; a write against any of them is refused as a method that is not allowed.

That is the design and not a gap. Topology, ports, deployment identity and edge routing are bound when the environment is provisioned, by the deployment templates and the tooling that creates it, and they are surfaced here so you can read what a running environment actually is without opening a shell on the host. There is no supported path to re-shape a deployment from a settings screen.

What must exist first

Platform Settings is a platform screen, reached in the platform context and served only to the platform tenant. Before you work here:

  • The permission to read platform configuration. It is what shows the Platform Settings sidebar entry at all, and on this group it is what almost everything needs, because almost everything here is a read.
  • The permission to write platform configuration, for the editable Admin Console values and for nothing else in this group. No value here is classified dangerous, so the third, dangerous permission is never asked for on any of these four screens.
  • Nothing further. Unlike the connector groups, no card here reads a second surface, so no subgroup in this group carries permissions of its own.

Decisions you make here

These four cards carry a plain row count rather than a status chip: they are not connectors, and there is no external system whose state could be reported. The count follows the Posture filter above the cards, so it is a filtered count whenever the filter is not All — and this group is where that matters most. Under Editable only Admin Console reads anything other than 0, and under Secrets only Networking & Edge does.

Topology & Ports

All read-only: the ports the environment's components answer on, the base port they are derived from, and the identifiers the environment's infrastructure was created with. They exist so you can confirm the shape of a running environment from the console.

Several entries in this group declare their default as (auto), which states plainly that the deployment computes the value rather than inheriting a product default. To change anything here, change the environment: the base port and the deployment templates decide this section, and the environment is re-provisioned, never edited from this screen.

Deployment Identity

All read-only: the logical name of this environment, the identifier saying whether it is production, staging, demo or dev, the public domain name of the deployment, and the release it runs.

That identifier is also what raises the Non-production environment advisory above the Platform Settings cards, so an environment that declares the wrong one is told the wrong thing on every settings screen — and it is changed at provisioning, not here.

Read the applied value, never the declared default. A deployment's release and domain are properties of that environment, while the catalogue's declared value describes the product's reference shape, so quoting the declared column as a customer's release or URL is how a wrong answer reaches a report. The release is one of the (auto) entries for exactly this reason.

Admin Console

This group's editable entries.

Help source decides where the console reads its in-product screen help from, and it takes exactly two values: the published ANKATech documentation site, or off. Choose off on an install with no outbound internet access — the console then issues no request to the documentation site and renders no help affordance and no help link on any screen, while every other surface is unchanged. Screen help is served online only, so there is no in-environment copy to point at instead.

Default display time zone is the time zone the console shows dates and times in for every person who has not chosen their own from the user menu. It takes a region time zone or UTC, never a fixed offset, because a fixed offset does not follow daylight saving time. Only the display changes: the platform stores every instant in UTC.

A change to either reaches every console on the next page load, with no restart and no redeploy. Both are platform-wide decisions with no per-tenant override: a tenant can neither turn help on for itself in an install that has no internet, nor off for itself in one that has.

The remaining value in this section is the address the console uses for real-time updates. It is read-only and owned by the deployment.

Networking & Edge

None of them editable here: the internal address the administration service is reached on, the name of this environment's private network, and the password protecting the platform TLS keystore the services present.

The keystore password is a secret and is operator-managed. It is never shown, the entry tells you only whether one is stored, and a write is refused rather than accepted — it is changed where the deployment's secrets are managed, not here. The network name is another (auto) entry, computed per environment.

How it relates to other screens

The root of this surface explains what every screen below it shares: the posture filter, the search palette, how secrets behave, and when a saved value takes effect. What this group describes, two other screens watch — whether the components it lists are up, and what the installation is connected to.

Where to read more