LogForge Documentation
Browse documentation

Supported environments

Check runtime, collection and interactive-access boundaries.

LogForge · Runs in your infrastructure

Deployment and collection

Before choosing a target:

  1. Identify your supplied release and intended host/cluster with your release contact.
  2. Check the capabilities below.
  3. Confirm the qualified combination, then use its matching guide. No shell or sign-in is needed for this checklist.

Release-specific support: a runtime's general capabilities do not establish that your supplied release supports them.

AreaDocumented path
LogForge serverSelf-hosted Linux host/VM supported by the selected release; public Git/Compose online installation or CPU-matched signed air-gapped package
Docker agentUse the installer offered by your installed release; Compose bundles need Compose 2.24.4+ and sudo
Docker placementthe server's Docker daemon or another operator-managed Docker host
Kubernetes agentGenerated Helm install; Kubernetes 1.32+, Helm 3, kubectl
LogsSupported runtime sources, monitored history, bounded live viewing
Runtime metricsSupported Docker container and Kubernetes Pod/container metrics
Custom application metricsNot supported
Linux host Terminal/FilesRelease 2026.11.03.64 on native AMD64 Docker; explicit administrator setup and local OS policy required; see host setup

Use Docker installation or Kubernetes installation. They use different artifacts.

Check: you have a qualified target and matching procedure before installation.

Editions and access

CapabilityCommunityBusiness
Local OwnerIncludedIncluded; no paid seat used
Agent enrollmentIncludedIncluded
Monitored logs/runtime metricsIncludedIncluded
AlertsIncludedIncluded
Additional people, teams, delegated accessRequires BusinessVerified license and seat capacity required

Website accounts and local LogForge accounts are separate. See Activation, People & Access, and the separate Docker Terminal permission.

Important limits

  • Kubernetes: no interactive Terminal/Files; telemetry access grants no workload-mutation permission.
  • Other runtimes: Podman, Swarm, and ECS/Fargate sidecars are outside this support line.
  • Metrics: no host, node, filesystem-volume, or storage-volume runtime metrics.
  • Backups: product-managed backup/restore is not a base-product feature.
  • Offline: the complete server package supplies server images; fully disconnected first agent installation needs separate release guidance. Updater internal-registry support is a different operation.
  • Release qualification: 2026.11.03.64 is qualified for native Linux AMD64 Docker. ARM64 artifacts are published; Kubernetes and real ARM hardware qualification remain separate.
  • Sizing: obtain workload-specific sizing; no general resource minimum is published.

Use Updates and recovery for release boundaries. Generated artifacts and the installed product determine available actions; do not infer update/rollback guarantees.

Begin with Requirements or Get started.

Follow the instructions for your installed release. Keep credentials and one-time agent setup files private.