Browse and search documentation

ChronoOps Product Documentation

Install the platform, connect your first host, run inspections and investigate problems. Find instructions, prerequisites and troubleshooting guidance by task.

For: Operations engineers, platform administrators and evaluation teamsReviewed:
On this page

What is ChronoOps

ChronoOps is an enterprise operations management platform. It brings asset records, remote access, jobs, Kubernetes inspections, application releases and troubleshooting together so you can move from a resource to its operations and history.

Connect existing monitoring, logging, identity and notification systems without replacing them all. AI assists analysis and proposes responses; execution still depends on user authorization, access permissions and team policy.

System architecture

The diagram shows how the console, backend, data stores and managed environments connect. ChronoOps can be privately deployed. Cloud platforms, monitoring, identity and model endpoints are optional integrations, not prerequisites for an initial installation.

ChronoOps system architectureThe Web console uses APIs and WebSocket to reach the Go backend. Its access, asset and job modules share a process with Agent Gateway and connect to PostgreSQL and file storage. Host Agents initiate connections to the embedded gateway. Bastion access uses a separate Access Gateway, with guacd for remote desktops. External systems connect through configured APIs or adapters. An optional event path reads the same PostgreSQL Outbox through a publisher, NATS JetStream and consumers. Detailed text follows the figure.Web consoleVue 3 · TypeScript · Web entry pointHTTP API · WebSocketChronoOps backend · GoShared APIs and access checksAssets · Jobs · Inspections · ReleasesRemote access · Costs · AI assistanceTenant/project permissions · MFA · AuditAgent GatewayInside the backendModules share a backendNot separate microservicesPostgreSQLBusiness and audit datapgvector for retrievalSQLFile storageOutput · RecordingsArtifacts · VolumesBundled RedisNot the business databasegRPC · mTLSAgent initiates connectionHost AgentsRegistration · HeartbeatsAuthorized jobs and resultsHTTPS · mTLSAuthorized routes/sessionsAccess GatewaySeparate access serviceguacd for remote desktopsAuthorized targetsSSH · SFTP · RDP/VNCAPI / adapterExternal integrationsKubernetes · CloudDatabases · IdentityMetrics · Logs · AlertsModel endpointsConfigured individuallyEvent processing when configuredPostgreSQLOutbox tablePublisherEvent publisherNATS JetStreamEvent messagingConsumersEvent consumersMain configured connectionsOptional integration or runtime
Main logical components and connections, not a fixed server count. Scroll horizontally on narrow screens; the table below explains the diagram.
ComponentResponsibilities and connections
Web consoleThe Vue 3 and TypeScript interface reaches backend APIs through the Web entry point and uses WebSocket for interactive sessions. Protect the production entry point with HTTPS. The browser does not connect directly to the platform database.
ChronoOps backendThe Go backend contains assets, jobs, inspections, releases, remote access, costs and AI modules, together with identity, tenant/project permissions and audit. These groups are not independent microservices. Agent Gateway also runs inside the backend.
Host Agents and Agent GatewayHost Agents initiate gateway connections for registration, heartbeats, observations, authorized tasks and returned results. Production execution channels use gRPC with mTLS. An online Agent does not by itself authorize job execution.
Bastion Access GatewayA separate access service uses backend-authorized routes to reach targets, including SSH and SFTP sessions, with guacd for remote desktops. It is distinct from Agent Gateway. Assets, managed accounts, grants and applicable MFA or approval are still required.
PostgreSQL and persistent filesPostgreSQL stores business and audit records; knowledge retrieval uses pgvector. Job output, session recordings and release artifacts use configured persistent storage, so a database-only backup is insufficient. All-in-One also bundles Redis. It is not the business database, and its presence does not mean every session or task is stored there.
External systems and adaptersKubernetes, cloud platforms, databases, telemetry, identity, notifications and model services connect through their configured APIs or adapters. Set each integration’s address, credentials and permissions separately. Connectivity or read access does not imply permission to make changes.
Optional event processingWhen event processing is configured, a publisher reads the same PostgreSQL Outbox, sends events to NATS JetStream and consumers process them. This is not the synchronous path for every Web request or Agent job, nor an initial All-in-One requirement. NATS session relay for multi-replica jobs is a separate, explicitly configured use.

A host job starts with a user request. The backend checks permissions and execution readiness, dispatches over the established Agent channel, receives status and output, and stores records for the console. An AI suggestion does not bypass these checks.

Confirm deployment topology and network ports against the actual installation package. All-in-One supports initial sign-in and core checks; Agent execution, integrations and event processing are enabled separately. Helm replicas, persistent volumes, certificates and network entry points also need explicit configuration. A connection in this diagram does not certify high availability or production acceptance.

Choose a reading path

Your taskSuggested reading order
Evaluate the platformQuick start → Agent onboarding → Remote access → Jobs and templates
Prepare a private deploymentDeployment preparation → Quick start or advanced deployment → Users and permissions → Backup and upgrades
Investigate a host or clusterAsset inventory → Kubernetes inspections or process diagnosis → Inspection follow-up
Release an applicationAsset inventory → Releases and changes → Observability and on-call

Key concepts

ConceptMeaning
Tenant and projectTenants separate organizational data. Projects further limit which resources a member may view and operate.
Asset and AgentAn asset is a managed-resource record. An Agent runs on a host. Finding an asset does not mean its Agent is online.
Job definition and executionA definition describes the task. Each execution records its targets, progress, output and result. Editing a definition does not rewrite execution history.
Execution result and check resultA successful command does not mean its checks are healthy. Missing data, unsupported checks and inconclusive results are separate from healthy results.

Community and Enterprise editions

Community Edition is free licensed software distributed as installation packages, not open source. It is licensed for one tenant, up to 50 managed nodes and one Kubernetes cluster, with core assets, jobs, in-platform audit and AI diagnosis.

Enterprise capacity, features and support depend on the purchased license. Both editions include AI diagnosis, which needs a connected model service, such as an enterprise model gateway or private model. Alert-event diagnosis works on alerts received through Observability and on-call. Cloud costs and localized-stack adaptation are Enterprise features. Moving from Community to Enterprise uses a replacement license file without requiring reinstallation or data migration solely for the edition change.

Validate a small scenario first

  1. Choose one host or test cluster approved for evaluation. Record its name, project and owner.
  2. Verify sign-in, asset visibility and read-only checks before evaluating remote access, jobs and releases.
  3. Check resource boundaries with a restricted operator account as well as an administrator.
  4. Keep execution records and results, identify unmet prerequisites and resolve them before expanding.
Something differs from your environment?

Send your deployment version, page and a redacted description so we can investigate and update the guide.

weiwendi@aiops.red