Before you install

Settle three things first

These three decide everything that follows. Settling them first saves a reinstallation.

What the installation host must provide

• Operating system and architecture: Linux amd64 or arm64. openEuler, Kylin and UOS have baseline adaptation; confirm your exact combination by testing the target environment.
• Resources: 4 vCPU, 8 GiB RAM and 50 GiB free disk is a reasonable start. Real capacity depends on how long you retain data and how much work runs, so treat it as a starting point rather than a specification.
• Runtime: Docker Engine 24 or later and Docker Compose v2. Installation requires root or equivalent privileges.
• The offline package needs extra room: 551 MB to download and about 1.4 GB once extracted, so leave more than 2 GB free until the installation finishes.

docker --version
docker compose version
df -h /
free -h
uname -m

docker compose version must report a v2 version; the old standalone docker-compose command does not count. uname -m reporting x86_64 means amd64 and aarch64 means arm64.

If Docker does not work, fix Docker. Do not switch off host security protections to get the installation moving.

Which ports to open

A single-node deployment publishes only three ports; the remaining services talk to each other inside the container network and are not exposed on the host.

• Do not put the Agent channel behind a layer-7 proxy. Terminating TLS there breaks the mTLS client-certificate identity chain and enrollment stops working.
• The database and cache are not published to the host and are reachable only inside the Compose network, so they need no firewall rules.
• If another program holds a port, the installer stops before touching any container and names the port, rather than failing halfway through.

Where the data lives and what to back up

The data sits in six Docker volumes plus a local state directory, which defaults to ~/.config/chronoops/quickstart under the installing account — root’s home directory when you install with sudo.

• Plan capacity and retention for each volume separately: the database, job output, file distribution, session recordings and release artifacts all grow at very different rates.
• The state directory holds the platform authentication and credential-encryption material. What the database stores is already encrypted, so losing the encryption key means the database alone cannot recover your credentials.
• A backup therefore has to cover the database, the relevant volumes and the state directory together. Backup, recovery and upgrades covers how.

When a single node is not enough

Single-node installation suits trials, evaluations and small production starts. When any of the following applies, move to the advanced Helm path rather than stretching a single-node environment into production.

• You already run Kubernetes and want the platform operated alongside the cluster.
• You need an external database, or your database is managed centrally by a DBA team.
• You need multiple replicas against a stated availability target. Note that configuring replicas is not the same as having verified high availability, which has to be rehearsed separately.
• You have strict network segmentation requirements, or sensitive configuration must go through an enterprise secret manager.

CHRONOOPS_OFFLINE_DRY_RUN=true \
CHRONOOPS_OFFLINE_REQUIRE_SIGNATURE_VERIFY=true \
CHRONOOPS_OFFLINE_MODE=helm \
CHRONOOPS_OFFLINE_VALUES=/secure/values.prod.yaml \
tools/install.sh

This command belongs to the complete signed delivery package rather than to either website package; contact weiwendi@aiops.red when you need it. Review images, secret references, storage and networking after the dry run; the real run is performed by an administrator during an approved window, following the procedure shipped with that package.

Reference existing secrets for sensitive data; never put database passwords, JWT secrets or private keys into a values file, a ticket or a public repository. Run database migrations with permissions separate from the application runtime.

Checks before real use

A finished installation is a beginning. The environment is ready for real work only once each of these four has been verified on its own.

1. Sign-in and permissions: sign in as both an administrator and an ordinary account, and confirm restricted resources are neither visible nor operable to the ordinary one.
2. Connection and execution: check target hosts, Agent heartbeats, a read-only job and the resulting records, and confirm nothing connected to the wrong resource.
3. Maintenance: actually rehearse a backup, a restore and a failed upgrade in a test environment, and record how long recovery really took.
4. External integrations: verify each identity source, cloud account and notification channel separately. One working channel says nothing about the others.