Skip to main content

Moving Entrosity Hub

Entrosity Hub and Entrosity Axis share one host name: the Hub at /, Axis at /axis, the documentation at /docs (PLATFORM_DOMAIN). Moving them to another name is one scripted step on the host. Agents and connectors are not affected: every earlier name keeps serving Axis's API for the devices enrolled against it, and sends browsers to the new name.

History​

Sign-in moved from Axis to the Hub in September 2026, in three steps:

  1. Hub sign-in. Axis used to sign users in itself at https://manage.entrosity.com (the portal under /manage). The Hub was started next to it at https://portal.entrosity.com, Axis's users, tenants and roles were copied there with platform-server import-rmm, and Axis switched to the Hub's tokens, served at https://portal.entrosity.com/manage. manage.entrosity.com kept the API for enrolled agents and connectors and redirected browsers.
  2. Local sign-in removed. Migration 0013_drop_local_auth removed passwords, sessions, two-factor secrets and invitations from Axis's database (Data model). Going back to local sign-in now means restoring a backup taken before it.
  3. New addresses. Axis moved from /manage to /axis (the Hub's migration 0002_axis_path), and the Hub to hub.entrosity.com with the move step below.

The stages used for the first step (hub, import, switch, redirect, rollback) are gone from the script. import-rmm still exists in platform-server, but it needs an Axis database from before migration 0013.

Production

Until hub.entrosity.com has a DNS record, production serves the Hub on https://portal.entrosity.com with Axis at https://portal.entrosity.com/axis; the move below completes the switch.

Before you start​

  • DNS: an A record for the new name (for example hub.entrosity.com) pointing at the host (93.123.16.234), in the entrosity.com zone at GoDaddy. It may be proxied (Cloudflare) or not; the script only checks that the name resolves on the host. Caddy gets the certificate on the first request (HTTP-01 on port 80), so the record must reach the host.
  • Tell users: everyone signs in again after the move, at the new address (the Hub's session cookie belongs to a host name). Passwords, authenticators and roles are unchanged.
  • A backup is taken by the script; keep a copy of deploy/.env as well.

Move​

Run deploy/scripts/platform-cutover.sh move hub.entrosity.com (and status) on the host, in /opt/entrosity/deploy.

The move to hub.entrosity.com was run, before production was deployed from entrosity-infra, with the manual workflow platform-cutover of entrosity/RMM (.github/workflows/platform-cutover.yml), which ran the script over the deploy workflow's SSH key and never overlapped a deploy. That workflow is disabled now; entrosity-infra keeps a copy in .github/workflows-disabled/:

# historical, in entrosity/RMM
gh workflow run platform-cutover.yml -f stage=status
gh workflow run platform-cutover.yml -f stage=move -f domain=hub.entrosity.com

move:

  1. checks that the name resolves (getent hosts) and stops otherwise;
  2. takes a backup (backup.sh);
  3. sets PLATFORM_DOMAIN in deploy/.env to the new name and adds the previous one to PLATFORM_OLD_DOMAINS (removing the new name from that list, so moving back works the same way);
  4. removes settings that compose now derives or that are no longer used: RMM_PUBLIC_URL, RMM_PORTAL_URL, RMM_CORS_ORIGINS, RMM_AUTH_MODE, RMM_EDGE, COMPOSE_PROFILES. Compose sets RMM_PUBLIC_URL and RMM_PORTAL_URL to https://<PLATFORM_DOMAIN>/axis (Configuration);
  5. restarts the Hub, the backends (same number of replicas) and Caddy;
  6. waits for https://<domain>/api/platform/v1/healthz and https://<domain>/axis/api/v1/healthz (which also proves the certificate).

status prints PLATFORM_DOMAIN, PLATFORM_OLD_DOMAINS, RMM_DOMAIN, RMM_VERSION and the services.

To go back, move to the previous name the same way.

Verify​

curl -fsS https://hub.entrosity.com/api/platform/v1/healthz
curl -fsS https://hub.entrosity.com/axis/api/v1/healthz
curl -so /dev/null -w '%{http_code}\n' https://hub.entrosity.com/api/platform/internal/v1/jwks.json   # 404
curl -so /dev/null -w '%{http_code} %{redirect_url}\n' https://portal.entrosity.com/manage/   # 308 to hub.entrosity.com/axis/
curl -fsS https://portal.entrosity.com/manage/api/v1/healthz   # enrolled agents
curl -fsS https://manage.entrosity.com/api/v1/healthz          # enrolled agents

Then, as a user: sign in at https://hub.entrosity.com, open Entrosity Axis, open a tenant and run a script on a test device. In Grafana, rmm_ws_connections stays where it was (agents keep their connections) and rmm_platform_sync_age_seconds stays below 60.

After the move, point the variables of the workflows that still name the old host at the new one where wanted (DEPLOY_URL, RMM_API_URL, CI workflows); the old hosts keep serving the API, so nothing breaks in between.

What old addresses keep working​

Caddy serves three kinds of sites (TLS, deploy/Caddyfile):

AddressBrowsersAgents, connectors, scripts
https://hub.entrosity.com/ (PLATFORM_DOMAIN)The Hub; Axis at /axis; the docs at /docsNew enrollments use https://hub.entrosity.com/axis (/axis/api/…)
https://hub.entrosity.com/manage/…308 to /axis/…/manage/api/* is still served
https://portal.entrosity.com/… (PLATFORM_OLD_DOMAINS)308 to the same path on the Hub's name (/manage/… to /axis/…)/axis/api/* and /manage/api/* are still served
https://manage.entrosity.com/… (RMM_DOMAIN)308 to https://hub.entrosity.com/axis/…; /docs to the Hub's docs/api/* and /manage/api/* are still served

Agents and connectors keep the server URL they enrolled with (a redirect to another host would drop their credentials), so these API paths stay as long as such devices exist. Reinstalling with an enrollment token moves a device to the current address. Bookmarks and e-mailed links to any old page land on the matching page of the new address.