Loopback.Cloud
Documentation
DocumentationAgent modules

Agent modules

Loopback’s agent ships as a core runtime plus optional modules. Modules extend what the host can do—typically around performance-sensitive networking, security, or integrations—without forking a separate agent product for every customer.

This page uses generic language on purpose: exact module names, packaging layout, and version matrices are operator configuration. Use it to understand capabilities and governance, not internal package manifests.


Why modules exist

The core agent must stay small and stable: join the control plane, apply mesh configuration, report health, and honor RBAC for operational features.

Modules allow Loopback to:

  • Ship heavier or kernel-adjacent features (for example high-throughput firewall datapaths) without bloating every deployment.
  • Version modules independently from the core agent where that reduces risk (your operator may still ship paired releases).
  • Enable or disable capabilities per environment (lab vs production, regulated vs standard).

How modules behave (conceptually)

  1. Eligibility - the control plane advertises which modules are available for a host or workspace.
  2. Delivery - modules are downloaded and installed through the same trusted update channel as the agent (see Agent install and updates).
  3. Activation - configuration from Loopback turns modules on and supplies policy (rules, interfaces, feature toggles).
  4. Observability - healthy modules contribute metrics or health signals suitable for monitoring and support.

If a module fails to load, the core agent typically remains up so you do not lose inventory and heartbeat; the optional feature may be degraded until fixed.


Primary module family: host-integrated firewall

The flagship module story in Loopback is a host-integrated firewall implemented with eBPF for performance. It is documented in depth on a dedicated page so security and platform buyers can evaluate it without mixing concerns:

Think of that module as the default reference for “what a Loopback module looks like” from a risk and capability perspective: kernel-level enforcement, double-buffered policy updates, statistics, and integration with Loopback’s load balancer and monitoring stories where enabled.


Other module categories (illustrative)

Your deployment may include modules that fall into buckets such as:

  • Edge integration - tighter coupling between hosts and managed load balancer fabrics (often labeled in product materials as WGLB / LBFW-class features).
  • Metrics and diagnostics - richer host telemetry for monitoring sources or support bundles.
  • Future expansion - additional security or compliance-oriented probes without changing the core agent ABI every time.

Treat this list as non-exhaustive. Your operator’s release notes are authoritative for what is on in your tenant.


Procurement and security questions

Ask your operator:

  • Which modules are enabled for production workspaces vs sandboxes?
  • How are module packages signed and verified before load?
  • What kernel versions are required (eBPF-heavy modules usually require modern Linux and correct capabilities)?
  • What is the blast radius if a module misbehaves—does it affect only the optional datapath or all agent functions?
  • How are module updates staged (canary hosts, maintenance windows, forced minimum versions)?

Loopback.Cloud
© Loopback.Cloud. All rights reserved.